Re: [cspace-users] Roadmap
Yes... unusual to say the least. On 1/22/07, Andreas <[EMAIL PROTECTED]> wrote: I really wonder about thomasassta... In so many P2P projects he writes such a bunch of theorys... Or these combinations of projects... Not the way an average user does... - Original Message - From: "Sebastian Silva" <[EMAIL PROTECTED]> To: Sent: Monday, January 22, 2007 10:32 PM Subject: Re: [cspace-users] Roadmap Guys @tachyon... I have been following your mailing list and I have whitnesed you being extremely polite to "thomasassta" but he is really extremely disruptive specially now that he is taking your name in answering to users. Cspace is nice and it needs to mature and I hope I can lend a hand sometime. Meanwhile I'm watching and thanks. Just ban that guy like would be done on an IRC channel. You can post a little policy note or something. Its sad but really just look at the archives. Thanks Sebastian On 1/13/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Original-Nachricht > Datum: Sat, 13 Jan 2007 11:41:21 +0530 > Von: Jeethu Rao <[EMAIL PROTECTED]> > > > > - Cspace is not decentral, it needs a tachion server for creating an RSA > > key and it needs the Cspace-ID for the taychion server to launch the > > application. We need to change this. > > > > > Though there is a hint of truth to what you're saying, its not entirely > > true. This is probably the 3rd time I'm explaining this on cspace-users. > > > Hi Jeethu, good to know your not dead here on the list. > > > The central server is there just to maintain a persistent mapping > > between the Public Keys and the key-ids. There was no way we could > > implement atomic increments (like an autoincr field in a DB) securely in > > the DHT, and thus we had to use a centralized server for this. > > > not understood, do you mean, it is needed to establish a secure dht, then if done, we can get rid of the server? > > > This does > > not compromise the security of CSpace in any way. This one time > > registration process with the *cspace-id* can be made optional, and we haven't made > > it yet. > > Well, till know tachyion does know any Ip adress and any Nicname and any RSA-key for the nickname. This is not at all decentral. We even could not use cspace without tachyion, we are far away to be a gnutella style network. > > > Would it then be possible to create an RSA-Key without a server? > So that we seperate bootstrapping the dht and registration/RSA-Key-Creation? > > > I think it is good to have short numbers we can communicate on telephones, but what about a wesite, entering the CSpace ID and getting the RSA-Key back. > > Then Cspace can work totally without Cspace-ID, and we can use always the RSA-key, the ID-Should be just a helping box, to identify the RSA-Key. > > Second: would it be possible, to share the RSA-key = Cspace-ID in a match-atabase on the DHT ? > > So like emule kademlia, I search for the Cspace-ID and get the RSA-Key back out of the DHT, so the match could be made decentral as well. > OK Fake Clients then could provide fake matches, but this should be not a problem, as users only do this if they reinstall a system or are on vacations travelling. and if they chat then, they do get the right nic-name from the client or not, this should identify wrong matches. > > So get rid of this server and be owner of a network, not a messenger. > > > > And the application does not need to connect to the central server, > > every time its launched. The central server is only used after creating > > a new key pair and while adding a new user with a keyid (you can always > > enter the public key directly and avoid the connection to the central > > server) > > > > OK, but how, if I cannot launch the application without the cspace-ID and the server is connected... > > > > > - The question for security is as well, if you permit user "sreeram", if > > then a fake could use VNC or your PC, so the RSA-Key has to be inserted > > into the permission and not the nicname. > > > > > This simply is not possible because of the following constraints: > > All nick names in a users buddy list are guaranteed to be unique > > For any new user whose pub key is not in the user's buddy list, > > CSpace adds a "unknown-" prefix to his nickname > > > Right, I know, but it would be possible to code a client, which is not interpreting the nic-name to the saved RSA-Key for this buddy, then we would have a problem for this clone. > This is why the process has to be, to insert the RSA-Key for permissions. Maybe it is just a gui question to have a window for ea
Re: [cspace-users] Roadmap
I really wonder about thomasassta... In so many P2P projects he writes such a bunch of theorys... Or these combinations of projects... Not the way an average user does... - Original Message - From: "Sebastian Silva" <[EMAIL PROTECTED]> To: Sent: Monday, January 22, 2007 10:32 PM Subject: Re: [cspace-users] Roadmap Guys @tachyon... I have been following your mailing list and I have whitnesed you being extremely polite to "thomasassta" but he is really extremely disruptive specially now that he is taking your name in answering to users. Cspace is nice and it needs to mature and I hope I can lend a hand sometime. Meanwhile I'm watching and thanks. Just ban that guy like would be done on an IRC channel. You can post a little policy note or something. Its sad but really just look at the archives. Thanks Sebastian On 1/13/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Original-Nachricht > Datum: Sat, 13 Jan 2007 11:41:21 +0530 > Von: Jeethu Rao <[EMAIL PROTECTED]> > > > > - Cspace is not decentral, it needs a tachion server for creating an RSA > > key and it needs the Cspace-ID for the taychion server to launch the > > application. We need to change this. > > > > > Though there is a hint of truth to what you're saying, its not entirely > > true. This is probably the 3rd time I'm explaining this on cspace-users. > > > Hi Jeethu, good to know your not dead here on the list. > > > The central server is there just to maintain a persistent mapping > > between the Public Keys and the key-ids. There was no way we could > > implement atomic increments (like an autoincr field in a DB) securely in > > the DHT, and thus we had to use a centralized server for this. > > > not understood, do you mean, it is needed to establish a secure dht, then if done, we can get rid of the server? > > > This does > > not compromise the security of CSpace in any way. This one time > > registration process with the *cspace-id* can be made optional, and we haven't made > > it yet. > > Well, till know tachyion does know any Ip adress and any Nicname and any RSA-key for the nickname. This is not at all decentral. We even could not use cspace without tachyion, we are far away to be a gnutella style network. > > > Would it then be possible to create an RSA-Key without a server? > So that we seperate bootstrapping the dht and registration/RSA-Key-Creation? > > > I think it is good to have short numbers we can communicate on telephones, but what about a wesite, entering the CSpace ID and getting the RSA-Key back. > > Then Cspace can work totally without Cspace-ID, and we can use always the RSA-key, the ID-Should be just a helping box, to identify the RSA-Key. > > Second: would it be possible, to share the RSA-key = Cspace-ID in a match-atabase on the DHT ? > > So like emule kademlia, I search for the Cspace-ID and get the RSA-Key back out of the DHT, so the match could be made decentral as well. > OK Fake Clients then could provide fake matches, but this should be not a problem, as users only do this if they reinstall a system or are on vacations travelling. and if they chat then, they do get the right nic-name from the client or not, this should identify wrong matches. > > So get rid of this server and be owner of a network, not a messenger. > > > > And the application does not need to connect to the central server, > > every time its launched. The central server is only used after creating > > a new key pair and while adding a new user with a keyid (you can always > > enter the public key directly and avoid the connection to the central > > server) > > > > OK, but how, if I cannot launch the application without the cspace-ID and the server is connected... > > > > > - The question for security is as well, if you permit user "sreeram", if > > then a fake could use VNC or your PC, so the RSA-Key has to be inserted > > into the permission and not the nicname. > > > > > This simply is not possible because of the following constraints: > > All nick names in a users buddy list are guaranteed to be unique > > For any new user whose pub key is not in the user's buddy list, > > CSpace adds a "unknown-" prefix to his nickname > > > Right, I know, but it would be possible to code a client, which is not interpreting the nic-name to the saved RSA-Key for this buddy, then we would have a problem for this clone. > This is why the process has to be, to insert the RSA-Key for permissions. Maybe it is just a gui question to have a window for each buddy to set the permissions or not, or a matrix with radio-butons which sets the
Re: [cspace-users] Roadmap
Guys @tachyon... I have been following your mailing list and I have whitnesed you being extremely polite to "thomasassta" but he is really extremely disruptive specially now that he is taking your name in answering to users. Cspace is nice and it needs to mature and I hope I can lend a hand sometime. Meanwhile I'm watching and thanks. Just ban that guy like would be done on an IRC channel. You can post a little policy note or something. Its sad but really just look at the archives. Thanks Sebastian On 1/13/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Original-Nachricht Datum: Sat, 13 Jan 2007 11:41:21 +0530 Von: Jeethu Rao <[EMAIL PROTECTED]> > > - Cspace is not decentral, it needs a tachion server for creating an RSA > key and it needs the Cspace-ID for the taychion server to launch the > application. We need to change this. > > > Though there is a hint of truth to what you're saying, its not entirely > true. This is probably the 3rd time I'm explaining this on cspace-users. Hi Jeethu, good to know your not dead here on the list. > The central server is there just to maintain a persistent mapping > between the Public Keys and the key-ids. There was no way we could > implement atomic increments (like an autoincr field in a DB) securely in > the DHT, and thus we had to use a centralized server for this. not understood, do you mean, it is needed to establish a secure dht, then if done, we can get rid of the server? > This does > not compromise the security of CSpace in any way. This one time > registration process with the *cspace-id* can be made optional, and we haven't made > it yet. Well, till know tachyion does know any Ip adress and any Nicname and any RSA-key for the nickname. This is not at all decentral. We even could not use cspace without tachyion, we are far away to be a gnutella style network. Would it then be possible to create an RSA-Key without a server? So that we seperate bootstrapping the dht and registration/RSA-Key-Creation? I think it is good to have short numbers we can communicate on telephones, but what about a wesite, entering the CSpace ID and getting the RSA-Key back. Then Cspace can work totally without Cspace-ID, and we can use always the RSA-key, the ID-Should be just a helping box, to identify the RSA-Key. Second: would it be possible, to share the RSA-key = Cspace-ID in a match-atabase on the DHT ? So like emule kademlia, I search for the Cspace-ID and get the RSA-Key back out of the DHT, so the match could be made decentral as well. OK Fake Clients then could provide fake matches, but this should be not a problem, as users only do this if they reinstall a system or are on vacations travelling. and if they chat then, they do get the right nic-name from the client or not, this should identify wrong matches. So get rid of this server and be owner of a network, not a messenger. > And the application does not need to connect to the central server, > every time its launched. The central server is only used after creating > a new key pair and while adding a new user with a keyid (you can always > enter the public key directly and avoid the connection to the central > server) > OK, but how, if I cannot launch the application without the cspace-ID and the server is connected... > > - The question for security is as well, if you permit user "sreeram", if > then a fake could use VNC or your PC, so the RSA-Key has to be inserted > into the permission and not the nicname. > > > This simply is not possible because of the following constraints: > All nick names in a users buddy list are guaranteed to be unique > For any new user whose pub key is not in the user's buddy list, > CSpace adds a "unknown-" prefix to his nickname Right, I know, but it would be possible to code a client, which is not interpreting the nic-name to the saved RSA-Key for this buddy, then we would have a problem for this clone. This is why the process has to be, to insert the RSA-Key for permissions. Maybe it is just a gui question to have a window for each buddy to set the permissions or not, or a matrix with radio-butons which sets the permissions for each saved buddy in the buddylist, Ok. This has no priority. In my eyes, as the time is short and sreeram offers no deverlopment to it till now, we neew a real serverless RSA-Creation and implmenetation and if oyu like a so called Csapce-ID-nummer maybe stored in a DHT for getting the RSA-Key match. As the DHT bootstraps. the RSA-Key should be searchable with the Cspace-ID to add buddies. Last idea is to port it to java. you said, that it is not easy to port it woth jython.org to java, but if third party is interested in this, we should et least have the basic work done, which is the Serverless RSA-Key-Creation. As java is now as well open source, jython would be perfect to port the application and then we as well need no linux or other ports. just my 2 cents: Serverless RSA-L
Re: [cspace-users] Roadmap
Original-Nachricht Datum: Sat, 13 Jan 2007 11:41:21 +0530 Von: Jeethu Rao <[EMAIL PROTECTED]> > > - Cspace is not decentral, it needs a tachion server for creating an RSA > key and it needs the Cspace-ID for the taychion server to launch the > application. We need to change this. > > > Though there is a hint of truth to what you're saying, its not entirely > true. This is probably the 3rd time I'm explaining this on cspace-users. Hi Jeethu, good to know your not dead here on the list. > The central server is there just to maintain a persistent mapping > between the Public Keys and the key-ids. There was no way we could > implement atomic increments (like an autoincr field in a DB) securely in > the DHT, and thus we had to use a centralized server for this. not understood, do you mean, it is needed to establish a secure dht, then if done, we can get rid of the server? > This does > not compromise the security of CSpace in any way. This one time > registration process with the *cspace-id* can be made optional, and we > haven't made > it yet. Well, till know tachyion does know any Ip adress and any Nicname and any RSA-key for the nickname. This is not at all decentral. We even could not use cspace without tachyion, we are far away to be a gnutella style network. Would it then be possible to create an RSA-Key without a server? So that we seperate bootstrapping the dht and registration/RSA-Key-Creation? I think it is good to have short numbers we can communicate on telephones, but what about a wesite, entering the CSpace ID and getting the RSA-Key back. Then Cspace can work totally without Cspace-ID, and we can use always the RSA-key, the ID-Should be just a helping box, to identify the RSA-Key. Second: would it be possible, to share the RSA-key = Cspace-ID in a match-atabase on the DHT ? So like emule kademlia, I search for the Cspace-ID and get the RSA-Key back out of the DHT, so the match could be made decentral as well. OK Fake Clients then could provide fake matches, but this should be not a problem, as users only do this if they reinstall a system or are on vacations travelling. and if they chat then, they do get the right nic-name from the client or not, this should identify wrong matches. So get rid of this server and be owner of a network, not a messenger. > And the application does not need to connect to the central server, > every time its launched. The central server is only used after creating > a new key pair and while adding a new user with a keyid (you can always > enter the public key directly and avoid the connection to the central > server) > OK, but how, if I cannot launch the application without the cspace-ID and the server is connected... > > - The question for security is as well, if you permit user "sreeram", if > then a fake could use VNC or your PC, so the RSA-Key has to be inserted > into the permission and not the nicname. > > > This simply is not possible because of the following constraints: > All nick names in a users buddy list are guaranteed to be unique > For any new user whose pub key is not in the user's buddy list, > CSpace adds a "unknown-" prefix to his nickname Right, I know, but it would be possible to code a client, which is not interpreting the nic-name to the saved RSA-Key for this buddy, then we would have a problem for this clone. This is why the process has to be, to insert the RSA-Key for permissions. Maybe it is just a gui question to have a window for each buddy to set the permissions or not, or a matrix with radio-butons which sets the permissions for each saved buddy in the buddylist, Ok. This has no priority. In my eyes, as the time is short and sreeram offers no deverlopment to it till now, we neew a real serverless RSA-Creation and implmenetation and if oyu like a so called Csapce-ID-nummer maybe stored in a DHT for getting the RSA-Key match. As the DHT bootstraps. the RSA-Key should be searchable with the Cspace-ID to add buddies. Last idea is to port it to java. you said, that it is not easy to port it woth jython.org to java, but if third party is interested in this, we should et least have the basic work done, which is the Serverless RSA-Key-Creation. As java is now as well open source, jython would be perfect to port the application and then we as well need no linux or other ports. just my 2 cents: Serverless RSA-Launch and java porting. -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ cspace-users mailing list [email protected] http://tachyon.in/cgi-bin/mailman/listinfo/cspace-users
Re: [cspace-users] Roadmap
[EMAIL PROTECTED] wrote: Marc, we guess there is no one. Sreeram said, that he earns a lot of money with projects for industry and Jethuu Rao is even not reading the list here, as he has another project already for tachion. Sreeram wanted to employee a python (jython java) developer for cspace. But I guess it is not done, as it is an invest in open source. What we need from content: Just to set the record right, - Cspace is not decentral, it needs a tachion server for creating an RSA key and it needs the Cspace-ID for the taychion server to launch the application. We need to change this. Though there is a hint of truth to what you're saying, its not entirely true. This is probably the 3rd time I'm explaining this on cspace-users. The central server is there just to maintain a persistent mapping between the Public Keys and the key-ids. There was no way we could implement atomic increments (like an autoincr field in a DB) securely in the DHT, and thus we had to use a centralized server for this. This does not compromise the security of CSpace in any way. This one time registration process with the can be made optional, and we haven't made it yet. As with any open source project, patches are always welcome :-) And the application does not need to connect to the central server, every time its launched. The central server is only used after creating a new key pair and while adding a new user with a keyid (you can always enter the public key directly and avoid the connection to the central server) - The question for security is as well, if you permit user "sreeram", if then a fake could use VNC or your PC, so the RSA-Key has to be inserted into the permission and not the nicname. This simply is not possible because of the following constraints: All nick names in a users buddy list are guaranteed to be unique For any new user whose pub key is not in the user's buddy list, CSpace adds a "unknown-" prefix to his nickname So, if I create a user with a nick "sreeram" and try connecting to your machine, my nick will be "unknown-sreeram" and the permission rules wouldn't match. - We could have Videochat, VOIP or Multi-user-Chatrooms in. - As well filesharing with the edonkey-hash system woulöd be nice. At the moment Developer TAZ promised to make a linux source file and spec file, but he has problems with his machines, dunno, we get here a linux PC for 200 euros. We need to check, if the linux messernger is running on suse, fedora, debian, and ubuntu. then end of january we need the linux source for the fedora 7 release. The plan is to add all extra packages to the fedora core and give the distributioin to the users. so... the development will slow down and we need to get it in. As well Fedora ias the basis for the laptop.org project, where millions of them are shipped... and they still have no open source messenger added.. Hope TAZ can create a source file... Third, there is high interest to port cspace to java, so it is independent from platforms. See the jython.org newsletter for january 2007, there are already some coders starting.. The rest is not developed, until sreeram lays his hands on it. Regards Original-Nachricht Datum: Wed, 10 Jan 2007 17:12:30 +0100 Von: "Marc Nürnberger" <[EMAIL PROTECTED]> An: [email protected] Betreff: [cspace-users] Roadmap Hello everyone, I was wondering if there is some kind of roadmap for cspace. It would be nice to know on what the devs are currently working and which features are going to be implemented in the next or later releases. I would look into the source code for changes, but i'm not confident with python. And I think there are a lot people like me who are not. :) Greetings Marc Nuernberger ___ cspace-users mailing list [email protected] http://tachyon.in/cgi-bin/mailman/listinfo/cspace-users ___ cspace-users mailing list [email protected] http://tachyon.in/cgi-bin/mailman/listinfo/cspace-users
Re: [cspace-users] Roadmap
Original-Nachricht Datum: Fri, 12 Jan 2007 01:03:54 +0530 Von: Vijaya Chandra Vupputuri <[EMAIL PROTECTED]> > I sincerely hope you finally don't make people consider cspace as some > hypeware. It would be great, like people have already mentioned earlier > on the list, if only you can divert a part of your enthusiasm(to be > honest, it's amazing to see the time you seem to have spent on all the > suggestions you keep posting) to actually implementing some stuff and > stop bickering about others work. Hi Vjay cspace is hyperware. It has great potentials, if it would be really serverless. Users go to the internet to get information (surf) or to communicate (chat), to in the meanwhile know persons, so budies. The buddymarket, so a claim could be, is the internet. I see now, that it has even more potentials, if it would be in java, the we would not need to implement any function into cspace, we could implement cspace into the others apps, to get cspace shipped to a wider mass of interested people. For normal users it is indifferent, if a central server or a dht rulez their buddies. So strategy and some development is needed, if you are convinced, that it is better than a serverbased messenger. It is not about the work of others, it is about project management and the view of customers and the processes to use this software. Networking with other projects is my job, not coding. And yes, I would like to see a cspace toolbar in Thunderbird/Firefox, Cspace as a part of the Open office suite and as well as a package in fedore core 7 shipped as well to OLPC. If you regard my time, who uses the time to communicate and write tracs or open tickets? It is absurd to say to a customer, don´t open a ticket, because we have to close it then. As well it is not wrong to anser questions or to make questions. Sreeram said, he employees a jython.org coder for cspace, in 10/2006, now we have 2/2007.. If you do not even have a roadmap or are able to achive the milestonse set by yourself, the question of the User (to whom I answered with regrette) is justified. Another example: I would do a translation, but even not the question is answered, if thee will be a language file or xml-style. We could do a lot, but the developers even have no communication to the community, and with linux and integrated solutions we even could attract other developers. So why do you write to me, if the alternative would be, to let the question of the users, who asked, unanswered? Ok, then the question is still open, (And I take back my last mail.) What is the roadmap for cspace ? -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ cspace-users mailing list [email protected] http://tachyon.in/cgi-bin/mailman/listinfo/cspace-users
Re: [cspace-users] Roadmap
[EMAIL PROTECTED] wrote: Marc, - Cspace is not decentral, it needs a tachion server for creating an RSA key and it needs the Cspace-ID for the taychion server to launch the application. We need to change this. Would be great if you consider yourself as part of 'we' and make an attempt to get it done - The question for security is as well, if you permit user "sreeram", if then a fake could use VNC or your PC, so the RSA-Key has to be inserted into the permission and not the nicname. Of course it is the public key that's used for identifying a connection from a user; that should have already been clear to you considering the number of integration suggestions you have been bombarding us with. hope you haven't already given the impression to people, by your posts elsewhere, that cspace uses this 'nickname' for securely identifying connections from users. - We could have Videochat, VOIP or Multi-user-Chatrooms in. - As well filesharing with the edonkey-hash system woulöd be nice. At the moment Developer TAZ promised to make a linux source file and spec file, but he has problems with his machines, dunno, we get here a linux PC for 200 euros. Am sure taz would be glad to get a pc from you. he is volunteering to build those rpms, which he needn't if he doesn't want to, and you better not comment about his reasons for not being able to do that. Third, there is high interest to port cspace to java, so it is independent from platforms. See the jython.org newsletter for january 2007, there are already some coders starting.. The rest is not developed, until sreeram lays his hands on it. Regards Integration/plugins/ports with/for ed2k, openoffice, gaim, firefox, thunderbird, songbirdnest, backup drive, retroshare, solaris port, jabber, miranda, jython, yacy, antsp2p, limewire, azureus, wikisari - suggestions i can see from you in the archives. I sincerely hope you finally don't make people consider cspace as some hypeware. It would be great, like people have already mentioned earlier on the list, if only you can divert a part of your enthusiasm(to be honest, it's amazing to see the time you seem to have spent on all the suggestions you keep posting) to actually implementing some stuff and stop bickering about others work. Original-Nachricht Datum: Wed, 10 Jan 2007 17:12:30 +0100 Von: "Marc Nürnberger" <[EMAIL PROTECTED]> An: [email protected] Betreff: [cspace-users] Roadmap Hello everyone, I was wondering if there is some kind of roadmap for cspace. It would be nice to know on what the devs are currently working and which features are going to be implemented in the next or later releases. I would look into the source code for changes, but i'm not confident with python. And I think there are a lot people like me who are not. :) Greetings Marc Nuernberger ___ cspace-users mailing list [email protected] http://tachyon.in/cgi-bin/mailman/listinfo/cspace-users ___ cspace-users mailing list [email protected] http://tachyon.in/cgi-bin/mailman/listinfo/cspace-users
Re: [cspace-users] Roadmap
Marc, we guess there is no one. Sreeram said, that he earns a lot of money with projects for industry and Jethuu Rao is even not reading the list here, as he has another project already for tachion. Sreeram wanted to employee a python (jython java) developer for cspace. But I guess it is not done, as it is an invest in open source. What we need from content: - Cspace is not decentral, it needs a tachion server for creating an RSA key and it needs the Cspace-ID for the taychion server to launch the application. We need to change this. - The question for security is as well, if you permit user "sreeram", if then a fake could use VNC or your PC, so the RSA-Key has to be inserted into the permission and not the nicname. - We could have Videochat, VOIP or Multi-user-Chatrooms in. - As well filesharing with the edonkey-hash system woulöd be nice. At the moment Developer TAZ promised to make a linux source file and spec file, but he has problems with his machines, dunno, we get here a linux PC for 200 euros. We need to check, if the linux messernger is running on suse, fedora, debian, and ubuntu. then end of january we need the linux source for the fedora 7 release. The plan is to add all extra packages to the fedora core and give the distributioin to the users. so... the development will slow down and we need to get it in. As well Fedora ias the basis for the laptop.org project, where millions of them are shipped... and they still have no open source messenger added.. Hope TAZ can create a source file... Third, there is high interest to port cspace to java, so it is independent from platforms. See the jython.org newsletter for january 2007, there are already some coders starting.. The rest is not developed, until sreeram lays his hands on it. Regards Original-Nachricht Datum: Wed, 10 Jan 2007 17:12:30 +0100 Von: "Marc Nürnberger" <[EMAIL PROTECTED]> An: [email protected] Betreff: [cspace-users] Roadmap > Hello everyone, > > I was wondering if there is some kind of roadmap for cspace. It would be > nice to know on what the devs are currently working and which features > are going to be implemented in the next or later releases. I would look > into the source code for changes, but i'm not confident with python. And > I think there are a lot people like me who are not. :) > > Greetings > > Marc Nuernberger > > ___ > cspace-users mailing list > [email protected] > http://tachyon.in/cgi-bin/mailman/listinfo/cspace-users -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ cspace-users mailing list [email protected] http://tachyon.in/cgi-bin/mailman/listinfo/cspace-users
