bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Improving object mobility within the Hurd


From: olafBuddenhagen
Subject: Re: Improving object mobility within the Hurd
Date: Sat, 10 Jan 2009 08:50:28 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

Hi,

On Wed, Jan 07, 2009 at 10:24:33PM +0100, Carl Fredrik Hammar wrote:

> I'll be starting my bachelor's thesis this semester and have decided
> to pick up where I left off with libchannel.

Great news :-)

> I've been planning this for a while, but didn't announce it until now

That's so wicked of you... I though you deserted us ;-)

> 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 :-)

> 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?

> 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.

Regarding trust, I think this is complementary to authority. Probably
they should be considered together.

> 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?...

> 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)

> 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?

> [...]I'll be sending out mails to discuss the individual parts as I
> get to them.

I'm looking forward to it :-)

-antrik-




reply via email to

[Prev in Thread] Current Thread [Next in Thread]