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 ?? > 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 :) > 3.) Connection/Port for fine grained service/object level access What do you mean by that? It shouldn't be tied to networking. > 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. > 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. > 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? > 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 :) -- 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
