[Firefly-dev] firefly - a bit from gimpy

[firefly-dev]

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