On 1/2/06, Denis Oliver Kropp <[EMAIL PROTECTED]> wrote: > Mike Emmel schrieb: > > I looked at Dbus I feel that Hessian accomplishes most of the same goals > > which far less code. Plus we have a good local ipc mechanism in fusion. > > I was intrested in a simple message format protocol the hessian format > > fits the bill. > > > > Here is my logic. > > 1.) The ipce mechanism should be able to register with and external > > discovery manager > > fusion right now uses simple env vars hessian urls Dbus > > provides it own ( not needed) > > Yes, the "top level" scope should be managed much better in Fusion. > Originally, I didn't design it for multi world/world-class support. > > > 2.) The ipc mechanism should provide a URI(URL) style for connection > > or allow it to be added easily ( fusion can be ) > > fusion:/0 ?? > Probably fusion://screen?0 fusion://appworld?0 fusion://sound fusion://video
Or something like that a well known name for the app world and and optional world id/index. > > 3.) Upon resolution the ipc transport should implement the following > > > > 1.) Region/Service level isolation > > Right now Fusion provides different worlds (regions?), > where each world should contain only one world-class (service?), > e.g. DirectFB and FusionSound, but it doesn't have to. > > > 2.) client id that last at least for the lifetime of current > > client/server instances. > > Like Fusion ID :) > Yep :) > > 3.) Connection/Port for fine grained service/object level access > > What do you mean by that? It shouldn't be tied to networking. > No maybe I should have said session. In fusion terms this is probably a fusion_reactor_attach_global Also it would be nice if the last argument was a id not a real pointer. > > 4.) Current message id (this is not a hard requirment depends on the > > transport). > > > > 5.) Finally ability to return a response message tied to a request. > > High level stuff like requests and responses can be built on top of Fusion. > I agree and thats fine. > > Requirments 2 and 3 and 4 can be encoded in the message body > > but that could require and additional layer of redirection. > > > > 4.) Simple binary transport that encodes the following > > 1.) Primitive data types including opaque byte arrays > > 2.) A container class and reference support > > A reference should at the minimum be able to refer to data > > previously serialized. > > That's quite networkish again. In Fusion the binary transport is built > on top of shared memory. Messages usually don't contain binary data. > Not sure what you mean there but the messages do contain a pointer to shared memory holding the message. I agree I used the concept when it would go over the wire but its basically the same. > > Now looking at fusion it does not out of the box provide > > two things > > 1.) URL abstraction layer api for connecting > > This can easily be added > > 2.)Builtin or default message format for basic serialization > > What (for) should the default format be? > Mostly since the message is open it so that you can handle parsing the bodies of the messages with common code instead of having to write another custom parser basically the same arguments as are made for xml. As far as format Voodoo is close just as I said add a list concept and references. > > This can be added so its not a huge issue. I'd like to see it > > done. I mention hessian because its documented but you can use the > > current voodoo ipc as a basis. It is I believe only missing the list > > support and references. So the proposal would be to unify voodoo and > > fusion. > > Voodoo is strongly tied to the client/server model and is just a layer > on top of the public interfaces of DirectFB. > > Fusion is the opposite :) No unification :) > Yep true I think if you unified the two then vodoo could run over fusion or the wire plus we can add additional services as needed and reuse a small message parsing library. > -- > Best regards, > Denis Oliver Kropp > > .------------------------------------------. > | DirectFB - Hardware accelerated graphics | > | http://www.directfb.org/ | > "------------------------------------------" > _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
