Re: (no subject)

Shayne,

> Ooh. Quick problem. I note your lib is called "citlib". Thats going to
> cause namespace problems as thats what the server side one is. I
> wonder if maybe we ought have something like citserver and citclient
> to disambiguate the two projects.

Hrm, ok, thanks for the heads-up. I chose 'citlib' after looking through 
the Python standard library, where we have the following client 
implementations for Internet protocols:

    cookielib
    ftplib
    gopherlib
    httplib
    imaplib
    nntplib
    poplib
    smtplib
    telnetlib
    urllib
    urllib2
    xmlrpclib


... and the following server implementations:

    BaseHTTPServer
    CGIHTTPServer
    Cookie
    DocXMLRPCServer
    SimpleHTTPServer
    SimpleXMLRPCServer
    SocketServer
    smtpd

[http://docs.python.org/lib/internet.html]


Eventually, I would like to see our work end up in the std lib, so what 
are your thoughts on adopting its naming convention now? This would mean 
renaming the citadel server implementation to something like CitadelServer.

Then, of course, to be consistent, the client should be called 
citadellib. :-)

So ... to really be in line with current nomenclature, I think we would 
need to use citadellib and CitadelServer. However, I think your naming 
scheme makes much more sense than the standard library's, and I am 
willing to go with citserver and citclient.

Another alternative would be wrap both client and server into a single 
citlib package, of course.

And I had also toyed with the idea of packaging CitConn and Citadel 
separately (on the pattern of threads/threading, asyncore/asynchat), so 
not sure how that fits into the mix.


So there's a bunch of options. :-)

Let me know your thoughts ...




chad