pcplantdb

[John Schinnerer <john@eco-living.net>]

Aloha,

Thanks for the questions and input...I'll leave some replies to the rest 
of the gang...

> XML is fine for capturing complex data sets, but isn't
> always the answer.  With a properly defined data
> model, and non text data, XML would be over kill.

I am also no fan of XML's overhead.
However it is familiar and popular and would do the job.

>  I wonder if the consumers of the data you will serve
> have been defined.

We are designing to have a clean API for the data engine that will 
support a wide variety of clients, from vanilla HTML (and even text/cli 
if desired) to graph-based UIs and all sorts of other possibilities.
At this point XML is (I think... :-) our initial data transport 
mechanism of choice.

>  If you plan on thin client apps
> (Java/browser) being your only consumers, XML is fine.
>  However, a more involved site might want to reduce
> network traffic with a more traditional record based
> feed (perhaps even compressed and over ssh
> channels(scp)).

One way to deal with bandwidth issues is to have part of a 'fat' client 
actually run on the server, and use some more-efficient-than-XML 
transport mechanism to pass information back and forth to the remote 
part of the client.

For example to take the XML overhead out for really low-bandwidth 
clients that are passing a lot of actual data, a piece of 'client' 
process on the server could talk XML with the data engine and then strip 
it down to something leaner and meaner and pass it on to the remote 
piece of the client (works both ways of course).

John S.

--

John Schinnerer - MA, Whole Systems Design
------------------------------------------
- Eco-Living -
Whole Systems Design Services
People - Place - Learning - Integration
john@eco-living.net
http://eco-living.net