avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Froehlich <g-froehl...@gmx.de>
Subject Re: [AltRMI] Changes / a Future
Date Sun, 25 Aug 2002 14:05:07 GMT
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:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message