[Cxtable-devel] RE:p2p, the next generation..brainstorm

[Williams, D. <DAV...@ca...>]

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
> 
>