Thank you for your response.
 
I was aware that my last mail was too vague on the subject of constraints on the project, but as you answered my main question (Q. - "Do we have documentation?" A. - "Not really") it was precise enough :o)
 
Anyway, I'll try to give a brief recap of our constraints and the choices we have made.
 
We are developing a utility for informal communication using a many to many communication structure.  Each user recieves data from other users s/he is interested in communicating with, and broadcasts her/his own data to any interested party.  As the system is envisaged to grow, a pure broadcasting model where clients filter out the information they do not want to see is infeasible due to bandwith restrictions.
 
This has led to the choice of a publish-subscribe communication model where users subscribe to another user's "topic", and each time this topic is updated the new data is propagated to the subscribers.  On a protocol-level this leads to some sort of multicast.
 
We do not really have need of distributed objects, and a message oriented middleware would therefore suffice.  Some kind of RPC would be nice to have, but our system will be able to work without this functionality in the middleware.
 
Other constraints on the projects says that we want to use an open protocol.  As our machines range from old Macs via unix workstations to new pocket-pcs, we end up having to use java 1.1.8.  As the RMI implementation in this version of java does not meet our demands for openness, we started to look for other solutions.  Jeremie was a possibility until we noticed that it does not work with the jre 1.1.8, and David is just too big for our smallest hardware.
 
These factors has led us to start working on a solution based directly on the protocols, with the aim of constructing a message oriented publish-subscribe model on top of the IpMulticast or other protocols.  You may like it or not ;o)
 
Right now, we are figuring out were to graft our modifications on to the Jonathan protocol model.  Using the GIOPProtocol implementation as a guide, it seems that we need Marshallers, UnMarshallers and a factory for these.  We will implement Session_High with our Topic-class, and Session_Low with our subscribers (called MessageBoxes).  In addition to this, we will implement a Protocol, a ProtocolGraph and SessionIdentifiers to interact with the underlying layers.  we will probably end up using TcpIpProtocol for the first version, and then use IpMulticast or an inhouse RtpMulticast afterwards.
 
This rather long-winded tale explains the context of the project and hopefully justifies our choices. I would appreciate comments on whether our understanding of the protocol-model is correct, and if we have found the right place to start.
 
Thank you for your attention,
Per Christian Nodtvedt

Reply via email to