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

[firefly-dev]

On Tue, 2003-04-01 at 23: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? 

well it's not only a big hash :)
I'll put an image file of the db scheme in the cvs this evening.

>heres a possibility that came to me
> when waiting for the eye doctor today.

<cut>

It's a very nice idea.

> 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.

ok but don't forget that i/o operations are much prone to errors than a
db operation, however this shouldn'be a big issue to resolve, you're
right.

> if is stays xml from the core, i would think many
> programs can work with it. 

I think this is what I'm missing, what do you mean with many programs ?

> 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. 

ok I know the efficiency of perl with strings manipulation but u can't
even compare the parsing of a file in perl with retrieving data stored
in a db well designed and normalized.
The time you need to search the file and open it with the filesystem way
you already have the data in a variable with the db way.

However I admit that I'm too used to think at the way more efficient
rather than the easier or more handy :)

>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).

I agree.


Marco