cxtable-devel Mailing List for xTable: Serverless Network
Status: Alpha
Brought to you by:
xiarcel
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(13) |
Dec
(70) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(28) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Williams, D. <DAV...@ca...> - 2002-06-07 17:21:12
|
Just for anyone listening... Anxious to get back to this project...I have a pending 1.0 release of Dustyscript, the Children's Scripting Language I have been writing (and intensively tracking for a 1.0 release candidate at the beginning of July, and a 1.0 stabile at the end of july)... it has absorbed more of my time that I really had imagined... So...anyone with any ideas or feedback..now is the time to voice them :-) ~Dave David Scott Williams Inside Sales Executive Customer Interaction Center Computer Associates One Computer Associates Plaza Islandia, New York 11749 tel: +1 800-243-9462 ext. 73431 tel: +1 631-342-3431 (Direct) fax: +1 631-342-5734 wi...@ca... |
From: <xi...@pr...> - 2002-01-13 04:05:56
|
Hey... This program, if run with a "insert_public" arg will insert the public declaration in front of a "class XXX" in Java If run with a "make" arg, it will recurse through and create in the directory it was run from a .java source called MakeFromSource.java, which, if compiled, will force a recursive compile (even with the packages) of all of the Java sources. I have like 70 sources for cxtable..and part of freeing up my time is getting them to compile as a package. voila... |
From: Borne Goodman-M. <bj...@gl...> - 2002-01-13 00:29:11
|
As long as the packages / imports / and your CLASSPATH are set correctly there should be no problem, so I suggest the problem is in one of those three areas. javac is very smart about compilation dependencies and as long as the above is set up correctly, I have never seen a problem. --bjgm On Sat, 2002-01-12 at 18:23, David Scott Williams wrote: > I got the package * stuff done > I got the import cxtable....... stuff done > > However, it won't compile. > > If you go to compile one, it won't see the other, because the other's > package hasn't been compiled.. > > A needs C, C needs B, B needs A.. > > Any ideas? > > > -- > ~Dave > xi...@pr... > http://sourceforge.net/projects/cxtable >The xTable Project< > http://sourceforge.net/projects/dustyscript >Dustyscript Child Script > Language< > http://sourceforge.net/projects/grapevine >Grapevine p2p network< > http://sourceforge.net/projects/symbiosis >Symbiosis< > http://sourceforge.net/projects/freeblogger >Freeblogging Weblog project > > [temporary weblog: > |>>http://www.geocities.com/xiarcel/weblogs/log.html<<| ] > > > "When I think back on all the crap I learned in High School... > it's a wonder I can think at all..." > -Paul Simon, "Kodachrome" > > > > _______________________________________________ > Cxtable-devel mailing list > Cxt...@li... > https://lists.sourceforge.net/lists/listinfo/cxtable-devel |
From: David S. W. <xi...@pr...> - 2002-01-12 23:13:33
|
I got the package * stuff done I got the import cxtable....... stuff done However, it won't compile. If you go to compile one, it won't see the other, because the other's package hasn't been compiled.. A needs C, C needs B, B needs A.. Any ideas? -- ~Dave xi...@pr... http://sourceforge.net/projects/cxtable >The xTable Project< http://sourceforge.net/projects/dustyscript >Dustyscript Child Script Language< http://sourceforge.net/projects/grapevine >Grapevine p2p network< http://sourceforge.net/projects/symbiosis >Symbiosis< http://sourceforge.net/projects/freeblogger >Freeblogging Weblog project [temporary weblog: |>>http://www.geocities.com/xiarcel/weblogs/log.html<<| ] "When I think back on all the crap I learned in High School... it's a wonder I can think at all..." -Paul Simon, "Kodachrome" |
From: Borne Goodman-M. <bj...@gl...> - 2002-01-08 01:29:01
|
Classes outside of the context of your "local" package are never picked up without an import statement. This said, if I am a class in the cxtable package, I do need to import cxtable.core_comm.* and cxtable.gui.* if I want to use classes in those packages. If I am a class in the package cxtable.gui, and I am used by a class in cxtable.core_comm, I do not need to import cxtable.core_comm. I would only need to do that if I use a class from cxtable.core_comm. So, to summarize, you need to import any class outside of your "local" scope, and you never need to import a class that you don't use, even if it uses you. I hope that was clear :) --bjgm On Mon, 2002-01-07 at 18:35, Williams, David wrote: > ok...This is still my baby project for awhile, you know... I have some unfinished/unresolved things here... So.. pardon me if I still ask a question on this list :-) > > If a class in package cxtable.* happens to import from another package (cxtable.core_comm.*) does it need an import? > > Similarly, does cxtable.core_comm.XXX need to import cxtable.*, or is it implicitly there already? I know that cxtable.core_comm.XXX would need to import cxtable.gui.* or cxtable.WHATEVER.* if it needed a package that was of parallel depth to itself...but... does it need to import backwards? > > ~Dave > > > David Scott Williams > Computer Associates > Marketing Representative-Sales Call Center > One Computer Associates Plaza > Islandia, New York 11749 > tel: +1 800-243-9462 ext. 73431 > tel: +1 631-342-3431 (Direct) > fax: +1 631-342-5734 > wi...@ca... > > > _______________________________________________ > Cxtable-devel mailing list > Cxt...@li... > https://lists.sourceforge.net/lists/listinfo/cxtable-devel |
From: Williams, D. <DAV...@ca...> - 2002-01-07 23:38:31
|
ok...This is still my baby project for awhile, you know... I have some unfinished/unresolved things here... So.. pardon me if I still ask a question on this list :-) If a class in package cxtable.* happens to import from another package (cxtable.core_comm.*) does it need an import? Similarly, does cxtable.core_comm.XXX need to import cxtable.*, or is it implicitly there already? I know that cxtable.core_comm.XXX would need to import cxtable.gui.* or cxtable.WHATEVER.* if it needed a package that was of parallel depth to itself...but... does it need to import backwards? ~Dave David Scott Williams Computer Associates Marketing Representative-Sales Call Center One Computer Associates Plaza Islandia, New York 11749 tel: +1 800-243-9462 ext. 73431 tel: +1 631-342-3431 (Direct) fax: +1 631-342-5734 wi...@ca... |
From: Williams, D. <DAV...@ca...> - 2002-01-03 21:38:35
|
I don't think they'd listen to me.. David Scott Williams Computer Associates --->Marketing Representative-Sales Call Center<--- One Computer Associates Plaza Islandia, New York 11749 tel: +1 800-243-9462 ext. 73431 tel: +1 631-342-3431 (Direct) fax: +1 631-342-5734 wi...@ca... -----Original Message----- From: Borne Goodman-Mace [mailto:bm...@eg...] Sent: Thursday, January 03, 2002 4:28 PM To: Williams, David Subject: RE: [Cxtable-devel] RE: Can you help me guage how long this'd tak e? Other than having to download the JRE, because of it's interpreted nature, I believe you would find a Java program (it's .class files), are generally much smaller than C code which does the same thing. It also (usually) takes a lot less Java code (and time) to write the same thing as you would in C. I will attempt to address them as well as I can. Network IO, in Java, can be similar in performance, though I don't know the exact percentage difference. One of the huge wastes in Java networking IO, previous to version 1.4, was that you had to spawn a thread (or jump through other horrible hoops), to efficiently handle client IO. The 1.4 NIO libraries do a great deal to bring Java up to C / C++ speeds in this regards. It is also VERY painful to port complex network code between Windoze and Unix, as the Grapevine folks will find out, if they don't know already. I haven't seen a good (and fast) implementation of crypto in Java that didn't use JNI for the hard core stuff. I think this is more a lacking in the implementations than in Java's abilities, but the big problem caused by the bad implementation is the use of a TON of CPU cycles. When running a 2ghz processor (and faster in the future), even a bad crypto implementation with 4096 keys will run pretty well in Java. Because of this issue, when dealing with web traffic, or SSL streams in general, if performance is important, it is best to tunnel this through some kind of native SSL stream (ssh, https, etc). If you want to work for your company, and that is all they write in, then true, the bullet must be bitten, unless you can convince them to work on a conversion of some components to Java. I know it sounds far fetched, but in my early years, I convinced 2 separate companies that I worked for to start developing in Java, before it was "hot", and they never went back. --bjgm On Thu, 2002-01-03 at 15:14, Williams, David wrote: > Well..one of the reasons (and I wasn't entirely certain that this was correct, at the time) that Grapevine is working in C++, is a smaller, quicker, executable.... > > I, of course, wondered how much sense this made... > > I do have some questions/issues with Java that perhaps you can address for me? > > Sockets and Secure Sockets... and all that.. They run at 90% of a well-written C socks program? > > More importantly, would there be any advantage as far as tunneling through FWs and Proxies in C versus Java? Or are these distinctions that I've drawn up in my head? > > Also..my company writes in C/C++... They, of course, create closed-source, high-priced 'eBusiness' software... > > I might want to work for them programming, but at this point, since I don't write C and Assembler, I haven't a chance.. |
From: Borne Goodman-M. <bm...@eg...> - 2002-01-03 21:32:31
|
I have seen a WM written in Java that supports X, and I even tried it out once. I was running on a PII 400, and it wasn't all that peppy, but like I said, the speed of CPUs is increasing very rapidly, and I think things like this, and even a complete OS written in java (I helped out a project, called JOS, the Java Operating System, which is working toward this goal) is not out of the question. --bjgm On Thu, 2002-01-03 at 15:38, Williams, David wrote: > Well...here's a question then... > > If we had a good enough, fast enough, tight enough runtime, wouldn't it make sense to make an ENTIRE desktop in Java...for Linux? > > startx could pull up an empty X, and run > > /usr/java/bin/java KickAssDesktop > > And... voila! > > David Scott Williams > Computer Associates > Marketing Representative-Sales Call Center > One Computer Associates Plaza > Islandia, New York 11749 > tel: +1 800-243-9462 ext. 73431 > tel: +1 631-342-3431 (Direct) > fax: +1 631-342-5734 > wi...@ca... > > |
From: Williams, D. <DAV...@ca...> - 2002-01-03 20:51:55
|
Well...here's a question then... If we had a good enough, fast enough, tight enough runtime, wouldn't it make sense to make an ENTIRE desktop in Java...for Linux? startx could pull up an empty X, and run /usr/java/bin/java KickAssDesktop And... voila! David Scott Williams Computer Associates Marketing Representative-Sales Call Center One Computer Associates Plaza Islandia, New York 11749 tel: +1 800-243-9462 ext. 73431 tel: +1 631-342-3431 (Direct) fax: +1 631-342-5734 wi...@ca... |
From: <xi...@pr...> - 2002-01-03 20:16:57
|
For self-taught, non-certified Java hackers? |
From: Borne Goodman-M. <bm...@eg...> - 2002-01-03 18:05:12
|
The question is a simple one, and the answer is as well, and it seems to me, based on the comments I read, that most people agree. It is not the place of Object Orientation to make adding 2 + 2 (or a more complex function / calculation) better / stronger / faster, and the implementation, in software, of said solutions ends up looking, in Java, much like it did in C. The real gain is, when dealing with a huge system which is made up of thousands of these computations (which are perhaps even distributed across a network), it can be put together in a more elegant / logical way than just throwing all the functions into one big .c file, or or a bunch of them, and declaring them as global. --bjgm On Thu, 2002-01-03 at 12:24, Williams, David wrote: > http://slashdot.org/article.pl?sid=01/12/29/0455204&mode=thread > > Above is an article on slashdot about OOP > > > David Scott Williams > Computer Associates > Marketing Representative-Sales Call Center > One Computer Associates Plaza > Islandia, New York 11749 > tel: +1 800-243-9462 ext. 73431 > tel: +1 631-342-3431 (Direct) > fax: +1 631-342-5734 > wi...@ca... > > > _______________________________________________ > Cxtable-devel mailing list > Cxt...@li... > https://lists.sourceforge.net/lists/listinfo/cxtable-devel > |
From: Williams, D. <DAV...@ca...> - 2002-01-03 17:38:10
|
http://slashdot.org/article.pl?sid=01/12/29/0455204&mode=thread Above is an article on slashdot about OOP David Scott Williams Computer Associates Marketing Representative-Sales Call Center One Computer Associates Plaza Islandia, New York 11749 tel: +1 800-243-9462 ext. 73431 tel: +1 631-342-3431 (Direct) fax: +1 631-342-5734 wi...@ca... |
From: Williams, D. <DAV...@ca...> - 2002-01-03 16:51:53
|
has "symbiosis" been taken? David Scott Williams Computer Associates Marketing Representative-Sales Call Center One Computer Associates Plaza Islandia, New York 11749 tel: +1 800-243-9462 ext. 73431 tel: +1 631-342-3431 (Direct) fax: +1 631-342-5734 wi...@ca... -----Original Message----- From: Williams, David Sent: Thursday, January 03, 2002 11:30 AM To: cxt...@li... Subject: [Cxtable-devel] RE:p2p, the next generation..brainstorm Are you thinking with "table" in the name, or not? Using standard marketing rules.. 1-The name, though, should reflect its purpose completely and utterly... 2- If you are to break rule 1 even slightly, then the name should in NO WAY reflect the purpose. (In other words...either something related to p2p thats snappy, or TidalWave) David Scott Williams Computer Associates Marketing Representative-Sales Call Center One Computer Associates Plaza Islandia, New York 11749 tel: +1 800-243-9462 ext. 73431 tel: +1 631-342-3431 (Direct) fax: +1 631-342-5734 wi...@ca... -----Original Message----- From: Borne Goodman-Mace [mailto:bm...@eg...] Sent: Thursday, January 03, 2002 11:20 AM To: Williams, David Subject: RE: [Cxtable-devel] RE:p2p, the next generation [small reply] Excellent. Very happy to be working with you :). I will try to work on a more "formal" document in which I "as clearly as possible" express the architecture, based on both my initial email, and our discussions since, and, simultaneously, brainstorm names, and please feel free to kick in any ideas you have, at any time! --bjgm On Thu, 2002-01-03 at 10:06, Williams, David wrote: > Of course... I would love to assist with the coding of this effort... I think, though, that you would have to take the lead at first, to demonstrate where and how you wish to proceed more concretely... > > I would love to be a part of it, no matter which "project name" it falls under... > > > David Scott Williams > Computer Associates > Marketing Representative-Sales Call Center > One Computer Associates Plaza > Islandia, New York 11749 > tel: +1 800-243-9462 ext. 73431 > tel: +1 631-342-3431 (Direct) > fax: +1 631-342-5734 > wi...@ca... > > > > > > > -----Original Message----- > From: Borne Goodman-Mace [mailto:bj...@pe...] > Sent: Wednesday, January 02, 2002 11:37 PM > To: Williams, David > Subject: RE: [Cxtable-devel] RE:p2p, the next generation [small reply] > > > I will end up working on this with or without any assistance, so if you > would rather remain a brainstomer with me on this, then that is fine > with me as well, and the amount of time I will be able to spend hacking > on it will be completely dependent on the amount of activity at work, > and the amount of time I have to spend at home working on "work stuff". > > I do rather like the table inference myself, as you can put stuff on a > table, talk across a table, etc.... though I think some of the future > service I have in mind go a bit beyond the table paradigm. > > I have a "vision", and though a large step, this is project would simply > be the first one, but the most important thing, as I mentioned in an > email a few weeks ago, is to have a very solid foundation upon which to > build. > > I want to do this not only for my own sake (and the huge amount of FUN I > think it is going to be, and a HUGE amount of cool stuff will be learned > as well), but also to benefit as many people as possible out there. To > make it mindlessly easy to have your own, secure, and redundant web > server running on your own system. To chat and share data and ideas > with friends all over the world, etc.. etc... > > OMInit did initially stand for the Open Mind Initiative, and I was going > to use that name for an evolutionary system of distributed networking / > services, but I found out that name was already used somewhere else, > after I created the sourceforge project, and ended up doing something > else with it (the chat / arena thing now called open mud initiative). > > I do also happen to own ominit.org (and penguinfury.com :)... ), so as > far as names go, currently I haven't the foggiest, and haven't spend > much time since I wrote my initial email to you about the idea thinking > about it.... > > I think since we are dirtied our CVS waters already though, with both > ominit and cxtable, we need to start something fresh, and try to build > our code tree correctly the first time. > > It is really annoying that I can't go in and clean out the old > directories :(. > > Anyway, babbling again... hope you are having a great evening, > > --bjgm > > On Wed, 2002-01-02 at 18:01, Williams, David wrote: > > I suppose that I always new that a re-write might come into play at some point.. (Plan to throw one, or two, away..you will anyway...).. > > > > I do not out of hand object to a re-write...but at the same time, I do not rush toward it either... > > > > Relating to "the vision"... whew! You're closer to mine than Stephen's... :-) > > > > But, on a slightly more serious note, the vision, as presented, seems like a potential logical next step to go... In some ways, I would be stepping away from the project admin role, and stepping back for awhile, becoming one code warrior among many on the project.. > > > > I happen to like the name "xTable"... as the "x" represents ANYTHING.... it being a universal variable, and all..and it represents many different things and people brought "to the table"... a table, like...people sitting and sipping coffee...or people sitting and playing a nice game of Dungeons and Dragons, or Poker, or Chess... or planning something (like a board room table. etc..)... Perhaps that is one of the reasons why continuing under the cxtable namespace makes sense to your project as well as mine... > > > > > > I will read the longer reply, and reply to that... > > > > > > David Scott Williams > > Computer Associates > > Marketing Representative-Sales Call Center > > One Computer Associates Plaza > > Islandia, New York 11749 > > tel: +1 800-243-9462 ext. 73431 > > tel: +1 631-342-3431 (Direct) > > fax: +1 631-342-5734 > > wi...@ca... > > > > > > > > > > > > > > -----Original Message----- > > From: Borne Goodman-Mace [mailto:bm...@eg...] > > Sent: Wednesday, January 02, 2002 5:11 PM > > To: cxt...@li... > > Subject: Re: [Cxtable-devel] RE:p2p, the next generation [small reply] > > > > > > I am indeed not 100% clear on where cxtable's current implementation > > exists within the space of my vision, which was developed out of > > self-introspection, and a lot of experience, and an understanding (I > > think) of the optimal mechanism for information sharing / communication. > > > > I have always love the concept of having systems communicate with each > > other over the network, in much the way that humans do in the physical > > world. I think that improvements can be made, technologically, to the > > way we traditionally communicate, and this vision is the beginning down > > that path for me (and whomever might like to come with me). > > > > I do understand, basically, how the cxtable system currently works, from > > a networking perspective, and I do feel there is a sizable amount of > > > re-work to be done to make the changes I suggested to it. So much work > > in fact, especially in the case of sticking in security, that it might > > be faster to start from scratch, but this is not a certainty at this > > point. cxtable is a system that you developed from the ground up (with > > some help here and there) and it is a fairly large derivation from the > > way things work now, which is why I would understand if you aren't > > interested in my ideas and would rather pursue your own. > > > > It is rare that people can work together with common purpose / vision to > > develop a great piece of software, and I find my ideas are usually a bit > > lofty for a lot of people to consider reasonable, and they would rather > > write something very particular (like a shared data space / > > "grapevine"). > > > > I do believe, after a summary look at the "grapevine" project, that our > > thoughts are a bit closer, than that of grapevine, though I think that > > kind of capability could easily be put into the framework I have in > > mind. > > > > I shall respond to your other email, with more detailed answers to your > > questions about my initial email, to better describe what my concepts of > > a client / server / service truly represent and I will also try to give > > some examples of it's usage to more easily put the components in their > > correct context. > > > > --bjgm > > > > On Wed, 2002-01-02 at 15:51, Williams, David wrote: > > > Larger one to follow, after I've better read through your thoughts... > > > > > > This reply is mainly to ask a few questions, which might or might not be self-serving... > > > > > > Are you clear on where cxtable sits with relation to this vision? In other words, do these visions come from self-introspection with relation to the internet itself, or with some digging about in my code, a mixture? > > > > > > I ask this only to see whether you have come up with an assessment of how cxtable accomplishes p2p... I also ask it because there is another project that is working toward peer-to-peer that I have been impressed with.... They are primarily looking to create a persistent file storage network across anonymous peer-to-peer... It is grapevine.sourceforge.net... > > > > > > I almost reticently point you at it, as Stephen and I are approaching two different goals, and I am unsure of whether or not his is closer to yours than mine... > > > > > > Primarily, I am wondering, what adaptation would be required, on my part... I assume, in many ways, everything after the "line" in your message will explain that to me..so I will read it, and reply again... > > > > > > Either way, your help has been valuable to me... (Again... I hope that by pointing you toward Grapevine- a class act, I have not found you a new project to replace your participation in mine... but Stephen, et al, of the Grapevine project are way deserving of help, as well..) > > > > > > ~Dave > > > > > > > > > > > > David Scott Williams > > > Computer Associates > > > Marketing Representative-Sales Call Center > > > One Computer Associates Plaza > > > Islandia, New York 11749 > > > tel: +1 800-243-9462 ext. 73431 > > > tel: +1 631-342-3431 (Direct) > > > fax: +1 631-342-5734 > > > wi...@ca... > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Borne Goodman-Mace [mailto:bm...@eg...] > > > Sent: Wednesday, January 02, 2002 3:38 PM > > > To: cxt...@li... > > > Subject: [Cxtable-devel] p2p, the next generation. > > > > > > > > > Greetings, > > > > > > As I mentioned to you, my interest in the cxtable project is mainly due > > > to my feelings about the proper direction for applications / knowledge > > > sharing in the future, and that the next step is to create a system > > > which is neither purely p2p nor purely client/server. > > > > > > I have spent a bit of time in the last few days thinking about exactly > > > what this system should look / act like, and would like to explain this, > > > and do one of two things with this knowledge, based on your feelings. > > > > > > 1) Change cxtable to adapt to a slightly different vision, which > > > included the concepts I am going to present, at which point I will drop > > > my work on OMInit. > > > > > > 2) Continue to work om OMInit and evolve it to also support the concepts > > > which I am going to present, and continue to give information / > > > assistance on cxtable when possible. > > > > > > The following concepts are rough, and certainly open to discussion / > > > evolution, but I think are a basis for an excellent system which should > > > be enjoyed greatly by many. > > > > > > ------------------------------------------------------------------------- > > > > > > The main weakness, in my observation, of a pure p2p system, is that to > > > gain access to particular data, the peer you want to communicate with > > > needs to be available. Some systems have gotten around single peer > > > failure by persisting the data to all peers, but this is a horrible disk > > > (and bandwidth) hog. The solution is the following design, where each > > > piece of software can work as a client or a server. Each server would > > > have a set of available "services". The service and it's associated > > > data can be linked to a service on another "peer" to create redundancy > > > in case of failure. One service is the "master" and the other is a > > > "backup". There can be an unlimited number of backups for a particular > > > service, but obviously as that number increases so does the bandwidth > > > usage to keep the backups up-to-date. > > > > > > Think of a service in the current cxtable context as a plug-in. > > > > > > TheServer > > > --------- > > > A system only act's as a server if it has a service (in either master or > > > backup mode) running. Each service can use either TCP or UDP as it's > > > transport mechanism, and the server is in charge of doing the transport > > > listening, and hands off the connections to the service. > > > > > > The server should also support persistence of service data, and also > > > service "backup" monitoring / updating. This should make writing new > > > services / plug-in's as simple as possible. > > > > > > TheService > > > ---------- > > > The service would get the data from clients (as either byte arrays, > > > string arrays, or java objects (based on xml parsing)) through the > > > server, and handle it appropriately. They would be able to persist data > > > by making calls into the server which it is wrapped in, and if there are > > > "backup" services for this service, it's data is sent to those > > > automatically to be persisted. > > > > > > TheClient > > > --------- > > > The client would initially discover all services it is interested in > > > (see ServiceDiscovery) and a list of "master" services (and the server > > > they are connected to) is shown to the user. The User can then choose > > > to connect to a particular service. There would be client software > > > related to each service, and it would even be possible to have software > > > which could handle communication to more than one type of service. The > > > client "plug-in" would register itself with the client, and if there was > > > more than one client which could connect to a particular service, that > > > list would come up for the user to choose which one they wanted to use > > > (a default could be set so the list wouldn't come up). > > > > > > > > > ServiceDiscovery > > > ---------------- > > > There would be multiple modes of service discovery, all of which can be > > > configured / enabled / disabled. One would be a multicast message sent > > > to the local network. Each Server hearing the message would respond > > > with a list of it's available services. > > > > > > A client could have a set of IP addresses which it would connect to via > > > a proprietary protocol to determine the available services. This would > > > be used if the server / services are not on the local network. > > > > > > A set of URLs could be scanned, using a technique very much like is in > > > place for cxtable now, to determine a set of IP addresses which can be > > > connected to and asked about available services. > > > > > > Persistence > > > ----------- > > > There would be a generic set of methods to persist data. These would > > > link into a set of implementations, each of which would have a name > > > associated to it. This would allow multiple persistence schemes to be > > > used simultaneously. For example, a service could persist data to an > > > implementation called "cxtable.persist.mysql.chess" which would be > > > linked into a Class which uses JDBC to communicate to a MySQL database, > > > and the chess database within MySQL. In addition to JDBC > > > implementations, an XML implementation and flat file implementation > > > should be done at a minimum. > > > > > > These would be implemented through an interface, so 3rd parties could > > > implement alternative persistence schemes. > > > > > > > > > Security / Service Ownership > > > ---------------------------- > > > In the long run, I would suggest the use of a Public / Private Key > > > system which encrypts all communication between all of the objects in > > > the architecture. Initially this will not be implemented, but the > > > methods must be in place to do this so that it is designed from the > > > beginning to support this, rather than retro-fitting it in after the > > > initial implementation. > > > > > > Peers would, through some mechanism, exchange public keys. Each public > > > key would be related to a particular user name. A password will be > > > generated by the user, encrypted, and sent to the peer. The password > > > will be checked against the peer's data (which is encrypted locally) to > > > determine authentication. > > > > > > All data (including discovery messages) will be encrypted, so that only > > > a server can determine, based on the user's identity, what services are > > > available to them. > > > > > > ----------------------------------------------------------------------- > > > > > > I don't believe I have seen a system which supports all (or even half) > > > of the functionality which I have mentioned in this email, and I don't > > > consider it horribly outrageous that we may attempt to do this. I will > > > end up attempting to do this regardless, but another mind to bounce > > > things off of, as you know, is always a nice thing. > > > > > > > > > _______________________________________________ > > > Cxtable-devel mailing list > > > Cxt...@li... > > > https://lists.sourceforge.net/lists/listinfo/cxtable-devel > > > > > > _______________________________________________ > > > Cxtable-devel mailing list > > > Cxt...@li... > > > https://lists.sourceforge.net/lists/listinfo/cxtable-devel > > > > > > > > > > > _______________________________________________ > > Cxtable-devel mailing list > > Cxt...@li... > > https://lists.sourceforge.net/lists/listinfo/cxtable-devel > > _______________________________________________ Cxtable-devel mailing list Cxt...@li... https://lists.sourceforge.net/lists/listinfo/cxtable-devel |
From: Williams, D. <DAV...@ca...> - 2002-01-03 16:39:06
|
Are you thinking with "table" in the name, or not? Using standard marketing rules.. 1-The name, though, should reflect its purpose completely and utterly... 2- If you are to break rule 1 even slightly, then the name should in NO WAY reflect the purpose. (In other words...either something related to p2p thats snappy, or TidalWave) David Scott Williams Computer Associates Marketing Representative-Sales Call Center One Computer Associates Plaza Islandia, New York 11749 tel: +1 800-243-9462 ext. 73431 tel: +1 631-342-3431 (Direct) fax: +1 631-342-5734 wi...@ca... -----Original Message----- From: Borne Goodman-Mace [mailto:bm...@eg...] Sent: Thursday, January 03, 2002 11:20 AM To: Williams, David Subject: RE: [Cxtable-devel] RE:p2p, the next generation [small reply] Excellent. Very happy to be working with you :). I will try to work on a more "formal" document in which I "as clearly as possible" express the architecture, based on both my initial email, and our discussions since, and, simultaneously, brainstorm names, and please feel free to kick in any ideas you have, at any time! --bjgm On Thu, 2002-01-03 at 10:06, Williams, David wrote: > Of course... I would love to assist with the coding of this effort... I think, though, that you would have to take the lead at first, to demonstrate where and how you wish to proceed more concretely... > > I would love to be a part of it, no matter which "project name" it falls under... > > > David Scott Williams > Computer Associates > Marketing Representative-Sales Call Center > One Computer Associates Plaza > Islandia, New York 11749 > tel: +1 800-243-9462 ext. 73431 > tel: +1 631-342-3431 (Direct) > fax: +1 631-342-5734 > wi...@ca... > > > > > > > -----Original Message----- > From: Borne Goodman-Mace [mailto:bj...@pe...] > Sent: Wednesday, January 02, 2002 11:37 PM > To: Williams, David > Subject: RE: [Cxtable-devel] RE:p2p, the next generation [small reply] > > > I will end up working on this with or without any assistance, so if you > would rather remain a brainstomer with me on this, then that is fine > with me as well, and the amount of time I will be able to spend hacking > on it will be completely dependent on the amount of activity at work, > and the amount of time I have to spend at home working on "work stuff". > > I do rather like the table inference myself, as you can put stuff on a > table, talk across a table, etc.... though I think some of the future > service I have in mind go a bit beyond the table paradigm. > > I have a "vision", and though a large step, this is project would simply > be the first one, but the most important thing, as I mentioned in an > email a few weeks ago, is to have a very solid foundation upon which to > build. > > I want to do this not only for my own sake (and the huge amount of FUN I > think it is going to be, and a HUGE amount of cool stuff will be learned > as well), but also to benefit as many people as possible out there. To > make it mindlessly easy to have your own, secure, and redundant web > server running on your own system. To chat and share data and ideas > with friends all over the world, etc.. etc... > > OMInit did initially stand for the Open Mind Initiative, and I was going > to use that name for an evolutionary system of distributed networking / > services, but I found out that name was already used somewhere else, > after I created the sourceforge project, and ended up doing something > else with it (the chat / arena thing now called open mud initiative). > > I do also happen to own ominit.org (and penguinfury.com :)... ), so as > far as names go, currently I haven't the foggiest, and haven't spend > much time since I wrote my initial email to you about the idea thinking > about it.... > > I think since we are dirtied our CVS waters already though, with both > ominit and cxtable, we need to start something fresh, and try to build > our code tree correctly the first time. > > It is really annoying that I can't go in and clean out the old > directories :(. > > Anyway, babbling again... hope you are having a great evening, > > --bjgm > > On Wed, 2002-01-02 at 18:01, Williams, David wrote: > > I suppose that I always new that a re-write might come into play at some point.. (Plan to throw one, or two, away..you will anyway...).. > > > > I do not out of hand object to a re-write...but at the same time, I do not rush toward it either... > > > > Relating to "the vision"... whew! You're closer to mine than Stephen's... :-) > > > > But, on a slightly more serious note, the vision, as presented, seems like a potential logical next step to go... In some ways, I would be stepping away from the project admin role, and stepping back for awhile, becoming one code warrior among many on the project.. > > > > I happen to like the name "xTable"... as the "x" represents ANYTHING.... it being a universal variable, and all..and it represents many different things and people brought "to the table"... a table, like...people sitting and sipping coffee...or people sitting and playing a nice game of Dungeons and Dragons, or Poker, or Chess... or planning something (like a board room table. etc..)... Perhaps that is one of the reasons why continuing under the cxtable namespace makes sense to your project as well as mine... > > > > > > I will read the longer reply, and reply to that... > > > > > > David Scott Williams > > Computer Associates > > Marketing Representative-Sales Call Center > > One Computer Associates Plaza > > Islandia, New York 11749 > > tel: +1 800-243-9462 ext. 73431 > > tel: +1 631-342-3431 (Direct) > > fax: +1 631-342-5734 > > wi...@ca... > > > > > > > > > > > > > > -----Original Message----- > > From: Borne Goodman-Mace [mailto:bm...@eg...] > > Sent: Wednesday, January 02, 2002 5:11 PM > > To: cxt...@li... > > Subject: Re: [Cxtable-devel] RE:p2p, the next generation [small reply] > > > > > > I am indeed not 100% clear on where cxtable's current implementation > > exists within the space of my vision, which was developed out of > > self-introspection, and a lot of experience, and an understanding (I > > think) of the optimal mechanism for information sharing / communication. > > > > I have always love the concept of having systems communicate with each > > other over the network, in much the way that humans do in the physical > > world. I think that improvements can be made, technologically, to the > > way we traditionally communicate, and this vision is the beginning down > > that path for me (and whomever might like to come with me). > > > > I do understand, basically, how the cxtable system currently works, from > > a networking perspective, and I do feel there is a sizable amount of > > > re-work to be done to make the changes I suggested to it. So much work > > in fact, especially in the case of sticking in security, that it might > > be faster to start from scratch, but this is not a certainty at this > > point. cxtable is a system that you developed from the ground up (with > > some help here and there) and it is a fairly large derivation from the > > way things work now, which is why I would understand if you aren't > > interested in my ideas and would rather pursue your own. > > > > It is rare that people can work together with common purpose / vision to > > develop a great piece of software, and I find my ideas are usually a bit > > lofty for a lot of people to consider reasonable, and they would rather > > write something very particular (like a shared data space / > > "grapevine"). > > > > I do believe, after a summary look at the "grapevine" project, that our > > thoughts are a bit closer, than that of grapevine, though I think that > > kind of capability could easily be put into the framework I have in > > mind. > > > > I shall respond to your other email, with more detailed answers to your > > questions about my initial email, to better describe what my concepts of > > a client / server / service truly represent and I will also try to give > > some examples of it's usage to more easily put the components in their > > correct context. > > > > --bjgm > > > > On Wed, 2002-01-02 at 15:51, Williams, David wrote: > > > Larger one to follow, after I've better read through your thoughts... > > > > > > This reply is mainly to ask a few questions, which might or might not be self-serving... > > > > > > Are you clear on where cxtable sits with relation to this vision? In other words, do these visions come from self-introspection with relation to the internet itself, or with some digging about in my code, a mixture? > > > > > > I ask this only to see whether you have come up with an assessment of how cxtable accomplishes p2p... I also ask it because there is another project that is working toward peer-to-peer that I have been impressed with.... They are primarily looking to create a persistent file storage network across anonymous peer-to-peer... It is grapevine.sourceforge.net... > > > > > > I almost reticently point you at it, as Stephen and I are approaching two different goals, and I am unsure of whether or not his is closer to yours than mine... > > > > > > Primarily, I am wondering, what adaptation would be required, on my part... I assume, in many ways, everything after the "line" in your message will explain that to me..so I will read it, and reply again... > > > > > > Either way, your help has been valuable to me... (Again... I hope that by pointing you toward Grapevine- a class act, I have not found you a new project to replace your participation in mine... but Stephen, et al, of the Grapevine project are way deserving of help, as well..) > > > > > > ~Dave > > > > > > > > > > > > David Scott Williams > > > Computer Associates > > > Marketing Representative-Sales Call Center > > > One Computer Associates Plaza > > > Islandia, New York 11749 > > > tel: +1 800-243-9462 ext. 73431 > > > tel: +1 631-342-3431 (Direct) > > > fax: +1 631-342-5734 > > > wi...@ca... > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Borne Goodman-Mace [mailto:bm...@eg...] > > > Sent: Wednesday, January 02, 2002 3:38 PM > > > To: cxt...@li... > > > Subject: [Cxtable-devel] p2p, the next generation. > > > > > > > > > Greetings, > > > > > > As I mentioned to you, my interest in the cxtable project is mainly due > > > to my feelings about the proper direction for applications / knowledge > > > sharing in the future, and that the next step is to create a system > > > which is neither purely p2p nor purely client/server. > > > > > > I have spent a bit of time in the last few days thinking about exactly > > > what this system should look / act like, and would like to explain this, > > > and do one of two things with this knowledge, based on your feelings. > > > > > > 1) Change cxtable to adapt to a slightly different vision, which > > > included the concepts I am going to present, at which point I will drop > > > my work on OMInit. > > > > > > 2) Continue to work om OMInit and evolve it to also support the concepts > > > which I am going to present, and continue to give information / > > > assistance on cxtable when possible. > > > > > > The following concepts are rough, and certainly open to discussion / > > > evolution, but I think are a basis for an excellent system which should > > > be enjoyed greatly by many. > > > > > > ------------------------------------------------------------------------- > > > > > > The main weakness, in my observation, of a pure p2p system, is that to > > > gain access to particular data, the peer you want to communicate with > > > needs to be available. Some systems have gotten around single peer > > > failure by persisting the data to all peers, but this is a horrible disk > > > (and bandwidth) hog. The solution is the following design, where each > > > piece of software can work as a client or a server. Each server would > > > have a set of available "services". The service and it's associated > > > data can be linked to a service on another "peer" to create redundancy > > > in case of failure. One service is the "master" and the other is a > > > "backup". There can be an unlimited number of backups for a particular > > > service, but obviously as that number increases so does the bandwidth > > > usage to keep the backups up-to-date. > > > > > > Think of a service in the current cxtable context as a plug-in. > > > > > > TheServer > > > --------- > > > A system only act's as a server if it has a service (in either master or > > > backup mode) running. Each service can use either TCP or UDP as it's > > > transport mechanism, and the server is in charge of doing the transport > > > listening, and hands off the connections to the service. > > > > > > The server should also support persistence of service data, and also > > > service "backup" monitoring / updating. This should make writing new > > > services / plug-in's as simple as possible. > > > > > > TheService > > > ---------- > > > The service would get the data from clients (as either byte arrays, > > > string arrays, or java objects (based on xml parsing)) through the > > > server, and handle it appropriately. They would be able to persist data > > > by making calls into the server which it is wrapped in, and if there are > > > "backup" services for this service, it's data is sent to those > > > automatically to be persisted. > > > > > > TheClient > > > --------- > > > The client would initially discover all services it is interested in > > > (see ServiceDiscovery) and a list of "master" services (and the server > > > they are connected to) is shown to the user. The User can then choose > > > to connect to a particular service. There would be client software > > > related to each service, and it would even be possible to have software > > > which could handle communication to more than one type of service. The > > > client "plug-in" would register itself with the client, and if there was > > > more than one client which could connect to a particular service, that > > > list would come up for the user to choose which one they wanted to use > > > (a default could be set so the list wouldn't come up). > > > > > > > > > ServiceDiscovery > > > ---------------- > > > There would be multiple modes of service discovery, all of which can be > > > configured / enabled / disabled. One would be a multicast message sent > > > to the local network. Each Server hearing the message would respond > > > with a list of it's available services. > > > > > > A client could have a set of IP addresses which it would connect to via > > > a proprietary protocol to determine the available services. This would > > > be used if the server / services are not on the local network. > > > > > > A set of URLs could be scanned, using a technique very much like is in > > > place for cxtable now, to determine a set of IP addresses which can be > > > connected to and asked about available services. > > > > > > Persistence > > > ----------- > > > There would be a generic set of methods to persist data. These would > > > link into a set of implementations, each of which would have a name > > > associated to it. This would allow multiple persistence schemes to be > > > used simultaneously. For example, a service could persist data to an > > > implementation called "cxtable.persist.mysql.chess" which would be > > > linked into a Class which uses JDBC to communicate to a MySQL database, > > > and the chess database within MySQL. In addition to JDBC > > > implementations, an XML implementation and flat file implementation > > > should be done at a minimum. > > > > > > These would be implemented through an interface, so 3rd parties could > > > implement alternative persistence schemes. > > > > > > > > > Security / Service Ownership > > > ---------------------------- > > > In the long run, I would suggest the use of a Public / Private Key > > > system which encrypts all communication between all of the objects in > > > the architecture. Initially this will not be implemented, but the > > > methods must be in place to do this so that it is designed from the > > > beginning to support this, rather than retro-fitting it in after the > > > initial implementation. > > > > > > Peers would, through some mechanism, exchange public keys. Each public > > > key would be related to a particular user name. A password will be > > > generated by the user, encrypted, and sent to the peer. The password > > > will be checked against the peer's data (which is encrypted locally) to > > > determine authentication. > > > > > > All data (including discovery messages) will be encrypted, so that only > > > a server can determine, based on the user's identity, what services are > > > available to them. > > > > > > ----------------------------------------------------------------------- > > > > > > I don't believe I have seen a system which supports all (or even half) > > > of the functionality which I have mentioned in this email, and I don't > > > consider it horribly outrageous that we may attempt to do this. I will > > > end up attempting to do this regardless, but another mind to bounce > > > things off of, as you know, is always a nice thing. > > > > > > > > > _______________________________________________ > > > Cxtable-devel mailing list > > > Cxt...@li... > > > https://lists.sourceforge.net/lists/listinfo/cxtable-devel > > > > > > _______________________________________________ > > > Cxtable-devel mailing list > > > Cxt...@li... > > > https://lists.sourceforge.net/lists/listinfo/cxtable-devel > > > > > > > > > > > _______________________________________________ > > Cxtable-devel mailing list > > Cxt...@li... > > https://lists.sourceforge.net/lists/listinfo/cxtable-devel > > |
From: Borne Goodman-M. <bm...@eg...> - 2002-01-03 16:37:59
|
I agree that images rather than letters would be a huge step in the right direction, and even without drag and drop, you could just implement a 2 click mechanism, where you click on the 1st tile (from) and the 2nd tile (to), to move a piece. A friend of mine did some simple drag-n-drop for the jrci project (on sourceforge) for which I re-wrote the server to use the new 1.4 NIO code to scale up to handle a lot more load. I have in the past played D&D (and countless other rpgs), and the jrci project was developed in particular as a system to support remote role playing, including a die rolling engine, etc, but is a pure client / server implementation rather than p2p. I was an observer of them playing a game of Dune with it (not sure if it was based on a system, or home spun), but it is excellent for the latter type of role playing you described. --bjgm On Thu, 2002-01-03 at 11:05, Williams, David wrote: > Yeah... I pretty much thought that I've simply been being lazy.. > > Although, I think my classpath might be set wrong... > > I guess, if I am ever to attract a user base, it should at least support some basic Swing stuff... The Chess game, for example, could _really_ use DnD...currently,but at least something such as an JLabel with Image support... Cause right now, the chesspieces are "Kg-w" (Label objects), and moving them is a matter of calling label.setText(newpiecename); > > You move the chess pieces with coordinates (not a bad thing necessarily), d2 d4, etc.. > > Given the time I've put into it, getting it done and working, and distributable to my close-knit buddy buddies.. I could then have the online, 4-city, D&D session I've dreamed of.. > > (Incidentally..if you ever played D&D..there are two types of people...the 'power-gamers' who played D&D and might as well have been playing a 4-player arcade game, and those that developed a story... I catered, of course, to the latter of these two styles...) > > Its really funny, though...I keep saying "I imagine the possibilities for a real application of this, not just toys", and then follow it with plans for a Battleship game... :-) > > ~Dave > > > David Scott Williams > Computer Associates > Marketing Representative-Sales Call Center > One Computer Associates Plaza > Islandia, New York 11749 > tel: +1 800-243-9462 ext. 73431 > tel: +1 631-342-3431 (Direct) > fax: +1 631-342-5734 > wi...@ca... > > > > > > > -----Original Message----- > From: Borne Goodman-Mace [mailto:bm...@eg...] > Sent: Thursday, January 03, 2002 10:52 AM > To: cxt...@li... > Subject: Re: [Cxtable-devel] RE: Can you help me guage how long this'd > take? > > > This would all be very simple to migrate to Swing, and all of the names > of the Swing components relate to the names of the AWT components which > they mimic. Rather than an awt.Panel you would use a swing.JPanel. > Rather than a TextArea, you would use a JTextArea, or JTextPane (they > have different abilities, and I personally perfer the Pane, though it is > a little more tricky to implement). > > Since the xtable UI is very simple now, I think the transition to Swing > would be a very fast process, and mostly just adding a J in front of the > AWT object names :). > > --bjgm > > On Thu, 2002-01-03 at 10:43, Williams, David wrote: > > Basically, I have a class, xPanel...its .create() method returns a awt.Panel with a TextArea on the South layout, and a "refresh"button and label on the north layout. > > > > I have a message-panel that basically has 2-3 buttons on the south, and a TextArea on the North.... etc... > > > > These are "simple" AWT things... How hard would it be to do as javax.swing? > > > > Advanced things like DnD could be added, etc...but if I am planning to stabilize it as is, I don't know if I require swing for it..unless, of course, a user base comes along... > > > > > > David Scott Williams > > Computer Associates > > Marketing Representative-Sales Call Center > > One Computer Associates Plaza > > Islandia, New York 11749 > > tel: +1 800-243-9462 ext. 73431 > > tel: +1 631-342-3431 (Direct) > > fax: +1 631-342-5734 > > wi...@ca... > > > > > > _______________________________________________ > > Cxtable-devel mailing list > > Cxt...@li... > > https://lists.sourceforge.net/lists/listinfo/cxtable-devel > > > > > > _______________________________________________ > Cxtable-devel mailing list > Cxt...@li... > https://lists.sourceforge.net/lists/listinfo/cxtable-devel > > _______________________________________________ > Cxtable-devel mailing list > Cxt...@li... > https://lists.sourceforge.net/lists/listinfo/cxtable-devel > |
From: Williams, D. <DAV...@ca...> - 2002-01-03 16:07:44
|
Yeah... I pretty much thought that I've simply been being lazy.. Although, I think my classpath might be set wrong... I guess, if I am ever to attract a user base, it should at least support some basic Swing stuff... The Chess game, for example, could _really_ use DnD...currently,but at least something such as an JLabel with Image support... Cause right now, the chesspieces are "Kg-w" (Label objects), and moving them is a matter of calling label.setText(newpiecename); You move the chess pieces with coordinates (not a bad thing necessarily), d2 d4, etc.. Given the time I've put into it, getting it done and working, and distributable to my close-knit buddy buddies.. I could then have the online, 4-city, D&D session I've dreamed of.. (Incidentally..if you ever played D&D..there are two types of people...the 'power-gamers' who played D&D and might as well have been playing a 4-player arcade game, and those that developed a story... I catered, of course, to the latter of these two styles...) Its really funny, though...I keep saying "I imagine the possibilities for a real application of this, not just toys", and then follow it with plans for a Battleship game... :-) ~Dave David Scott Williams Computer Associates Marketing Representative-Sales Call Center One Computer Associates Plaza Islandia, New York 11749 tel: +1 800-243-9462 ext. 73431 tel: +1 631-342-3431 (Direct) fax: +1 631-342-5734 wi...@ca... -----Original Message----- From: Borne Goodman-Mace [mailto:bm...@eg...] Sent: Thursday, January 03, 2002 10:52 AM To: cxt...@li... Subject: Re: [Cxtable-devel] RE: Can you help me guage how long this'd take? This would all be very simple to migrate to Swing, and all of the names of the Swing components relate to the names of the AWT components which they mimic. Rather than an awt.Panel you would use a swing.JPanel. Rather than a TextArea, you would use a JTextArea, or JTextPane (they have different abilities, and I personally perfer the Pane, though it is a little more tricky to implement). Since the xtable UI is very simple now, I think the transition to Swing would be a very fast process, and mostly just adding a J in front of the AWT object names :). --bjgm On Thu, 2002-01-03 at 10:43, Williams, David wrote: > Basically, I have a class, xPanel...its .create() method returns a awt.Panel with a TextArea on the South layout, and a "refresh"button and label on the north layout. > > I have a message-panel that basically has 2-3 buttons on the south, and a TextArea on the North.... etc... > > These are "simple" AWT things... How hard would it be to do as javax.swing? > > Advanced things like DnD could be added, etc...but if I am planning to stabilize it as is, I don't know if I require swing for it..unless, of course, a user base comes along... > > > David Scott Williams > Computer Associates > Marketing Representative-Sales Call Center > One Computer Associates Plaza > Islandia, New York 11749 > tel: +1 800-243-9462 ext. 73431 > tel: +1 631-342-3431 (Direct) > fax: +1 631-342-5734 > wi...@ca... > > > _______________________________________________ > Cxtable-devel mailing list > Cxt...@li... > https://lists.sourceforge.net/lists/listinfo/cxtable-devel > _______________________________________________ Cxtable-devel mailing list Cxt...@li... https://lists.sourceforge.net/lists/listinfo/cxtable-devel |
From: Borne Goodman-M. <bm...@eg...> - 2002-01-03 15:54:46
|
This would all be very simple to migrate to Swing, and all of the names of the Swing components relate to the names of the AWT components which they mimic. Rather than an awt.Panel you would use a swing.JPanel. Rather than a TextArea, you would use a JTextArea, or JTextPane (they have different abilities, and I personally perfer the Pane, though it is a little more tricky to implement). Since the xtable UI is very simple now, I think the transition to Swing would be a very fast process, and mostly just adding a J in front of the AWT object names :). --bjgm On Thu, 2002-01-03 at 10:43, Williams, David wrote: > Basically, I have a class, xPanel...its .create() method returns a awt.Panel with a TextArea on the South layout, and a "refresh"button and label on the north layout. > > I have a message-panel that basically has 2-3 buttons on the south, and a TextArea on the North.... etc... > > These are "simple" AWT things... How hard would it be to do as javax.swing? > > Advanced things like DnD could be added, etc...but if I am planning to stabilize it as is, I don't know if I require swing for it..unless, of course, a user base comes along... > > > David Scott Williams > Computer Associates > Marketing Representative-Sales Call Center > One Computer Associates Plaza > Islandia, New York 11749 > tel: +1 800-243-9462 ext. 73431 > tel: +1 631-342-3431 (Direct) > fax: +1 631-342-5734 > wi...@ca... > > > _______________________________________________ > Cxtable-devel mailing list > Cxt...@li... > https://lists.sourceforge.net/lists/listinfo/cxtable-devel > |
From: Williams, D. <DAV...@ca...> - 2002-01-03 15:44:32
|
Basically, I have a class, xPanel...its .create() method returns a awt.Panel with a TextArea on the South layout, and a "refresh"button and label on the north layout. I have a message-panel that basically has 2-3 buttons on the south, and a TextArea on the North.... etc... These are "simple" AWT things... How hard would it be to do as javax.swing? Advanced things like DnD could be added, etc...but if I am planning to stabilize it as is, I don't know if I require swing for it..unless, of course, a user base comes along... David Scott Williams Computer Associates Marketing Representative-Sales Call Center One Computer Associates Plaza Islandia, New York 11749 tel: +1 800-243-9462 ext. 73431 tel: +1 631-342-3431 (Direct) fax: +1 631-342-5734 wi...@ca... |
From: Borne Goodman-M. <bj...@pe...> - 2002-01-03 13:28:02
|
I believe, based on your idea of what xTable was going to be for, your decision to make the design as it is now is certainly justified, and not all systems need to support a high level of scalability. I think you did quite an excellent job! :) I do understand the basic concept of a frictionless plane, and of course in that environment, force is completely conserved, and therefore and object moving at 10mph for example, will never slow down, because there is no friction to stop it. In regards to scalability, the analogy would be talking about the ability to scale to infinite capacity with no loss of speed / capability. If you want to continue work on xTable, I do completely understand. You can have any level of participation in the new project, and even work with me to brain storm a name, if you care to, and I would set us both up as admins (of course), and I would build the initial CVS tree, and move towards building an Interface shell for the implementation. I am also more than happy to help out with xTable, and if you would like me to look at a particular piece, to determine it's solidity, I will attempt to do so within a reasonable time frame. I would like to have the new project support 1.3 and 1.4, but it will hard to do both, as a lot of excellent new functionality is in 1.4 which I like very much (NIO, Preferences, Logging, etc), so though the user base would have to run latest / greatest to use it, I don't expect it would be ready for wide scale distribution for well over a year, at which point 1.4 should be everywhere.. Thoughts? --bjgm On Thu, 2002-01-03 at 00:03, David Scott Williams wrote: > I suppose that while I always wanted the software I was writing to grow > beyond a simple group of people lumped together for similar purposes...a > group of 'known' quantities... I deep down never really allowed for it with > the algorithm I created... > > xTable doesn't scale because it is a _table_, not one of those fictional > "infinite frictionless plane"s that they used to illustrate a frictionless > physics equation.... I think the goal of a scalable true p2p network is to > create said frictionless plane... (Are you familiar with this example?)... > In other words...when they are trying to discuss velocity of a rolling ball, > rolling down a decline to a flat, frictionless, plane... > > Ahh..I digress..my point is that xTable was born from a project to create a > 6-9 player Dungeons and Dragons chat room, filled with dice, and perhaps > character sheet programs, tournament battles, and maybe even automated > encounters.... An ICQ entirely meant for roleplaying games. Originally, it > was called CyberGameTable...and it was done by sharing "my" (or the DM's) > ftp-password, either directly, or embedded into a setup file, and posting > via FTP...then the panels each had a URL-reader that read the text file > online associated with it, and downloaded it.. (It skip(long)'d what the > text-area already contained, to speed up the reading)... It was actually > quite amazing...it was based on the fact that someone said that all dialups > suffered from an inability to create a ServerSocket, so "sockets" would be a > waste of my time... I was green...it made sense to listen at that point... > > Then, I (and this might be re-hashing old shit you've read in the doc's > section of the site)... did an experiment, and it worked.... I was both > PISSED, and THRILLED... I then, subsequently, selected 5-10 files of the 70 > for CyberGameTable, and started Cyber_x_Table.... The "x" came from the > idea that while this was a table, it wasn't only a game table, but rather, > an amorphic table..., that is, one with many potential purposes..much like > the kitchen table we all played D&D around as adolescents...and > teenagers... We did homework on the table, we did eating on the table, we > did crafts and/or art on the table...we sat around the table and talked > about nothing in particular... we played scrabble, and monopoly, around the > table... and yes, we played D&D... > > I saw xTable as being the same place where many or few people could gather > and do things...things that required being in some sort of proximity...and I > envisioned extending that proximity to close people (close in the heart, or > close in relation) who were in geographically disparate locations > physically.. . > > That is specifically why _two_ persistent connections between each peer is > not so heavy an overhead to place... because the count of peers, even at 8, > would mean that each user only had 15 connections to manage.... and > technically, 7 of them were only relavent when outgoing things were > occuring, so 8 of them required listeners for inbound messaging... > > I am not saying that said design would scale, but it was really never > designed to in the first place... It was not designed for 30 people, but > rather, for 6-10... > > That is why I make no apologies for its design, and at the same time, my own > visions said that it could be greater, that p2p could be done better.... and > I was wondering which way to go.. > > But if you think about it, I scrapped approximately 70-80 java sources that > had taken me 9-12 months (part-time) to write, in a heart-beat, and > subsequently re-wrote it...incidentally, though, the old one was _REALLY_ a > dog...as at 80 files, it was close to 2/3rds of a meg (ALOT OF WASTE)... > whereas now it is closer to 300 kb with both .java, .class, .bat and .cgt > setup file... > > If I get nothing else out of the year I spent on xTable (6-7 months prior to > it appearing on Sourceforge)..it was the more advanced knowledge of .net.* > and sockets in specific...as well as better uses of interfaces...etc... > > That is why I think that maybe we could either -1- continue under the > cxtable banner (although maybe something more fitting is required)... or -2- > start the new project...I will still have some work to do and/or try w/ > cxtable..until I can safely declare a 4-beta or 5- stabile 1.0 > release...then I can see if a user group for the close-knit p2p grows..if it > does./..I maintain it and release additional features and add-ons, if not, I > let it slide away into my educational past... > > Idea? > > Borne Goodman-Mace wrote: > > > There is indeed a huge scalability issue with the current model, and > > with the new model, for those 5 people to communicate, there would be a > > total of 5 connections between them, as they are just all talking to a > > common chat "service". There could of course be a number of these chat > > "services" which are pulled together, virtually, by a listing service, > > which you could connect to and find out about all the different chat > > services available, but if people don't want to join the "borg", then > > they could also have an independent grouping of these chat services. > > > > Of course if the chat client supports it, you could open up a connection > > to more than one chat service at the same time, giving the same > > abilities as IRC has now, but with better scalability, and security. > > You never have to worry about the whole channel going down and thousands > > of people losing their connections, and with the "backup" system, the > > chat environment could conceptually stay up forever. > > > > I hope, as we are talking this out (and my thoughts are evolving with > > your questions, so this is very helpful for me), that you can see how > > this is FAR more scalable, and bandwidth / diskspace friendly than any > > of the pure p2p systems I have seen. > > > > --bjgm > > > > On Wed, 2002-01-02 at 18:51, xi...@pr... wrote: > > > With relation to "chat"... > > > > > > The way cxtable currently handles this is that it has > > > a Vector of xClientConn objects... > > > > > > When you post, if you wish to send to the whole group, > > > you type your message, press the POST button, and then > > > leave the radio-button chosen to "Main".. > > > > > > Press send (or proceed) > > > > > > If you wish, however, to send to only one (or two, or > > > three, but not all) select whom you wish to send it > > > to, and press send > > > > > > If you have selected "main", then it sends to each > > > xClientConn > > > > > > If you select "other" and then many different people, > > > it polls through the array of xClientConn's, and > > > selects only those to whom you've chosen to send it to > > > the message. > > > > > > currently... 5 people connected look like a weird > > > criss cross.. > > > > > > A is connected to B, C, D and E as a client > > > B is connected to A, C, D and E as a client > > > C is connected to A, B, D and E as a client > > > D is connected to A, B, C and E as a client > > > E is connected to A, B, C and D as a client. > > > > > > (By default then, and not being redundant) > > > A has a server connection for B, C, D and E > > > B has a server connection for A, C, D and E > > > C has a server connection for A, B, D and E > > > D has a server connection for A, B, C and E > > > E has a server connection for A, B, C and D > > > > > > So 5 people, to be connected as a network, have 20 > > > connections total between all of them. > > > > > > x*(x-1) connections required with X being the value of > > > participants. > > > > > > This style of connections does not scale well to 1000 > > > users... > > > > > > 1000 * 999 = 999,000 connections... (999 a piece) > > > > > > But you knew that without me doing the math... > > > > > > However, what the above connections do allow is a > > > certain level of p2p between a limited set of peers. > > > > > > Therefore, a "neighborhood" of peers could then be > > > RELAYED between by registry servers. > > > > > > Let's say, Registry server A handles 10 people. > > > Registry server B handles 10 people. > > > > > > Now... for ALL of A's and B's people to "get together" > > > would take 90 connections. (an average of 9 a > > > piece...).. However, if A maintains a persistent > > > connection with B, 45 connections (4.5 per person) > > > would handle it, (actually, allow +1 for the > > > persistent registry server connection)... and > > > therefore allow multiple neighborhoods to relay... > > > That was how I planned to scale it (and, again, > > > everything remains up for debate)... with N users per > > > registry Server, and relay it while they were up... > > > > > > I think, though, maybe you could see how to create > > > a "virtual" intranet atop of the new "sxtable --> > > > cxtable-->whatever" vision that would allow the same > > > degree of virtual privacy and more flexibility to surf > > > across a distributed internet of nodes? > > > > > > I like your ideas, and sometimes, good ideas are hard > > > to swallow. Let me digest. > > > > > > > > > > > > > > > --- Original Message --- > > > From: Borne Goodman-Mace <bm...@eg...> > > > To: "cxt...@li..." <cxtable- > > > de...@li...> > > > Subject: Re: [Cxtable-devel] A longer reply to "p2p, > > > the next generation" > > > > > > >A "Server" is really just a piece of code in > > > each "peer". This part of > > > >the peer software (which each person would run), > > > would include the > > > >server, any services they have installed, and the > > > client code. A Server > > > >includes registry logic, persistence logic, service > > > replication logic, > > > >and user authentication / authorization logic. The > > > server is really > > > >just the wrapping through which a service sees the > > > world, which is made > > > >up of it's clients, and it's persistent storage. > > > > > > > >A service is started by the server (when the user > > > commands this to be > > > >done, or by default when the program is started if it > > > is configured in > > > >this way), and then, based on the service's > > > configuration, when it > > > >persists information, the server will send that same > > > information to > > > >other server's which have are designated as "backup" > > > services, to > > > >persist the data there as well. > > > > > > > >Your point about how the client currently works is > > > the largest > > > >divergence from my thoughts, as what I think this > > > idea really turns into > > > >is a kind of hybrid p2p / client-server model, though > > > it is flexible > > > >enough to be a pure p2p, or pure client-server model, > > > based on the > > > >configuration. > > > > > > > >I will now give some examples of usage, which I hope > > > will help to answer > > > >any other questions you might have, but if they > > > don't, please feel free > > > >to ask more! :) > > > > > > > >> Alice starts up the supercharged new cxtable (I > > > will call this sxtable > > > >for now). > > > >> Alice starts up a file sharing service (through the > > > server UI). > > > >> Bob starts up sxtable. > > > >> Bob starts up the file sharing service, but > > > in "backup" mode, and > > > >connects it to Alice's file sharing service (he needs > > > permission to do > > > >this, which he already has from Alice). > > > > > > > >> Charles starts up sxtable. > > > >> Charles has a URL which lists a number of peers > > > which are sometimes up > > > >running the file sharing service and types it into > > > the UI (or it is > > > >saved in his preferences and he doesn't need to type > > > it in). > > > >> Charles gets a list of file sharing services which > > > are currently > > > >available (found through the discovery process). > > > >> Charles starts up his file sharing client, and > > > connects to Alice's > > > >service. The client may or may not support > > > connecting to more than one > > > >service at a time > > > >> Charle's client finds out that Bob is a "backup" > > > for Alice, and > > > >remembers this. > > > >> Charles downloads some files, and uploads one. > > > This causes Alice's > > > >file sharing service to persist it to disk, at which > > > point the "server" > > > >knows that Bob is a backup, and send the file to him > > > to persist as well. > > > > > > > >> Alice's system crashes. > > > >> Bob's server detects this, and starts up the > > > service. A service in > > > >backup mode doesn't need to be fully running, the > > > server only needs to > > > >know how to persist the information for that service > > > type. > > > > > > > >> Charles can now connect to Bob's system, and > > > continue uploading / > > > >downloading. > > > > > > > >> Alice's system comes back up, pulls over the > > > persistent data from Bob > > > >and tells it to go back into "backup" mode, once no > > > clients are > > > >connected. > > > > > > > >In this example, if the client software supported it, > > > Charles could > > > >connect to a large number of file sharing systems at > > > once. > > > > > > > >Overall this solves one of the biggest problems of > > > peer networking, in > > > >that you might not be able to get to the data that > > > you want to, but you > > > >don't want to have the data EVERYWHERE because that > > > is a huge waste of > > > >bandwidth / space. > > > > > > > >Also, with things like chatting, rather than having > > > all the messages > > > >sent to everyone, you can have a single system, > > > a "server" of sorts, > > > >which everyone chats through, but if it goes down, > > > other can be set as > > > >"backups", so the conversation can continue > > > seamlessly if the server > > > >goes down. > > > > > > > >One of the guys that invented Lotus Notes is involved > > > in p2p software > > > >now, and I can't remember the name of it now, but I > > > used it for quite a > > > >while, and it was rather nice, with a shared > > > whiteboard, shared > > > >calendar, chat system, and some other stuff > > > (including file sharing), > > > >but it stored everything on each client (they have a > > > version you can pay > > > >for though, that creates a server which holds > > > stuff). Despite the > > > >ability to "serverize" some of these services, it > > > still lacks a great > > > >deal in the fail-over / reliability area, and > > > everything is encrypted, > > > >but their security scheme still blows, IMHO. > > > > > > > >I want everyone in the world to be able to host a set > > > of services on > > > >their home machine, and with more and more people > > > getting broadband and > > > >leaving their machines on all day long, this makes > > > more and more sense. > > > > > > > >I could then set up some file system space at home, > > > for family pictures, > > > >my mother and aunt could run "backup" services, so > > > that if for some > > > >reason I go off line (which doesn't happen often), > > > everyone can keep > > > >getting the data, and I can get updated when I come > > > back on-line. > > > > > > > >I see this as the ultimate group-ware, since you can > > > still be in > > > >client-server mode if you want, or each person can > > > keep their files on > > > >their local system, or you can tailor make your > > > service network in any > > > >way that is appropriate to your application. > > > > > > > >There could even be a service which acts as a client > > > in a knowledge > > > >"group" to obtain information about all available > > > files in the group. > > > >Then rather than having to connect to each peer, you > > > can just connect to > > > >one of the knowledge managers to get the information. > > > > > > > >There are a nearly infinite number of uses for this > > > technology, I think, > > > >yet I feel that this sort of thing has never been > > > implemented in the > > > >correct way. > > > > > > > >I hope I have not rambled too much, and perhaps even > > > answered some > > > >questions along the way. > > > > > > > >--bjgm > > > > > > > >On Wed, 2002-01-02 at 16:33, Williams, David wrote: > > > >> Borne- > > > >> > > > >> OK.... > > > >> > > > >> I am assuming, then, that a Server is a persistent > > > thing...? It is always available, or this is > > > incorrect? Either way.... I would make this akin to > > > my mind to the current Registry server process (which > > > also handles relay communications when direct, and > > > peer-enable, both fail..).. It could handle many > > > other processes as well..but at this time, does only > > > those two... > > > >> > > > >> The Service.. These services, run, then, on the > > > Server, and cache to their backup? Or did I miss this > > > point? > > > >> > > > >> The Client... This client has a list of services > > > it can connect to... This is definitely a planned but > > > lacking feature for cxtable. Cxtable assumes that > > > everyone connected to it wishes to connect to one > > > another... the persistent connection between each peer > > > eventually allows the runner of the Registry server to > > > pull down that server process, and have a set of X > > > people connected with one another, but closed off to > > > the rest of the 'network'.. > > > >> > > > >> Service Discovery... > > > >> URL-scanning is good. I personally like the PHP- > > > piece, as the act of registering a server for the > > > availability of use to clients can be done with a URL > > > scan as well.. Either way...this basic idea does seem > > > to be in line with how I do it (or hope I do) > > > >> > > > >> Persistence... > > > >> I have given no thought to persistence. These > > > ideas seem valuable, for sure.. > > > >> > > > >> Security/Service Ownership.. > > > >> Contrary to what the code would tell you.. I have > > > given thought to security... Relating to public > > > keys... these keys generally can be published > > > anywhere (hence their name) and could be provided > > > along with the peers other information (IP, port, > > > etc..), unless your intention is to route all > > > communicae through a Server, and then, if course, only > > > the server would need to know it... > > > >> > > > >> --------------------------------------- > > > >> > > > >> Each of the above points has merit with relation to > > > the project I currently have, and at the same time.. > > > I pause... as there are one or two points that I am > > > unsure of.. > > > >> > > > >> Is the goal of the p2p to have places that relay > > > which are persistent? Because this vision does give > > > way to a couple of weaknesses... One of these > > > weaknesses is that if they can pin down where you are, > > > and where you'll always be... Then they can shut you > > > down.... The other is the need for a certain type of > > > cash-flow to support the persistent servers... > > > >> > > > >> However, as I continue to read through this, I am > > > of the belief that the servers you speak of could be > > > EITHER a persistent server in the traditional sense, > > > OR a peer-type server that is fairly transient... > > > >> > > > >> Change is not a bad thing...and this is definitely > > > the type of thing I set myself up for by inviting new > > > creative blood to come look, to come help.... > > > >> > > > >> I think that the changes you propose are worth > > > pursuing. I think that certain services, under the > > > new modified vision, would allow for the "Intranet > > > over the internet" concept to remain, and at the same > > > time widen the vision to incorporate many other takes.. > > > >> > > > >> This is all assuming that you haven't decided to > > > ditch me for Grapevine ;-) > > > >> > > > >> ~Dave > > > >> > > > >> > > > >> David Scott Williams > > > >> Computer Associates > > > >> Marketing Representative-Sales Call Center > > > >> One Computer Associates Plaza > > > >> Islandia, New York 11749 > > > >> tel: +1 800-243-9462 ext. 73431 > > > >> tel: +1 631-342-3431 (Direct) > > > >> fax: +1 631-342-5734 > > > >> wi...@ca... > > > >> > > > >> > > > >> _______________________________________________ > > > >> Cxtable-devel mailing list > > > >> Cxt...@li... > > > >> > > > https://lists.sourceforge.net/lists/listinfo/cxtable- > > > devel > > > >> > > > > > > > > > > > > > > > >_______________________________________________ > > > >Cxtable-devel mailing list > > > >Cxt...@li... > > > >https://lists.sourceforge.net/lists/listinfo/cxtable- > > > devel > > > > > -- > ~Dave > xi...@pr... > http://sourceforge.net/projects/cxtable >The xTable Project< > http://sourceforge.net/projects/dustyscript >Dustyscript Child Script > Language< > > |>>weblog: http://www.geocities.com/xiarcel/weblogs/log.html<<| > > "He who trades even a small amount of freedom for temporary security > deserves neither freedom, nor security" > -Benjamin Franklin > > "When I think back on all the crap I learned in High School... > it's a wonder I can think at all..." > -Paul Simon, "Kodachrome" > > > > _______________________________________________ > Cxtable-devel mailing list > Cxt...@li... > https://lists.sourceforge.net/lists/listinfo/cxtable-devel |
From: David S. W. <xi...@pr...> - 2002-01-03 04:53:39
|
I suppose that while I always wanted the software I was writing to grow beyond a simple group of people lumped together for similar purposes...a group of 'known' quantities... I deep down never really allowed for it with the algorithm I created... xTable doesn't scale because it is a _table_, not one of those fictional "infinite frictionless plane"s that they used to illustrate a frictionless physics equation.... I think the goal of a scalable true p2p network is to create said frictionless plane... (Are you familiar with this example?)... In other words...when they are trying to discuss velocity of a rolling ball, rolling down a decline to a flat, frictionless, plane... Ahh..I digress..my point is that xTable was born from a project to create a 6-9 player Dungeons and Dragons chat room, filled with dice, and perhaps character sheet programs, tournament battles, and maybe even automated encounters.... An ICQ entirely meant for roleplaying games. Originally, it was called CyberGameTable...and it was done by sharing "my" (or the DM's) ftp-password, either directly, or embedded into a setup file, and posting via FTP...then the panels each had a URL-reader that read the text file online associated with it, and downloaded it.. (It skip(long)'d what the text-area already contained, to speed up the reading)... It was actually quite amazing...it was based on the fact that someone said that all dialups suffered from an inability to create a ServerSocket, so "sockets" would be a waste of my time... I was green...it made sense to listen at that point... Then, I (and this might be re-hashing old shit you've read in the doc's section of the site)... did an experiment, and it worked.... I was both PISSED, and THRILLED... I then, subsequently, selected 5-10 files of the 70 for CyberGameTable, and started Cyber_x_Table.... The "x" came from the idea that while this was a table, it wasn't only a game table, but rather, an amorphic table..., that is, one with many potential purposes..much like the kitchen table we all played D&D around as adolescents...and teenagers... We did homework on the table, we did eating on the table, we did crafts and/or art on the table...we sat around the table and talked about nothing in particular... we played scrabble, and monopoly, around the table... and yes, we played D&D... I saw xTable as being the same place where many or few people could gather and do things...things that required being in some sort of proximity...and I envisioned extending that proximity to close people (close in the heart, or close in relation) who were in geographically disparate locations physically.. . That is specifically why _two_ persistent connections between each peer is not so heavy an overhead to place... because the count of peers, even at 8, would mean that each user only had 15 connections to manage.... and technically, 7 of them were only relavent when outgoing things were occuring, so 8 of them required listeners for inbound messaging... I am not saying that said design would scale, but it was really never designed to in the first place... It was not designed for 30 people, but rather, for 6-10... That is why I make no apologies for its design, and at the same time, my own visions said that it could be greater, that p2p could be done better.... and I was wondering which way to go.. But if you think about it, I scrapped approximately 70-80 java sources that had taken me 9-12 months (part-time) to write, in a heart-beat, and subsequently re-wrote it...incidentally, though, the old one was _REALLY_ a dog...as at 80 files, it was close to 2/3rds of a meg (ALOT OF WASTE)... whereas now it is closer to 300 kb with both .java, .class, .bat and .cgt setup file... If I get nothing else out of the year I spent on xTable (6-7 months prior to it appearing on Sourceforge)..it was the more advanced knowledge of .net.* and sockets in specific...as well as better uses of interfaces...etc... That is why I think that maybe we could either -1- continue under the cxtable banner (although maybe something more fitting is required)... or -2- start the new project...I will still have some work to do and/or try w/ cxtable..until I can safely declare a 4-beta or 5- stabile 1.0 release...then I can see if a user group for the close-knit p2p grows..if it does./..I maintain it and release additional features and add-ons, if not, I let it slide away into my educational past... Idea? Borne Goodman-Mace wrote: > There is indeed a huge scalability issue with the current model, and > with the new model, for those 5 people to communicate, there would be a > total of 5 connections between them, as they are just all talking to a > common chat "service". There could of course be a number of these chat > "services" which are pulled together, virtually, by a listing service, > which you could connect to and find out about all the different chat > services available, but if people don't want to join the "borg", then > they could also have an independent grouping of these chat services. > > Of course if the chat client supports it, you could open up a connection > to more than one chat service at the same time, giving the same > abilities as IRC has now, but with better scalability, and security. > You never have to worry about the whole channel going down and thousands > of people losing their connections, and with the "backup" system, the > chat environment could conceptually stay up forever. > > I hope, as we are talking this out (and my thoughts are evolving with > your questions, so this is very helpful for me), that you can see how > this is FAR more scalable, and bandwidth / diskspace friendly than any > of the pure p2p systems I have seen. > > --bjgm > > On Wed, 2002-01-02 at 18:51, xi...@pr... wrote: > > With relation to "chat"... > > > > The way cxtable currently handles this is that it has > > a Vector of xClientConn objects... > > > > When you post, if you wish to send to the whole group, > > you type your message, press the POST button, and then > > leave the radio-button chosen to "Main".. > > > > Press send (or proceed) > > > > If you wish, however, to send to only one (or two, or > > three, but not all) select whom you wish to send it > > to, and press send > > > > If you have selected "main", then it sends to each > > xClientConn > > > > If you select "other" and then many different people, > > it polls through the array of xClientConn's, and > > selects only those to whom you've chosen to send it to > > the message. > > > > currently... 5 people connected look like a weird > > criss cross.. > > > > A is connected to B, C, D and E as a client > > B is connected to A, C, D and E as a client > > C is connected to A, B, D and E as a client > > D is connected to A, B, C and E as a client > > E is connected to A, B, C and D as a client. > > > > (By default then, and not being redundant) > > A has a server connection for B, C, D and E > > B has a server connection for A, C, D and E > > C has a server connection for A, B, D and E > > D has a server connection for A, B, C and E > > E has a server connection for A, B, C and D > > > > So 5 people, to be connected as a network, have 20 > > connections total between all of them. > > > > x*(x-1) connections required with X being the value of > > participants. > > > > This style of connections does not scale well to 1000 > > users... > > > > 1000 * 999 = 999,000 connections... (999 a piece) > > > > But you knew that without me doing the math... > > > > However, what the above connections do allow is a > > certain level of p2p between a limited set of peers. > > > > Therefore, a "neighborhood" of peers could then be > > RELAYED between by registry servers. > > > > Let's say, Registry server A handles 10 people. > > Registry server B handles 10 people. > > > > Now... for ALL of A's and B's people to "get together" > > would take 90 connections. (an average of 9 a > > piece...).. However, if A maintains a persistent > > connection with B, 45 connections (4.5 per person) > > would handle it, (actually, allow +1 for the > > persistent registry server connection)... and > > therefore allow multiple neighborhoods to relay... > > That was how I planned to scale it (and, again, > > everything remains up for debate)... with N users per > > registry Server, and relay it while they were up... > > > > I think, though, maybe you could see how to create > > a "virtual" intranet atop of the new "sxtable --> > > cxtable-->whatever" vision that would allow the same > > degree of virtual privacy and more flexibility to surf > > across a distributed internet of nodes? > > > > I like your ideas, and sometimes, good ideas are hard > > to swallow. Let me digest. > > > > > > > > > > --- Original Message --- > > From: Borne Goodman-Mace <bm...@eg...> > > To: "cxt...@li..." <cxtable- > > de...@li...> > > Subject: Re: [Cxtable-devel] A longer reply to "p2p, > > the next generation" > > > > >A "Server" is really just a piece of code in > > each "peer". This part of > > >the peer software (which each person would run), > > would include the > > >server, any services they have installed, and the > > client code. A Server > > >includes registry logic, persistence logic, service > > replication logic, > > >and user authentication / authorization logic. The > > server is really > > >just the wrapping through which a service sees the > > world, which is made > > >up of it's clients, and it's persistent storage. > > > > > >A service is started by the server (when the user > > commands this to be > > >done, or by default when the program is started if it > > is configured in > > >this way), and then, based on the service's > > configuration, when it > > >persists information, the server will send that same > > information to > > >other server's which have are designated as "backup" > > services, to > > >persist the data there as well. > > > > > >Your point about how the client currently works is > > the largest > > >divergence from my thoughts, as what I think this > > idea really turns into > > >is a kind of hybrid p2p / client-server model, though > > it is flexible > > >enough to be a pure p2p, or pure client-server model, > > based on the > > >configuration. > > > > > >I will now give some examples of usage, which I hope > > will help to answer > > >any other questions you might have, but if they > > don't, please feel free > > >to ask more! :) > > > > > >> Alice starts up the supercharged new cxtable (I > > will call this sxtable > > >for now). > > >> Alice starts up a file sharing service (through the > > server UI). > > >> Bob starts up sxtable. > > >> Bob starts up the file sharing service, but > > in "backup" mode, and > > >connects it to Alice's file sharing service (he needs > > permission to do > > >this, which he already has from Alice). > > > > > >> Charles starts up sxtable. > > >> Charles has a URL which lists a number of peers > > which are sometimes up > > >running the file sharing service and types it into > > the UI (or it is > > >saved in his preferences and he doesn't need to type > > it in). > > >> Charles gets a list of file sharing services which > > are currently > > >available (found through the discovery process). > > >> Charles starts up his file sharing client, and > > connects to Alice's > > >service. The client may or may not support > > connecting to more than one > > >service at a time > > >> Charle's client finds out that Bob is a "backup" > > for Alice, and > > >remembers this. > > >> Charles downloads some files, and uploads one. > > This causes Alice's > > >file sharing service to persist it to disk, at which > > point the "server" > > >knows that Bob is a backup, and send the file to him > > to persist as well. > > > > > >> Alice's system crashes. > > >> Bob's server detects this, and starts up the > > service. A service in > > >backup mode doesn't need to be fully running, the > > server only needs to > > >know how to persist the information for that service > > type. > > > > > >> Charles can now connect to Bob's system, and > > continue uploading / > > >downloading. > > > > > >> Alice's system comes back up, pulls over the > > persistent data from Bob > > >and tells it to go back into "backup" mode, once no > > clients are > > >connected. > > > > > >In this example, if the client software supported it, > > Charles could > > >connect to a large number of file sharing systems at > > once. > > > > > >Overall this solves one of the biggest problems of > > peer networking, in > > >that you might not be able to get to the data that > > you want to, but you > > >don't want to have the data EVERYWHERE because that > > is a huge waste of > > >bandwidth / space. > > > > > >Also, with things like chatting, rather than having > > all the messages > > >sent to everyone, you can have a single system, > > a "server" of sorts, > > >which everyone chats through, but if it goes down, > > other can be set as > > >"backups", so the conversation can continue > > seamlessly if the server > > >goes down. > > > > > >One of the guys that invented Lotus Notes is involved > > in p2p software > > >now, and I can't remember the name of it now, but I > > used it for quite a > > >while, and it was rather nice, with a shared > > whiteboard, shared > > >calendar, chat system, and some other stuff > > (including file sharing), > > >but it stored everything on each client (they have a > > version you can pay > > >for though, that creates a server which holds > > stuff). Despite the > > >ability to "serverize" some of these services, it > > still lacks a great > > >deal in the fail-over / reliability area, and > > everything is encrypted, > > >but their security scheme still blows, IMHO. > > > > > >I want everyone in the world to be able to host a set > > of services on > > >their home machine, and with more and more people > > getting broadband and > > >leaving their machines on all day long, this makes > > more and more sense. > > > > > >I could then set up some file system space at home, > > for family pictures, > > >my mother and aunt could run "backup" services, so > > that if for some > > >reason I go off line (which doesn't happen often), > > everyone can keep > > >getting the data, and I can get updated when I come > > back on-line. > > > > > >I see this as the ultimate group-ware, since you can > > still be in > > >client-server mode if you want, or each person can > > keep their files on > > >their local system, or you can tailor make your > > service network in any > > >way that is appropriate to your application. > > > > > >There could even be a service which acts as a client > > in a knowledge > > >"group" to obtain information about all available > > files in the group. > > >Then rather than having to connect to each peer, you > > can just connect to > > >one of the knowledge managers to get the information. > > > > > >There are a nearly infinite number of uses for this > > technology, I think, > > >yet I feel that this sort of thing has never been > > implemented in the > > >correct way. > > > > > >I hope I have not rambled too much, and perhaps even > > answered some > > >questions along the way. > > > > > >--bjgm > > > > > >On Wed, 2002-01-02 at 16:33, Williams, David wrote: > > >> Borne- > > >> > > >> OK.... > > >> > > >> I am assuming, then, that a Server is a persistent > > thing...? It is always available, or this is > > incorrect? Either way.... I would make this akin to > > my mind to the current Registry server process (which > > also handles relay communications when direct, and > > peer-enable, both fail..).. It could handle many > > other processes as well..but at this time, does only > > those two... > > >> > > >> The Service.. These services, run, then, on the > > Server, and cache to their backup? Or did I miss this > > point? > > >> > > >> The Client... This client has a list of services > > it can connect to... This is definitely a planned but > > lacking feature for cxtable. Cxtable assumes that > > everyone connected to it wishes to connect to one > > another... the persistent connection between each peer > > eventually allows the runner of the Registry server to > > pull down that server process, and have a set of X > > people connected with one another, but closed off to > > the rest of the 'network'.. > > >> > > >> Service Discovery... > > >> URL-scanning is good. I personally like the PHP- > > piece, as the act of registering a server for the > > availability of use to clients can be done with a URL > > scan as well.. Either way...this basic idea does seem > > to be in line with how I do it (or hope I do) > > >> > > >> Persistence... > > >> I have given no thought to persistence. These > > ideas seem valuable, for sure.. > > >> > > >> Security/Service Ownership.. > > >> Contrary to what the code would tell you.. I have > > given thought to security... Relating to public > > keys... these keys generally can be published > > anywhere (hence their name) and could be provided > > along with the peers other information (IP, port, > > etc..), unless your intention is to route all > > communicae through a Server, and then, if course, only > > the server would need to know it... > > >> > > >> --------------------------------------- > > >> > > >> Each of the above points has merit with relation to > > the project I currently have, and at the same time.. > > I pause... as there are one or two points that I am > > unsure of.. > > >> > > >> Is the goal of the p2p to have places that relay > > which are persistent? Because this vision does give > > way to a couple of weaknesses... One of these > > weaknesses is that if they can pin down where you are, > > and where you'll always be... Then they can shut you > > down.... The other is the need for a certain type of > > cash-flow to support the persistent servers... > > >> > > >> However, as I continue to read through this, I am > > of the belief that the servers you speak of could be > > EITHER a persistent server in the traditional sense, > > OR a peer-type server that is fairly transient... > > >> > > >> Change is not a bad thing...and this is definitely > > the type of thing I set myself up for by inviting new > > creative blood to come look, to come help.... > > >> > > >> I think that the changes you propose are worth > > pursuing. I think that certain services, under the > > new modified vision, would allow for the "Intranet > > over the internet" concept to remain, and at the same > > time widen the vision to incorporate many other takes.. > > >> > > >> This is all assuming that you haven't decided to > > ditch me for Grapevine ;-) > > >> > > >> ~Dave > > >> > > >> > > >> David Scott Williams > > >> Computer Associates > > >> Marketing Representative-Sales Call Center > > >> One Computer Associates Plaza > > >> Islandia, New York 11749 > > >> tel: +1 800-243-9462 ext. 73431 > > >> tel: +1 631-342-3431 (Direct) > > >> fax: +1 631-342-5734 > > >> wi...@ca... > > >> > > >> > > >> _______________________________________________ > > >> Cxtable-devel mailing list > > >> Cxt...@li... > > >> > > https://lists.sourceforge.net/lists/listinfo/cxtable- > > devel > > >> > > > > > > > > > > > >_______________________________________________ > > >Cxtable-devel mailing list > > >Cxt...@li... > > >https://lists.sourceforge.net/lists/listinfo/cxtable- > > devel > > -- ~Dave xi...@pr... http://sourceforge.net/projects/cxtable >The xTable Project< http://sourceforge.net/projects/dustyscript >Dustyscript Child Script Language< |>>weblog: http://www.geocities.com/xiarcel/weblogs/log.html<<| "He who trades even a small amount of freedom for temporary security deserves neither freedom, nor security" -Benjamin Franklin "When I think back on all the crap I learned in High School... it's a wonder I can think at all..." -Paul Simon, "Kodachrome" |
From: Borne Goodman-M. <bj...@pe...> - 2002-01-03 04:20:28
|
I haven't done a CVS update in the last week, but I would guess you got everything moved around and compiling correctly? If so, EXCELLENT!! I am happy you are getting more comfortable with it. Are you using the command line, or something like WinCVS to interface with it? --bjgm On Wed, 2002-01-02 at 18:52, Williams, David wrote: > Did you see what I did in CVS ?? :-) > > ("Win little victories") > > > David Scott Williams > Computer Associates > Marketing Representative-Sales Call Center > One Computer Associates Plaza > Islandia, New York 11749 > tel: +1 800-243-9462 ext. 73431 > tel: +1 631-342-3431 (Direct) > fax: +1 631-342-5734 > wi...@ca... > > > _______________________________________________ > Cxtable-devel mailing list > Cxt...@li... > https://lists.sourceforge.net/lists/listinfo/cxtable-devel |
From: Borne Goodman-M. <bj...@pe...> - 2002-01-03 04:19:02
|
Another option would be that we decide on the best name for this new project and create a new one on sourceforge, use code from my ominit project and your cxtable project where we don't write new code, and of course share an admin role in it. I don't know if I would really call it a purely p2p project, but describing it is rather hard to do without examples. I may have to write up some kind of paper, which we can publish in the docs section of the project, and evolve as the project evolves. Extraordinary, that is a good word for it :). I don't especially see dial-up networkers as being 2nd class citizens, but there are obviously certain limitations that the lesser bandwidth place on them. It would be more difficult for them to play the "master", or even "backup" role for high throughput services, but should be able to serve as a "chat" or low throughput "backup" file server just fine. Off to reply to your other emails :) --bjgm On Wed, 2002-01-02 at 21:54, David Scott Williams wrote: > Perhaps the project I have been working on can be renamed Mini-xTable, > and proceed through its 1.0 release...stabilized at about where I could > have taken it on my own... > > And the xTable project proper will re-direct its efforts and re-building > the p2p from the ground up? > > At that point, you and I would share the project admin role? Some of > the ideas/principles from my project can remain, and your ideas can be > merged with and envelope mine, and we can create an extraordinary > project? > > > I just wonder...what place do dial-up networkers have in your p2p > system? > > > -- > ~Dave > xi...@pr... > http://sourceforge.net/projects/cxtable >The xTable Project< > http://sourceforge.net/projects/dustyscript >Dustyscript Child Script > Language< > > |>>weblog: http://www.geocities.com/xiarcel/weblogs/log.html<<| > > "He who trades even a small amount of freedom for temporary security > deserves neither freedom, nor security" > -Benjamin Franklin > > "When I think back on all the crap I learned in High School... > it's a wonder I can think at all..." > -Paul Simon, "Kodachrome" > > > > _______________________________________________ > Cxtable-devel mailing list > Cxt...@li... > https://lists.sourceforge.net/lists/listinfo/cxtable-devel |
From: David S. W. <xi...@pr...> - 2002-01-03 02:44:06
|
Perhaps the project I have been working on can be renamed Mini-xTable, and proceed through its 1.0 release...stabilized at about where I could have taken it on my own... And the xTable project proper will re-direct its efforts and re-building the p2p from the ground up? At that point, you and I would share the project admin role? Some of the ideas/principles from my project can remain, and your ideas can be merged with and envelope mine, and we can create an extraordinary project? I just wonder...what place do dial-up networkers have in your p2p system? -- ~Dave xi...@pr... http://sourceforge.net/projects/cxtable >The xTable Project< http://sourceforge.net/projects/dustyscript >Dustyscript Child Script Language< |>>weblog: http://www.geocities.com/xiarcel/weblogs/log.html<<| "He who trades even a small amount of freedom for temporary security deserves neither freedom, nor security" -Benjamin Franklin "When I think back on all the crap I learned in High School... it's a wonder I can think at all..." -Paul Simon, "Kodachrome" |
From: Williams, D. <DAV...@ca...> - 2002-01-02 23:54:38
|
Did you see what I did in CVS ?? :-) ("Win little victories") David Scott Williams Computer Associates Marketing Representative-Sales Call Center One Computer Associates Plaza Islandia, New York 11749 tel: +1 800-243-9462 ext. 73431 tel: +1 631-342-3431 (Direct) fax: +1 631-342-5734 wi...@ca... |
From: Borne Goodman-M. <bm...@eg...> - 2002-01-02 22:47:02
|
A "Server" is really just a piece of code in each "peer". This part of the peer software (which each person would run), would include the server, any services they have installed, and the client code. A Server includes registry logic, persistence logic, service replication logic, and user authentication / authorization logic. The server is really just the wrapping through which a service sees the world, which is made up of it's clients, and it's persistent storage. A service is started by the server (when the user commands this to be done, or by default when the program is started if it is configured in this way), and then, based on the service's configuration, when it persists information, the server will send that same information to other server's which have are designated as "backup" services, to persist the data there as well. Your point about how the client currently works is the largest divergence from my thoughts, as what I think this idea really turns into is a kind of hybrid p2p / client-server model, though it is flexible enough to be a pure p2p, or pure client-server model, based on the configuration. I will now give some examples of usage, which I hope will help to answer any other questions you might have, but if they don't, please feel free to ask more! :) > Alice starts up the supercharged new cxtable (I will call this sxtable for now). > Alice starts up a file sharing service (through the server UI). > Bob starts up sxtable. > Bob starts up the file sharing service, but in "backup" mode, and connects it to Alice's file sharing service (he needs permission to do this, which he already has from Alice). > Charles starts up sxtable. > Charles has a URL which lists a number of peers which are sometimes up running the file sharing service and types it into the UI (or it is saved in his preferences and he doesn't need to type it in). > Charles gets a list of file sharing services which are currently available (found through the discovery process). > Charles starts up his file sharing client, and connects to Alice's service. The client may or may not support connecting to more than one service at a time > Charle's client finds out that Bob is a "backup" for Alice, and remembers this. > Charles downloads some files, and uploads one. This causes Alice's file sharing service to persist it to disk, at which point the "server" knows that Bob is a backup, and send the file to him to persist as well. > Alice's system crashes. > Bob's server detects this, and starts up the service. A service in backup mode doesn't need to be fully running, the server only needs to know how to persist the information for that service type. > Charles can now connect to Bob's system, and continue uploading / downloading. > Alice's system comes back up, pulls over the persistent data from Bob and tells it to go back into "backup" mode, once no clients are connected. In this example, if the client software supported it, Charles could connect to a large number of file sharing systems at once. Overall this solves one of the biggest problems of peer networking, in that you might not be able to get to the data that you want to, but you don't want to have the data EVERYWHERE because that is a huge waste of bandwidth / space. Also, with things like chatting, rather than having all the messages sent to everyone, you can have a single system, a "server" of sorts, which everyone chats through, but if it goes down, other can be set as "backups", so the conversation can continue seamlessly if the server goes down. One of the guys that invented Lotus Notes is involved in p2p software now, and I can't remember the name of it now, but I used it for quite a while, and it was rather nice, with a shared whiteboard, shared calendar, chat system, and some other stuff (including file sharing), but it stored everything on each client (they have a version you can pay for though, that creates a server which holds stuff). Despite the ability to "serverize" some of these services, it still lacks a great deal in the fail-over / reliability area, and everything is encrypted, but their security scheme still blows, IMHO. I want everyone in the world to be able to host a set of services on their home machine, and with more and more people getting broadband and leaving their machines on all day long, this makes more and more sense. I could then set up some file system space at home, for family pictures, my mother and aunt could run "backup" services, so that if for some reason I go off line (which doesn't happen often), everyone can keep getting the data, and I can get updated when I come back on-line. I see this as the ultimate group-ware, since you can still be in client-server mode if you want, or each person can keep their files on their local system, or you can tailor make your service network in any way that is appropriate to your application. There could even be a service which acts as a client in a knowledge "group" to obtain information about all available files in the group. Then rather than having to connect to each peer, you can just connect to one of the knowledge managers to get the information. There are a nearly infinite number of uses for this technology, I think, yet I feel that this sort of thing has never been implemented in the correct way. I hope I have not rambled too much, and perhaps even answered some questions along the way. --bjgm On Wed, 2002-01-02 at 16:33, Williams, David wrote: > Borne- > > OK.... > > I am assuming, then, that a Server is a persistent thing...? It is always available, or this is incorrect? Either way.... I would make this akin to my mind to the current Registry server process (which also handles relay communications when direct, and peer-enable, both fail..).. It could handle many other processes as well..but at this time, does only those two... > > The Service.. These services, run, then, on the Server, and cache to their backup? Or did I miss this point? > > The Client... This client has a list of services it can connect to... This is definitely a planned but lacking feature for cxtable. Cxtable assumes that everyone connected to it wishes to connect to one another... the persistent connection between each peer eventually allows the runner of the Registry server to pull down that server process, and have a set of X people connected with one another, but closed off to the rest of the 'network'.. > > Service Discovery... > URL-scanning is good. I personally like the PHP-piece, as the act of registering a server for the availability of use to clients can be done with a URL scan as well.. Either way...this basic idea does seem to be in line with how I do it (or hope I do) > > Persistence... > I have given no thought to persistence. These ideas seem valuable, for sure.. > > Security/Service Ownership.. > Contrary to what the code would tell you.. I have given thought to security... Relating to public keys... these keys generally can be published anywhere (hence their name) and could be provided along with the peers other information (IP, port, etc..), unless your intention is to route all communicae through a Server, and then, if course, only the server would need to know it... > > --------------------------------------- > > Each of the above points has merit with relation to the project I currently have, and at the same time.. I pause... as there are one or two points that I am unsure of.. > > Is the goal of the p2p to have places that relay which are persistent? Because this vision does give way to a couple of weaknesses... One of these weaknesses is that if they can pin down where you are, and where you'll always be... Then they can shut you down.... The other is the need for a certain type of cash-flow to support the persistent servers... > > However, as I continue to read through this, I am of the belief that the servers you speak of could be EITHER a persistent server in the traditional sense, OR a peer-type server that is fairly transient... > > Change is not a bad thing...and this is definitely the type of thing I set myself up for by inviting new creative blood to come look, to come help.... > > I think that the changes you propose are worth pursuing. I think that certain services, under the new modified vision, would allow for the "Intranet over the internet" concept to remain, and at the same time widen the vision to incorporate many other takes.. > > This is all assuming that you haven't decided to ditch me for Grapevine ;-) > > ~Dave > > > David Scott Williams > Computer Associates > Marketing Representative-Sales Call Center > One Computer Associates Plaza > Islandia, New York 11749 > tel: +1 800-243-9462 ext. 73431 > tel: +1 631-342-3431 (Direct) > fax: +1 631-342-5734 > wi...@ca... > > > _______________________________________________ > Cxtable-devel mailing list > Cxt...@li... > https://lists.sourceforge.net/lists/listinfo/cxtable-devel > |