pcplantdb

[Chad Knepp <pyg@galatea.org>]

Sorry to take so long to respond to this John, it's just that I don't
have much to add.

John Schinnerer writes:
 > Aloha,
 > 
 > > I also agree with what John S. said about this becoming a UI issue and
 > > we need to have a lot more discussion about it.  I'll repeat that I'm
 > > pretty open to implementing anything I can (within reason) that folks
 > > suggest.  I'm not really sure what questions to ask in this discussion
 > > so I'll leave it to others to bring it up.  
 > 
 > Well, we need to design our system architecture.  Block diagrams, that 
 > sort of thing, to start with.  We need to clarify/decide:
 > 
 > What are the components of our system?
 > Where are the logical separations between those components and what are 
 > the bridges across those separations going to be?
 > How will we go about maintaining separation of data/content, logic, 
 > presentation?
 > 
 > There is the data (data set) itself - pretty basic and obvious.
 > 
 > Then there is what I've been calling the 'data engine', a.k.a. loosely 
 > speaking the 'back end' or 'data server' (*not* the same as the physical 
 > server/computer we are hosted on).
 > 
 > There's the client(s), which provide or interface with some sort of UI 
 > (from CLI to GBI, many possible options) where users can get data from 
 > and put data to the data set (via the data engine, of course).
 > 
 > There's the UI itself, which is *not* necessarily tied 1:1 with a 
 > particular client (one client could provide or use several UIs, for 
 > example).
 > 
 > And then there's how each of these talks with the others (those they're 
 > allowed to talk with directly that is - for example a client talks to 
 > the data set only through the data engine, not directly).
 > 
 > The main immediate issue IMO is designing and implementing an 
 > Application Programming Interface (API) that the data engine provides 
 > for clients to communicate with it (and thereby with the data set).
 > 
 > The API should *not* implement any particular markup or presentation of 
 > data whatsoever.  That is the job of client software and UIs ('front 
 > ends').
 > 
 > The API *should* provide ways to ask the data engine to perform all the 
 > operations we can think of between a client and the data set (and be 
 > expandable to those we haven't thought of yet).  For example:
 > 
 > * It will take in a client request for information from the data set.
 > * It will return the correct data to the client in response to such a 
 > query (data *only*, not presentation!).
 > * It will allow a client to request a change in the data set (add, edit, 
 > delete, etc.) and will make the requested change if the client is 
 > authorized to make it.

Yep, exactly.  Documenting and developing the API contains a lot of
group level discussion issues. 

 > As we've discussed before, the API has to pass back content in some 
 > particular form so that the clients know how to manipulate what they get 
 > back.  Ideally it's a flexible and extensible form.
 > 
 > So far XML seems to have been the favored data transport method...in 
 > other words, the common 'language' that data engine and clients will use 
 > to communicate with each other.
 > Still true?

I'm on board with this.

 > We might also consider designing the data engine so that other 
 > mechanisms than XML could be implemented in the future.
 > That is, build a data engine with a default data transport module that 
 > uses XML and the ability (another API, actually) to use other data 
 > transport modules that use something other than XML.

Yeah, the data engine (or sub-client layer) could convert the XML to
anything really.

 > Anyhow...Chad, unless you've already got data engine and client 
 > separated in your Eden code and just haven't told us, IMO our most 
 > urgent need is to make that separation via designing an API for your 
 > data engine.

It is in fact quite easy to separate the data engine and client in
Eden.  Html.py/Text.py are client specific and everything else except
for Session.py (which currently provides the interconnect between
client and data engine) is the data engine.  Actually Kfml.py (methods
to generate XML from the data) should be more general than it is and
currently does some things that should probably be in the client
although this would introduce redundant code in the clients...

All of the above ideas are pretty much exactly what I had in mind 18
months ago when I wrote Eden.  I will continue to work on the
distinction between client and data engine and perhaps should move to
creating separate release packages for them.

 > cheers,
 > John S.

-- 
Chad Knepp
python -c 'import base64;print base64.decodestring("cHlnQGdhbGF0ZWEub3Jn")'