Menu
▾
▴
springframework-developer
|
From: Martin K. <Mar...@St...> - 2004-08-17 05:23:43
|
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=20 serialization for remote procedure calls. I tried to contribute the code to Spring those days, but I wrote about the request=20 in the sourceforge forum only and got only one reply those=20 days :-(. Never the less, such a simple remoting solution proofed to be=20 usefull outside the areas of Spring. It works well for=20 client<-->server communication in general and=20 applet<-->server communication in special. The client=20 API's footprint is only about 5KB to 6KB so it is predestinated=20 for mobile/applet point-to-point communication.=20 Also I think, in most areas a socket-driven solution is more=20 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=20 a habbit. Since I am currently using Spring RC 1.1, I had noticed=20 that Spring 1.1 is most likely to become final these days,=20 I guess I am maybe late, but here is a summary about I=20 finally want to suggest: * I would like to see such a 'simple RPC' solution to be exposed as an independent API.=20 * It should also provide socket-driven connections=20 (two-ways connection). So what do you folks think about this? Bye, Martin (Kersten) |
|
From: Seth L. <set...@gm...> - 2004-08-17 06:13:09
|
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) |
|
From: Martin K. <Mar...@St...> - 2004-08-17 06:44:06
|
> 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). Are you referring to the beepcore-java project? It doesn't look that kind of a lightweight solution. Lots of depending libraries anyway. Or are you referring to something special? Cheers, Martin (Kersten) <<>> > ----- 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) > > > ------------------------------------------------------- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Seth L. <set...@gm...> - 2004-08-17 07:06:02
|
> Are you referring to the beepcore-java project? It doesn't look that > kind of a lightweight solution. Lots of depending libraries anyway. Or > are you referring to something special? I haven't seen it in a while. Just popped into my head a moment ago. :) Still an option, though not sure there's any demand... Seth |
|
From: Martin K. <Mar...@St...> - 2004-08-17 07:29:28
|
> > Are you referring to the beepcore-java project? It doesn't look that > > kind of a lightweight solution. Lots of depending libraries anyway. Or > > are you referring to something special? > > I haven't seen it in a while. Just popped into my head a moment ago. > :) Still an option, though not sure there's any demand... That's why I suggest to rename the HttpInvoker and pull out the solution to create an independent project/API around it. It's mostly just about the InvokationAction and InvokationResponse. Serialize a method invokation and return any results (including caught exceptions). Using dependency injection you can establish connections between two objects by ease without those objects to notice it. It feels like Java. It also eases testing :-) And I think the impact on finialization of Spring wouldn't be such big. It simply requires a renaming and a reconsideration. It also only involves renaming refactorings. Therefore it is very unlikely to introduce bugs to the current implementation. But once the API gots frozen, it will be to late and the opportunity is gone... . Martin (Kersten) > > ------------------------------------------------------- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
