[Pipet Devel] Data Storage Interfaces

[Alan J. Williams]

On Wed, 23 Jun 1999, J.W. Bizzaro wrote:
 > Yeah, I'd go with a free database.  There is also MSQL and PostgreSQL (and
 > BerkeleyDB?).  I'm not sure about AceDB, but PostgreSQL has a BSD license; MSQL
 > and MySQL are not free for commercial use.  I was just thinking that Oracle
 > would be a huge prerequisite for a program.
Yeah.  For the single user or small lab user any relational database may
be too much to setup and maintain.

With loci I think we want to allow for data access and storage to/from
robust relational databases, but it isn't the job of loci to
setup/maintain/administer those databases.

 > Hmmm.  I think I get it now.  So, DM is almost an abstraction layer for
 > plug-ins, an "interface" or API?
Exactly! A data access abstraction layer! Of course this abstraction layer
should be designed with the data passing through the workflow in mind.
Data exchange through the workflow could be accomplished through the same
API as documents are stored and retrieved by.  

 > Well, I'm thinking of something that any locus can talk to at any time and that
 > can provide a seamless interface across networks.  I'm not sure how this would
 > work is the deamon is really deamons, and some might be there and some might not
 > be.  It seems like you would still need some central manager to keep track of
 > what is what, which is really what Locid would do.
This is one of the parts I haven't thought out yet.  How do we keep track
of and advertise data sources. CORBA has this functionality, but do we
want to force all data sources to use CORBA?

 > It sounds like we could be working on the same project.  Enough of Loci's data
 > management model is still unimplemented and up in the air, that we could come up
 > with something by working together on this.  So, we'll use DM's, if everyone
 > likes the idea.  I'm flexible, and this isn't The Bizzaro Project :-)  If we
 > work together, it would just be more likely we'll have something successful.
I am exited enought about the goals of Loci that I will focus my efforts
on Loci and not GST.  Having said that, I am in my last year and have a
huge dissertation to write up! Ug! Needless to say, I am not sure how much
I can commit to. (Although coding for Loci would be infinitely more
exciting than writing a dissertation!)

 > We spoke before about licensing issues, and the problem was that if Loci uses
 > the GPL, it could not be extended with something that has your own license (APL
 > - Alan's Public License :-).  But if Loci uses the LGPL (Lesser GPL), which we
 > could if we don't include straight GPL parts, you could extend Loci with your
 > own stuff and use whatever license you want.  The LGPL is the same license that
 > the Gtk+ toolkit uses, and you're using that already.
When we talked about license before, I wasn't really thinking about this
angle, but I think your right.  We may need to look at licensing the core
components of loci under the LGPL and the different modifiers, viewers,
etc, under the GPL.  I am sure that the GNOME and KDE developers have
already had to deal with this.  I think the GNOMEish way is to use BONOBO
to connect modules.

 > Personally, I'd love to see Loci extended and find its way into all sorts of
 > places and uses.
Heck, I just want a great bioinformatics package that newbies can jump
right into and old-timers can twist around. Oh yeah, anything that will
make the windows and mac users green with envy wouldn't be too bad either.

************************************************************************  
Alan Williams           
------------------------------------------------------------------------  
University of California, Riverside   "Where observation is concerned,
Dept. of Botany and Plant Sciences     chance favors the prepared mind."  
Alan at TheWilliamsFamily.org                         -- Louis Pasteur
************************************************************************