Re: [Firefly-dev] firefly - a bit from gimpy

[firefly-dev]

I have been going over this quite a bit with myself. I would really like
to keep alot of xml in here as possable. I will have a real problem if
this is just another sql project. I got the idea for this project
because I want something in a library that is very cross format and can
be ran on just about anything that has a processor. We should really
start addressing this and trying to figure just how we want the db. I do
not mind using postgresql or Mysql. I would just rather have it so that
the information in the file can be parsed by many a program and can kick
it back out into many different format. If it slows it down a bit that
is worth the cross platform expanditure. Let me know your thoughts,
John Hornbeck


On Tue, 2003-04-01 at 15:55, address@hidden wrote:
> a few things. first, i thought john wanted it to be in
> .xml so it can be used by any other software. i can
> understand if there is a bit more overhead though. but
> are we just gonna have one big hash of all the data in
> (my/postgre)sql? heres a possibility that came to me
> when waiting for the eye doctor today.
> 
> store all patrons and staff in one directory
> with their lastname as the name of the .xml file
> 
> /people or whatever can be the directory
> so it'd be /people/lastname.xml to search for and play
> with
> 
> then have /books /films /newspapers /etc /etc /etc
> 
> newspapers and the like can have abbrev. titles and a
> dash then the date or something like that
> /newspapers/LC-4-1-03 and the like or a new folder
> created for each day with all newspapers in there for
> that day, but that may be a bit too far fetched
> 
> have a unique id_number added to the patron.xml so it
> can be inserted into the book.xml when that book gets
> checked out. the book_id can be placed in the users
> xml and have a tally tag that says how many the patron
> currently has out. and a checked in/out tag in the
> book.xml so searches for the book tell whether its
> currently there or not
> 
> for the fear of several people modifying a xml doc at
> the same time, it can always flock() that xml file
> when ever it is opened to be edited, and will only
> write to a certain tagged area. no data will be lost
> or corrupted.
> 
> if is stays xml from the core, i would think many
> programs can work with it. but i know there are
> modules that allow for, say perl, to work extremely
> well with sql databases. and im not sure which would
> be easier for plugins to work for (but im betting on
> sql).
> 
> the whole xml backbone is only an idea. if the
> overhead will be more than the sql-ness or anything
> else we come up with or can find something easier to
> work with, then lets go with that instead. i know
> nothing about which is faster, sql or something else,
> so i need to find out. but perl has xml parsers and
> perl has always been fast and efficient with strings
> and text files. again its only an idea. but i would
> like to have some definates soon, so i can start
> learning the language of choice and find out how i can
> manipulate what i can with perl (no use letting my
> perl knowledge go to waste now).
> 
> --- address@hidden wrote:
> > That patron.xml was a mook up of a idea I had. It is
> > not going to be
> > something that stays. I did not even mean for it to
> > go into cvs. I know
> > what you are saying about how slow it is. What would
> > you like to discuss
> > about OOP?
> > John Hornbeck
> > 
> > 
> > On Mon, 2003-03-31 at 16:57, address@hidden
> > wrote:
> > > Hi,
> > > 
> > > I would like to ask you one thing about patrons
> > management.
> > > In the cvs repository there is a file called
> > patron.xml whose purpose is
> > > still not very clear to me.
> > > I really hope you do not intend to manage patrons
> > with xml files, it
> > > would be a nightmare. 
> > > 
> > > Just think about a simple loan, in the db you have
> > to store the user_id
> > > of the patron who loaned the book, and where do
> > you take it from if it
> > > is not in the db ?  from the xml file ?  
> > > This mean that you have to parse the xml
> > file(which require to create a
> > > sax parser to go through the file until it founds
> > what we need, or even
> > > worse create a dom representation of the entire
> > file in the memory) and
> > > put in the query the results of the parsing
> > operation.
> > > This is *terribly* slower than a simple db
> > operation, at least a million
> > > time to be optimistic, and don't forget the
> > overhead caused by the
> > > network connection(and the encriptions of the data
> > with ssl).
> > > Also you must take care of concurrent access to
> > files, what if two of
> > > the staff modify at the same time a patron's
> > details ? In the worst case
> > > this may empty or erase the file...
> > > 
> > > I use often xml at work and it sure has many uses
> > but it can't and must
> > > not replace a db.
> > > 
> > > Actually I see two possible uses for xml in this
> > project:
> > > 
> > > 1. an hipothetical "registry" that serves as a
> > glue between core app and
> > > plugins. 
> > > This is absolutely required if a plugin is written
> > in a different
> > > language than the core, plugins and core can
> > exchange data between
> > > themselves in an xml format (soap, wddx etc...),
> > without requiring CORBA
> > > or stuff like that.
> > > 
> > > 2. we can retrieve data from the db in an xml
> > format suitable to be
> > > transformed with an xslt stylesheet(this can be
> > easily been done with
> > > openjade but I don't think windows has something
> > like that...) in the
> > > formats we want.
> > > 
> > > Another thing, considering the features of this
> > app and especially its
> > > "modular" nature, I would like to discuss with you
> > about a more object
> > > oriented development approach.
> > > 
> > > 
> > > Let me know what do you think.
> > > 
> > > 
> > > Marco
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Firefly-dev mailing list
> > > address@hidden
> > >
> > http://mail.nongnu.org/mailman/listinfo/firefly-dev
> > -- 
> > John Hornbeck <address@hidden>
> > 
> > 
> > _______________________________________________
> > Firefly-dev mailing list
> > address@hidden
> > http://mail.nongnu.org/mailman/listinfo/firefly-dev
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - File online, calculators, forms, and more
> http://platinum.yahoo.com
> 
> 
> _______________________________________________
> Firefly-dev mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/firefly-dev
-- 
John Hornbeck <address@hidden>