Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Java (http://www.velocityreviews.com/forums/f30-java.html)
-   -   I've been lazy (http://www.velocityreviews.com/forums/t751494-ive-been-lazy.html)

Ross 07-15-2011 07:59 AM

I've been lazy
 
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 07-15-2011 03:04 PM

Re: I've been lazy
 
On Jul 15, 12:59*am, Ross <rossclem...@gmail.com> wrote:
> 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.

--
Lew

Robert Klemme 07-15-2011 03:30 PM

Re: I've been lazy
 
On 15 Jul., 17:04, lewbloch <lewbl...@gmail.com> wrote:
> On Jul 15, 12:59*am, Ross <rossclem...@gmail.com> wrote:
>
> > 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.


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 07-15-2011 03:35 PM

Re: I've been lazy
 
On Jul 15, 8:59*am, Ross <rossclem...@gmail.com> wrote:
> I've just written a client/server application.


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


Ross 07-15-2011 04:38 PM

Re: I've been lazy
 
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 07-15-2011 04:39 PM

Re: I've been lazy
 
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 07-16-2011 12:48 PM

Re: I've been lazy
 
On 15.07.2011 18:38, Ross wrote:
> 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

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

Ross 07-16-2011 03:48 PM

Re: I've been lazy
 
On Jul 16, 1:48*pm, Robert Klemme <shortcut...@googlemail.com> wrote:
> On 15.07.2011 18:38, Ross wrote:
>
> > 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.


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 07-16-2011 05:21 PM

Re: I've been lazy
 
On Jul 16, 8:48*am, Ross <rossclem...@gmail.com> wrote:
> On Jul 16, 1:48*pm, Robert Klemme <shortcut...@googlemail.com> wrote:
>
>
>
>
>
>
>
>
>
> > On 15.07.2011 18:38, Ross wrote:

>
> > > 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.

>
> 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.

--
Lew


All times are GMT. The time now is 04:42 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.