"dhtapp" <dhtapp / cox.net> schrieb im Newsbeitrag
news:JtENb.17981$Ar1.3600 / fed1read04...
> Hi,
>
> I'm fiddling with a little personal client/server project (still in the
> "toy" stage), mainly to get somewhat better at a few different things
> simultaneously.
>
> The first draft of the server is going to be Ruby 1.8, using a pstore
for
> backing.  The first shot at the client is in Java 1.4, using Eclipse and
SWT
> (which I'm also learning).
>
> I'm at the point where I need to settle on a communication strategy.
(As a
> WebObjects techie for the past few years, this kind of stuff all
happened
> automagically for me.)  Looking through the Pickaxe book and some of the
> whitepapers up on java.sun.com, I find myself wondering whether HTTP or
> socket-level would be a better payoff, ultimately.
>
> For now, the communications can be XML-ish plaintext, i.e.
>
> -- From client
> <login_request>
>     <username>dan</username>
>     <password>fido</password>
> </login_request>
>
> -- From server
> <login_response>
>     <status>OK</status>
>     <session_key>1aBwhateverfoo</session_key>
> </login_response>
>
> But I also find myself wondering if it wouldn't be possible to
occasionally
> pass Java objects across the wire and have them stored in the Ruby
pstore
> (using, I guess, some magic with Array#pack...?)

I don't think that array pack is appropriate.  But you can use XMLEncoder
and XMLDecoder to serialize a bean to / from XML:
http://java.sun.com/j2se/1.4.2/docs/api/java/beans/XMLEncoder.html

Maybe you can invent a Ruby class that reads this XML and builds an object
graph from that.  Of course you'd have to do some translations of method
names etc.  But I don't think it is far fetched.

> So, to anyone with more network programming experience in both Ruby and
> Java, my question is: if you were in my position, which approach would
you
> take?  Or, maybe more appropriately, what kinds of questions should I be
> asking myself to help make the determination?

I think HTTP is a good starting point if that protocol suits your
application (i.e. only message exchange, no permanent connection) because
there are tools for that on both sides.  If encapsulated properly you can
exchange it later if you feel the need.  If you choose sockets, you'll
have to implement yourself what lots of others have done already: network
communication protocols.  While HTTP is a bit limited, there are CORBA,
RMI, XML-RPC, SOAP via HTTP etc.

Regards

    robert