Re: [Mod-pubsub-developer] Java client update/rewrite

[Asynch M. <asy...@ho...>]

I'm a bit messed up with my connection to sourceforge - can't even access
anonymous cvs.
My machine got hosed & I re-installed (winxp) and I'm not sure I have the
same setup I did last year - i get errors about
cvs update: warning: unrecognized response `'ssh' is not recognized as an
internal or external command,' from cvs server

Anyway... i was thinking about refactoring pieces - try to hide the URI
construction code (long term we should try to improve the protocol to not
require any client to know about the syntax of the URI - I think there may
be a way to do that with Location: response headers), also I'd like to try
to maintain a pattern similar to JMS - possibly even having a 'connection'
interface (but not necessarily a direct JMS implementation) which may help
application determine their own threading approach. Not sure that is a
problem as typical desktop clients probably won't have but a few servers
they connect to.

I'll bang on WinCVS some more to try to get connected again - in the
meantime, let set out the structure of the interfaces you were thinking
about. Also, we should probably put those interfaces under
org.mod_pubsub.client or something.
What is the official java package name for mod-pubsub.org?


----- Original Message ----- 
From: "Robert Leftwich" <ro...@le...>
To: "Asynch Messaging" <asy...@ho...>;
<mod...@li...>
Sent: Thursday, March 18, 2004 2:46 AM
Subject: Re: [Mod-pubsub-developer] Java client update/rewrite


> At 04:30 PM 18/03/2004, Asynch Messaging wrote:
>
> >I'm interested in following the development & helping.
>
> Great!
>
> >I think following the protocol specification is a better route - that
avoids
> >accidental coupling with other client stacks & also may help expose
> >ambiguously documented features.
>
> Sounds like a good plan. I was looking to use the python code as the
> arbiter of what is and is not supported in the protocol, mainly because my
> memory is bad and I had this recollection that the protocol doco was a
> little lacking - apologies if my memory casts any dispersions :-)
>
>
> >Why does the java client need to be re-written?
> >Are there pieces that just don't work at all? Is it a stylistic thing?
> >It's been a few months since I looked at the source, but I thought it was
> >working okay.
>
> There are a number of areas where it doesn't meet the 'standard' protocol
> requirements, which causes some problems. I also wanted to bring it more
> into line with the other libraries, in particular, python as I am most
> familiar with it, in terms of class names, features, etc (but looking to
> the others more closely there is not that much similarity in class names
> and structure anyway), so that may not be as high a priority. I'm also
very
> keen to do it in a 'test driven design'  way as much as possible (as I'm
> somewhat test infected) and this will likely lead to a different end
result
> in any case.
>
> Robert
>



>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.614 / Virus Database: 393 - Release Date: 5/03/2004
>