Re: [Springframework-developer] HttpInvoker

[Seth L. <set...@gm...>]

I'm not sure how abstract the new HTTP Invoker stuff is (haven't had a
chance to look at it).  But in reference to your request for a socket
implementation, one possible implementation is a BEEP implementation. 
It would be better than a socket approach, but not HTTP (for those who
need a non-HTTP choice).

Seth



----- Original Message -----
From: Martin Kersten <mar...@st...>
Date: Tue, 17 Aug 2004 07:22:11 +0200
Subject: [Springframework-developer] HttpInvoker
To: spr...@li...

 
Getting notice of the HttpInvoker implementation yesterday, 
I would like to make some additional suggestions. 
  
I programmed such a solution half a year ago, using 
serialization for remote procedure calls. I tried to contribute 
the code to Spring those days, but I wrote about the request 
in the sourceforge forum only and got only one reply those 
days :-(. 
  
Never the less, such a simple remoting solution proofed to be 
usefull outside the areas of Spring. It works well for 
client<-->server communication in general and 
applet<-->server communication in special. The client 
API's footprint is only about 5KB to 6KB so it is predestinated 
for mobile/applet point-to-point communication. 
  
Also I think, in most areas a socket-driven solution is more 
preferable than a http one, since session management feels 
more natural then http requests/http sessions, and it establish 
a two-way communication, but maybe this is just more like 
a habbit. 
  
Since I am currently using Spring RC 1.1, I had noticed 
that Spring 1.1 is most likely to become final these days, 
I guess I am maybe late, but here is a summary about I 
finally want to suggest: 
  
* I would like to see such a 'simple RPC' solution to be 
exposed as an independent API. 
* It should also provide socket-driven connections 
(two-ways connection). 
  
  
So what do you folks think about this? 
  
  
Bye, 
  
Martin (Kersten)