Application/Execution model

What we have right now is very limitted and it has shown to be a problem on occasion.
All of PeerGroup, Service, ShellApp, and Shell implement an interface named jxta.net.platform.Application. What this interface provides is :

Running

I think we should at least specify whether or not a thread is dedicated to start executing each App, and if we trust the implementation to supply it or if we supply one de-facto. If we do, we need to decide which entity supplies it.

Other things that we may need to decide is what entity does create the actual objects that implement the Application interface. I find it mostly relevant to PeerGroup instances.

For groups, there's a factory. However, using the factory is not absolutely mandatory, and also the new object (at least a fully functional stub) is always returned to the invoker in the inactive state. (Except for Platform). For certain groups it may be all right, but would not we like the possibility of creating groups that do not give any control to the entities that instanciate them ? If we found a way to ensure that a group is always instanciated by a somewhat controled mechanism (provided by another group for example) then there would be a point in providing mechanisms for each group to specify whether it keeps control from the start, or it lets its creator play around. Think of it as an equivalent of a unix executable file that has permissions s--x--x and belongs to root. This is considered to be safe because an ordinary user cannot change what this executable will make of its superuser privilege, but may still have legitimate reasons to want it to happen.

As a means of implementation, what if the group could decide what object is returned to the instanciator ? Could be null. I am not forgetting that top-to-bottom non-conforming implementations can exist, so, this may not enable any more garantees for other peers in that group anyway. As Mike summarized recently: "the only truth is on the wire". Not sure the framework side of things can help at all on distributed security aspects, but at least it would provide some sanity checks to ensure indivudal peers are runing smoothly for their respective users.

Standard input and ouput

I am somewhat questioning the concept of shell apps. Not that the properties of shellapps are bad, on the contrary, having standard IO pipes is a great feature, that's why I am wondering if we do not want to make all apps be like shell apps, and deal with the actual existence of pipes in a more dynamic fashion. A bit like unix does, in fact. All processes may have standard IO files (in fact, it is essentialy a convention). Init on the other end has none, and some daemons just close those that they get. The shell itself is orthogonal to that. It can execute pretty much anything that's executable.

One reason why there are separate init and start methods, however, is for being able to set the pipes of shell apps before we start them. So our way of dealing with app pipes is correlated with how we control the starting of apps. But that's not something I am too worried about. Since pipes have the very nice property that they can be defined independantly of the existence of both ends, we could probably simply supply lists of input and output pipe IDs as arguments and let the app create input or output ends when it is ready...plus or minus devilish details; it's not a spec, just ideas.



Jean-Christophe Hugly

Last modified: Thu Jun 14 14:40:10 PDT 2001