Folks, 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'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. *Async behaviour* Joe Walnes (Mr Sitemesh - blog : http://radio.weblogs.com/0108103/), Charles Lowell (Thoughtworks) and myself are slowing pushing towards an Asynchronous aspect to AltRMI. Basically if a methods returns void and throws no exceptions, it could be executed asynchonously. This is a publication choice of course. Joe talks of a default implementation of 'over AltRMI' but envisages ones over JMS and other specialised messaging transports, possibly including the way-cool JavaGroups. With a JMS tyle solution hierarchies of messaging factories could be laced together to releive the burdon on the server and guaranteed deliver could be a value added possibility. *Unit Tests* I've added some more, based on an orginal one from Charles and Joe. We can now unit test, well integration test, all of the transports that AltRMI offers. There are more to add to specifically test the various tylpes of class loader and authentication, but they will be added later. There is work needed to make the Piped tests perform better - there must be some thrashing due to lack of threads in the test cases presently. I say that because the piped speeds suck, which is not my actual experience. It would also be nice to extract the testSpeed() elapsed time from the Jinit XML and make a page for use on the website with actual relative speeds. Has anyone got Zen level XSL and can take on the task? *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? *Dual level client side proxies* Consider an interface 'HowdieInterface' that has a single method 'void howdie()'. AltRMI generates the equiv of: public class AltrmiGeneratedHowdie_Main implements org.apache.excalibur.altrmi.client.AltrmiProxy{ private transient org.apache.excalibur.altrmi.client.ProxyHelper mProxyHelper; public AltrmiGeneratedHowdie_Main (org.apache.excalibur.altrmi.client.ProxyHelper proxyHelper) { mProxyHelper = proxyHelper; } public void howdie () { // method body } } public final class AltrmiGenerated2Howdie_Main extends AltrmiGeneratedHowdie_Main implements HowdieInterface { public AltrmiGenerated2Howdie_Main (org.apache.excalibur.altrmi.client.ProxyHelper proxyHelper) { super(proxyHelper); } } 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? *SOAP* Anyone want to take this on? Reusing Apache-Axis or James Strachan's Jelly (jakarta-commons-sandbox/jelly) or something else? *Custom XML transport* I'd though for a while that something that leverages http://www.csse.monash.edu.au/~bren/JSX/tech.html would be really cool. Unfortunately it is dual GPL/Commercial license which completely precludes any effort on our part to ship anything that includes it. We could. I'm sure do some work that codes against it using some Class.forName(..) way of circumventing the licnse issue, but previously it was incompatible with JDK 1.4. It would be interesting to see the speed of a JSX using transport over one that utilises the JDK serialzed objects (all other AltRMI transports). It would also be interesting to see how version tolerant this would be (XMLs promise). I'm beginning to think that James Strachan's Jelly is the way forward though. Talking to James there is some realy interesting work going on there. It is ahead of a curve presently and bit of a tool looking for its killer app. (Blog of James http://radio.weblogs.com/0112098/ change the skin dude!). *More transportable pass-by-value types* Currently the primatives and basic dervarions of plain Object are supported provided they are transportable. We can also do derivations of Object[] but I think more complex things require more work. Is Object[][] ever going to need to be supported? Also I feel that some special work needs to be done for Collection and Iterator etc. Thoughts? *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? *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? *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? *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. *Any Other Business* Anything else to discuss? Regards, - Paul -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
