Leo Simons wrote: > 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.
Just for my understanding. You want something similar as in the EJB 2.1 definiton. Instead of using JAX-RPC, you want to use Axis or something else to generate the server code (proxy/stubs?) to do RPC over Soap. Greets Gerhard -- -------------------------------------------------- Black holes were created when God divided by zero. -------------------------------------------------- Blog at: http://radio.weblogs.com/0107791/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
