[Pipet Devel] Data Storage Interfaces

Justin Bradford justin at ukans.edu
Fri Jun 11 17:08:42 EDT 1999

> > would be simpler if the DM just passed the whole xml file (in other words
> > the interface deals with xml entities only and not parts of entities).  On
> > the other hand, if a user just needs one part of the entity, the whole
> > entity must still be transfered over a potentially slow network
> > connection.
> That's a good point.  We haven't considered slow networks or very large files.

I have, and that's my problem with 
1) how Paos passes objects -- it sends the whole thing. I would prefer
   just sending updates. Breaking up the data into linked objects could be
   an adequate compromise.
2) the independently roaming object concept where it's passed directly
   from tool to tool. Without a "home" everything has to be passed, and by
   the end of a complex series, that could be a large object.

> > The alternative is to have the xml parsing take plase on the
> > DM side of the interface.  This would allow for only the requested element
> > to be transfered. In addition, only the requested portion from a non xml
> > data set would have to be wrapped in xml. So despite the additional
> > complexity, it would seem that having the interface be aware of xml parts
> > and not just entities would be highly advantageous.
> Hmmm.  I'd like to hear what Justin, Humberto et al think about that.

I think I was addressing similar issues in my previous mail.
Your second alternative is roughly a description for DOM (including level
2, however), except DOM doesn't make the programs directly write and parse
it's own XML whenever it crosses an interface. At the lowest level, it
might actually be straight XML passed across the network, but the
interface should abstract that.

I'm beginning to think the optimal solution is a virtual interface (or set
of optional interface) across all junctions. It's the most efficient (only
what the receiving end wants is sent [and only the receiving end
really knows what it wants]). It's completely language independent, as
well as "junction" indepedent (each end has a standard interface,
regardless of whether a C, Python, or Perl script is on the other end, or
whether the two are communication via CORBA, TCP/IP, UDP/IP, shared
memory, a pipe, a dynamically-loaded plug-in interface).

This interface method requires a home location where the object resides
throughout its processing life-time. This is what I had envisioned the
work flow system to be (ie. coordinating it's various objects, where
and when they connected, etc). This could be located on the client
machine, and it allows the various other loci to be really dumb (which
means small).


More information about the Pipet-Devel mailing list