On Sun, 2002-08-25 at 13:55, Paul Hammant wrote: > Folks, Paul =)
> Firstly -> > >http://cvs.apache.org/viewcvs/jakarta-avalon-excalibur/altrmi/src/xdocs/altrmi_logo.gif > > -> Way cool!! I missed it happening, but it looks good. I did those; however it was afterwards mentioned that this might be brand diffusion blah blah so I now officially feel all the new logos should be removed ;) > I'd like to start a dialogue with persons intersted in pushing AltRMI > forward. Namely those are Leif, Peter Royal, Vinay and Jeff looking at > the CVS logs. Stephen too is interested given some previous Merlin > work. There are also some users of AltRMI in companies for bespoke > solutions. I'm experimenting...shame I haven't got more time. > *Jar Files* > > Currently there are five jars files for AltRMI. Given that there are > multiple transport implementations, it is likely that users will use jar > files that contain transports that are just not needed. Should we push > towards more jars files? There is also a case that we should push > towards less jar files bu combining the server and client interfaces > ones into the common. Thoughts? 5 seems plenty. It seems footprint is important (I imagined a UMTS cell phone app talking to a server using AltRMI), so it seems you should indeed keep the client interface separate. > This is done so that in theory a remote client like BeanShell (I love > it), can use the service and do preper reflection over the methods > without dealing with an java.reflect.Proxy style invocation handler > which is a bit of a black-box to reflection tools. Anyway a couple of > people have requested that the classloader should get dependencies over > AltRMI like RMI does. Specifically that would mean HowdieInterface in > the above example. At the same time we could combine the two above > classes into a single class. This would be quite easy for the Javac > using proxy generator. For the BCEL one ot would be harder for me cos I > have trouble understanding it to the level Vinay does. Thoughts? all sounds good but I can't help and I also don't need it ;) > *SOAP* > > Anyone want to take this on? Reusing Apache-Axis or James Strachan's > Jelly (jakarta-commons-sandbox/jelly) or something else? I want to... thoughts I had: - jelly is cool, but yet another development package - axis on the client is heavy, axis on the server is bliss - I wonder whether SOAP/AltRMI interop is feature flexibility otoh, it seems to me you can generate soap stubs etc using Axis for AltRMI generated code quite easily. > *Distributed Garbage Collection* > > We have implemented this so far using WeakReferences on both the client > and server side. .Net uses leasing. The weak references is a perfect > world scenario, but if a client dies without tidying up, then the server > will be prevented from garbage collecting an item on teh server side. > It also relies on the fact that Java does actuall GC objects when they > are inaccessible, and not when there are tight memory situations. > Should we also implement a leasing scheme? My view is that it would > supplement the weak reference impl addressing the client-death scenario. > Thoughts? cool feature, not vital. Me, I'd work towards release before adding this. > *AltRMI tunnelling* > > Just an idea. Is there a concept of a firewall or proxy server for > AltRMI? I.e. a way of tunnelling an AltRMI connection through a server. > Some listener that does nothing other than forward calls to some other > thing. Thoughts? not really neccessary I think as SSH tunneling works just fine for a gazillion different setups =) > *AltRMI redirection* > > Another on the original todo list. Client esablished a dialog with a > server but is redicrected to another server which unknown to the user of > lookup(..). A poor man's load balancing. Thoughts? is this not something that can be coded on a higher (application) level? > *Seperation of Content and Addressing* > > Currently some bastardized command pattern is uses as the messaging > protocol (over the transport) for method invocations. The whole thing > has to be deserialzed to show what type of command it is. If this were > split into basic info and a methods args components, then tunnelling > might be easier. Deterministic routing might be easier too. Having > said that basic client to server connections would be slower. > *Seperation of Content and Addressing* > > Currently some bastardized command pattern is uses as the messaging > protocol (over the transport) for method invocations. The whole thing > has to be deserialzed to show what type of command it is. If this were > split into basic info and a methods args components, then tunnelling > might be easier. Deterministic routing might be easier too. Having > said that basic client to server connections would be slower. when in doubt about protocol setup, copy from TCP/IP =) so sounds like a good idea. > > *Any Other Business* > > Anything else to discuss? - can I have an alpha release, please? ;) - docs docs docs as always; I keep getting lost in the code - it'd be cool to have a servlet (if it comes as a .war it for some reason is always accepted as "standards compliant") it's all take and no give from my side atm...but I'm happy to see activity ;) cheers, Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
