I've been lazy

[Ross]

I've just written a client/server application. Usually when I do this,
I have to spend some time getting the protocols right, with hung
clients or servers being a typical alpha debugging scenario. This time
I just decided that all communications from the client were a single
string (encoded and sent encrypted with the server's public key).
Where usually I'd have a sequence of steps for operations that require
multiple bits of data, I just encoded all data into the single string,
and the server unpacks them, executes the command potentially using
unpacked data, and then replies with a single packed string. This was
much easier than having multi-step protocols.

Next time I'm defining an XML schema for requests and replies to make
this even more robust/general.

Apologies for the stream of consciousness question-less post.

 

[lewbloch]

I've just written a client/server application. Usually when I do this,
I have to spend some time getting the protocols right, with hung
clients or servers being a typical alpha debugging scenario. This time
I just decided that all communications from the client were a single
string (encoded and sent encrypted with the server's public key).
Where usually I'd have a sequence of steps for operations that require
multiple bits of data, I just encoded all data into the single string,
and the server unpacks them, executes the command potentially using
unpacked data, and then replies with a single packed string. This was
much easier than having multi-step protocols.

Next time I'm defining an XML schema for requests and replies to make
this even more robust/general.

Apologies for the stream of consciousness question-less post.

This isn't a help desk but a discussion group, so your introduction of
a discussion topic is entirely appropriate. Sounds like RESTful
services or other XML-based communication protocols. Since there are
plenty of robust, standard libraries for this out there, you might
seriously want to use those. It's hard enough to master the
deployment and ops details without reinventing the programming wheels.

 

[Robert Klemme]

This isn't a help desk but a discussion group, so your introduction of
a discussion topic is entirely appropriate.  Sounds like RESTful
services or other XML-based communication protocols.  Since there are
plenty of robust, standard libraries for this out there, you might
seriously want to use those.  It's hard enough to master the
deployment and ops details without reinventing the programming wheels.

Another thought that came to mind when reading the original posting:
if both client and server are Java and there is zero chance that other
languages need to be supported RMI might be a good choice, too. RMI
avoids to manually do the parsing process. If other languages need to
be supported then CORBA's IIOP is also a good fit - especially since
it is less verbose than XML (and maybe also RMI). Granted, nowadays
XML and SOAP / WS are hip and there are plenty tools around (and also
debugging of ASCII based messages is easier) so that's probably the
most reasonable way to go.

Kind regards

robert

 

[Paul Cager]

I've just written a client/server application.

Your title reminded me of this:
http://c2.com/cgi/wiki?LazinessImpatienceHubris

 

[Ross]

Fundamentally the program I'm writing is an experimental program,
rather than a commercial product. Hence, my primary aim is to get a
working version of it that I can release to people, and see if they
like using it. If it's a hit, then it's reasonable to start rewriting
bits of it to make them more elegant under the hood. Otherwise, if the
end user can't see it, it's not a high priority. It took me part of a
day to write the client/server code, so almost any amount of learning
curve for things I haven't used in a while (e.g. RMI) would have meant
that it took longer to get that functionality working.

I'm reminded of the old programming maxim "Make it work first, then
make it work fast". At the moment, I'll make it work at all, then make
it more elegant under the hood. Fundamentally, I *need* people using
it.

 

[Ross]

PS: There will only be one server running, and it'll be on a computer
managed by me. So, deployment is not a problem.

 

[Robert Klemme]

Fundamentally the program I'm writing is an experimental program,
rather than a commercial product. Hence, my primary aim is to get a
working version of it that I can release to people, and see if they
like using it. If it's a hit, then it's reasonable to start rewriting
bits of it to make them more elegant under the hood. Otherwise, if the
end user can't see it, it's not a high priority. It took me part of a
day to write the client/server code, so almost any amount of learning
curve for things I haven't used in a while (e.g. RMI) would have meant
that it took longer to get that functionality working.

I'm reminded of the old programming maxim "Make it work first, then
make it work fast". At the moment, I'll make it work at all, then make
it more elegant under the hood. Fundamentally, I *need* people using
it.

It is not too unlikely that the architecture of an experimental program
does not fit real usage needs - especially if you provide it as a public
service which can be hit by arbitrary many clients. In those cases it's
not enough to "start rewriting bits of it" but you need to rearchitect
it which often means a major effort.

Experience shows that code that exists has a certain - err ductility? -
which keeps it hanging around longer than you may want.

If you are afraid of the learning curve you could at least replace your
custom format (which we do not know) with something like JSON which is
pretty short yet allows for arbitrary structured data much like the
verbose XML. That will give you flexibility and avoid having to fiddle
with the details of parsing.

Kind regards

robert

 

[Ross]

It is not too unlikely that the architecture of an experimental program
does not fit real usage needs - especially if you provide it as a public
service which can be hit by arbitrary many clients.  In those cases it's
not enough to "start rewriting bits of it" but you need to rearchitect
it which often means a major effort.

Experience shows that code that exists has a certain - err ductility? -
which keeps it hanging around longer than you may want.

If you are afraid of the learning curve you could at least replace your
custom format (which we do not know) with something like JSON which is
pretty short yet allows for arbitrary structured data much like the
verbose XML.  That will give you flexibility and avoid having to fiddle
with the details of parsing.

I wouldn't say that I'm "afraid" of the learning curve, just that I
would
rather allocate the time to other things. The client/server part is an
add-on
to my current application, rather than a major part of it. And, the
code I have
is reasonably simple, and it works, which is what I want. I don't
believe that
I'll need to rewrite it ever if I don't want to.

I'm going to write another client application soon, which will have
very limited
communication between the client and server. So, what can I use that I
can distribute
as an executable .jar file that doesn't require any other resources
such as SSL
key files, doesn't require policy files, or the rmiregistry to be
running, etc?

Sometimes you just want to "do it" rather than spend a month in
analysis paralysis.

Also there's the age old saying "plan to throw one away, you will
anyway".

 

[lewbloch]

I wouldn't say that I'm "afraid" of the learning curve, just that I
would
rather allocate the time to other things. The client/server part is an
add-on
to my current application, rather than a major part of it. And, the
code I have
is reasonably simple, and it works, which is what I want. I don't
believe that
I'll need to rewrite it ever if I don't want to.

I'm going to write another client application soon, which will have
very limited
communication between the client and server. So, what can I use that I
can distribute
as an executable .jar file that doesn't require any other resources
such as SSL
key files, doesn't require policy files, or the rmiregistry to be
running, etc?

Sometimes you just want to "do it" rather than spend a month in
analysis paralysis.

Also there's the age old saying "plan to throw one away, you will
anyway".

He who lives by the sword, dies by the sword.