I've been lazy

Discussion in 'Java' started by Ross, Jul 15, 2011.

  1. Ross

    Ross Guest

    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.
     
    Ross, Jul 15, 2011
    #1
    1. Advertising

  2. Ross

    lewbloch Guest

    On Jul 15, 12:59 am, Ross <> 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
     
    lewbloch, Jul 15, 2011
    #2
    1. Advertising

  3. On 15 Jul., 17:04, lewbloch <> wrote:
    > On Jul 15, 12:59 am, Ross <> 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
     
    Robert Klemme, Jul 15, 2011
    #3
  4. Ross

    Paul Cager Guest

    Paul Cager, Jul 15, 2011
    #4
  5. Ross

    Ross Guest

    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, Jul 15, 2011
    #5
  6. Ross

    Ross Guest

    PS: There will only be one server running, and it'll be on a computer
    managed by me. So, deployment is not a problem.
     
    Ross, Jul 15, 2011
    #6
  7. 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/
     
    Robert Klemme, Jul 16, 2011
    #7
  8. Ross

    Ross Guest

    On Jul 16, 1:48 pm, Robert Klemme <> 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".
     
    Ross, Jul 16, 2011
    #8
  9. Ross

    lewbloch Guest

    On Jul 16, 8:48 am, Ross <> wrote:
    > On Jul 16, 1:48 pm, Robert Klemme <> 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
     
    lewbloch, Jul 16, 2011
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    6
    Views:
    484
    Joe Smith
    Apr 21, 2004
  2. =?Utf-8?B?YmxhY2toYXdr?=

    Lazy Loading Grid Object

    =?Utf-8?B?YmxhY2toYXdr?=, Nov 10, 2004, in forum: ASP .Net
    Replies:
    4
    Views:
    587
    =?Utf-8?B?YmxhY2toYXdr?=
    Nov 12, 2004
  3. Ken Pu
    Replies:
    3
    Views:
    674
    Steven D'Aprano
    Jan 16, 2009
  4. Boris Borcic
    Replies:
    0
    Views:
    550
    Boris Borcic
    Jan 16, 2009
  5. Boris Borcic
    Replies:
    0
    Views:
    547
    Boris Borcic
    Jan 16, 2009
Loading...

Share This Page