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)
2.) The ipc mechanism should provide a URI(URL) style for connection
or allow it to be added easily ( fusion can be )
3.) Upon resolution the ipc transport should implement the following
1.) Region/Service level isolation
2.) client id that last at least for the lifetime of current
client/server instances.
3.) Connection/Port for fine grained service/object level access
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.
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.
3.) Synchronous return/result messages and error reports.
This is simply a more detailed version of 5 above.
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
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.
Hessian:
Hessian provides all the above and includes some extras like maps and
xml data types that are not explictly needed.
If you look at dbus it has far far more then is needed for a core
system level ipc service.
The big mistake with dbus is they did not split out the Service
Manager or meta service from the ipc system. Look at DNS or
Apples Rendezvous. My point is discovery is a completly different
problem from using a ipc transport. One job of the discovery manager
is to actually determine the best transport for a requestor it needs
to answer these questions.
1.) Is the service and requestor in the same process
2.) Are they on the same host
3.) If not what is the network between them and its abilities
local/wlan high/low bandwith latency etc etc.
4.) Security requirments ( I.e can it even do the lookup ?)
5.) Finally the lookup service should be able to tell the requestor
some basic info on the performance of the service connection this may
come from the url format asking the service etc etc. This could
include listing mutiple paths providers etc. This should only be
provided if requested i.e the client should be able to just get a
reasonable default.
In short the network is not transparent.
For now the Service manager design is outside the scope of the problem
we need to solve but it does need to be addressed.
Corba, Dbus, jini, dcom, xpcom, rmi, Web Services, etc etc etc don't get it.
Mach ipc, Unix shmem/sendmsg, fusion, hessian, snmp
are on the right track.
To wrap up you need.
1.) String or url based Service manager/transport resolver
2.) Simple message protocol.
3.) Basic message format api.
For a compete system you probably want transports optimized for the
various connection scenrios in process,local, remote(bandwith/latency)
Mike
On 1/1/06, Alex Lau <[EMAIL PROTECTED]> wrote:
> What about using DBus?
>
>
_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
