I'd like to help work on this project. I've reviewed the code posted so far, and I have a general idea of what you're doing.
Before going too much further, I'd suggest working out a spec for the protocol. That would allow a team of client-side developer(s) and server-side developer(s) to work fairly independantly.
Shall we have the conversation here, rather than c.l.p?
Doug
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>Shall we have the conversation here, rather than >c.l.p?
I think an email based conversation would probably be for the better, it certainly would facilitate communications because we don't need to login into sourceforge to read or reply to messages. Perhaps a mailing list would be the best route.
Unfortunately, my computer's monitor is broken so I can get much done until monday when I get a replacement but I have a fairly good idea what needs to be done in the client (e.g. get package parsing done, add a list and remove module to let users see installed modules and remove them, write up my design docs and document more of the code).
At the moment, I'm inclined to get a working version based on ftp then adding more advanced functionality so that there is something done now and more advanced features can be added onto the existing framework.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't have a protocol really designed yet, I just a format for package information in mind and was thinking that this could be retrieved by the client through ftp to update information. I haven't given much thought to protocols and unfortunately it doesn't look like I will be able to do much work on this until wednesday due to some things I have to do for clients.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Have you considered using XML-RPC to query a Zope server? Using Zope would make it really easy for anyone to setup a mirror, all they would have to do is add a "Product" representing the backend.
It also keeps everything in the "Python family." ;) For clustering they can use ZEO and rsync over SSH, if needed, to keep the remote sites current.
The client software would only need xmlrpclib to query the server for files, documentation, etc. The the data could be downloaded by httplib or ftplib.
One problem though is determining how to approve the uploading of data, i.e., who is authorized and trusted to make changes.
Wayne
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd like to help work on this project. I've reviewed the code posted so far, and I have a general idea of what you're doing.
Before going too much further, I'd suggest working out a spec for the protocol. That would allow a team of client-side developer(s) and server-side developer(s) to work fairly independantly.
Shall we have the conversation here, rather than c.l.p?
Doug
>Shall we have the conversation here, rather than >c.l.p?
I think an email based conversation would probably be for the better, it certainly would facilitate communications because we don't need to login into sourceforge to read or reply to messages. Perhaps a mailing list would be the best route.
Unfortunately, my computer's monitor is broken so I can get much done until monday when I get a replacement but I have a fairly good idea what needs to be done in the client (e.g. get package parsing done, add a list and remove module to let users see installed modules and remove them, write up my design docs and document more of the code).
At the moment, I'm inclined to get a working version based on ftp then adding more advanced functionality so that there is something done now and more advanced features can be added onto the existing framework.
It sounds like you've got a protocol defined already. Do you have it written up somewhere?
Doug
I don't have a protocol really designed yet, I just a format for package information in mind and was thinking that this could be retrieved by the client through ftp to update information. I haven't given much thought to protocols and unfortunately it doesn't look like I will be able to do much work on this until wednesday due to some things I have to do for clients.
Perhaps an egroups/yahoo list would be best for this temporarily? At least it'd get archived.
Hey, nevermind the egroups thing, sourceforge already has a mailman list setup.
Have you considered using XML-RPC to query a Zope server? Using Zope would make it really easy for anyone to setup a mirror, all they would have to do is add a "Product" representing the backend.
It also keeps everything in the "Python family." ;) For clustering they can use ZEO and rsync over SSH, if needed, to keep the remote sites current.
The client software would only need xmlrpclib to query the server for files, documentation, etc. The the data could be downloaded by httplib or ftplib.
One problem though is determining how to approve the uploading of data, i.e., who is authorized and trusted to make changes.
Wayne