Hi, On Sat, Jan 10, 2009 at 08:50:28AM +0100, olafbuddenha...@gmx.net wrote: > > I have dropped the channel concept and have opted to focus on > > arbitrary Hurd objects. I've adopted term ``mobile object'' from > > similar frameworks such as Java's RMI, where it is usually used when > > the transfer may load the objects' required code base. It's short and > > sweet. > > I don't know the term from other contexts, but indeed it seems pretty > nice :-)
Perhaps I should add that the context in question is distributed systems. The main difference from what I'm doing is that they usually assume communication over network. > > I've split the project into three main parts: improving authority > > verification, improving code transfer and an object system that can > > emulate Hurd objects. This because while they reinforce each-other in > > respect to mobility, they are orthogonal and might be useful in other > > areas. > > I must admit that I don't see it (yet)... Can you please explain how you > imagine these to be useful in different contexts? The first two parts could be used to improve mobility in libstore directly, without porting stores to the new object system. It could also be useful for alternative mobility framework, which might want to use a tailored object system. Most likely they might consider my object system overkill if they don't actually want to emulate Hurd objects. The object system itself can be used in contexts outside of mobility. For instance, libstores mechanism for specifying stores on the command line. Thus the process don't need other translators to provide the store for it (using it remotely or transferring it). This is useful for the root file system translator during boot, e.g. if the file system is on some RAID configuration. The command line mechanism can ignore many of the issues that arise in mobility, e.g. consistency between different copies. Looser restrictions means a larger class of objects can be implemented. > > By ``code transfer'' I mean how the code base of an object is > > specified so it can be found and loaded by the receiver. The receiver > > must also be able to determine if it can trust the code. Again > > chroots and sub-Hurds makes this more fun, e.g. what if the two > > parties use the same name for different code bases? > > As I said before, I believe it is best for the server to provide the > object code directly (by an RPC), rather than letting the client look it > up somewhere. This would entirely remove the naming problem, along with > some others. This is one of the methods I'm considering, i.e. ``naming'' the code with a port to the .so file. I do not have high hopes for this method though, mostly because it's hard for the recipient to determine if it can trust the code. More on this in later mails. > Regarding trust, I think this is complementary to authority. Probably > they should be considered together. Really? Being allowed to do something is quite distinct from trusting that it really does what it claims to do IMHO. > > Interfaces that aren't possible through RPCs that utilize the fact > > that the receiver is in the same address space should also be > > possible, though naturally these can't be used through a wrapper port. > > That means the objects can't migrate in a transparent fashion. What use > cases do you see for non-transparent object migration?... I thought you'd be cheering this feature. It allows for interfaces which don't have to assume that the object is remote, e.g. it can use pointers, globals, etc. This is done at the cost of transparency. I don't know a particular use case where it would be worth losing it, I figure it's mostly a question of not introducing any artificial limitations. > > Lastly, these parts will be tied together into a library, which I > > think I'll call ``libmob''. > > LOL... Is the pun intended? :-) (herd vs. mob) It is now! ;-) I was mostly associating it with its use in MUDs for monsters which can roam from room to room, where it's short for Mobile OBject. I like the idea of little monsters running through the translators by themselves, though technically this would be a mobile agent, not an object. It is interesting to note that ``mob'' is derived from ``mobile vulgus'', which is Latin for ``the easily movable crowd''. (Thanks goes to Wikipedia.) So its also associated with mobility. > > And I'll do some simple performance benchmarks, which should show when > > using mobile objects instead of IPC is a good idea if at all. This > > will hopefully give a substantial result without committing myself to > > find concrete use case. Though optimization is probably one of > > mobility's least interesting possibilities, it's the one that > > instantly springs to mind. > > What other possibilities do you see? Maybe my statement was a bit premature, as currently my thoughts on this are a bit vague. But I have high hopes :-) One idea I have been toying with is using it for alleviating the problem of resource accountability. I.e. making the client load an object which manages state needed by the server. Consider an object that maintains the current position within a file, then the translator wouldn't need to maintain such session state. Since this is an idea in the making, there are many issues I haven't worked out. But I don't have time to spend on it at the moment. I'm also sure there are interesting use cases that skip the transparency requirement. Though I haven't come up with anyone yet. Regards, Fredrik
