Mail Index

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: meta info for images... db?

Something like this would be awesome to have a db in Apache:gallery.

Take a look at this

I still like Apache:gallery better but we might be able to get some
ideas from EE.

Take a look.

-----Original Message-----
From: Saadiq Rodgers-King [mailto:[email protected]] 
Sent: Wednesday, July 31, 2002 11:06 AM
To: Dave Preston
Cc: [email protected]
Subject: Re: meta info for images... db?

The question of going with the db or not seems to be dependent on how
much information you want to store for your pictures.  It seems most
people here are content with just a comment.  I've been thinking about
it and these are the types of things I'd like to store for each image.

numeric id
file path
when taken
people in image
when added to gallery

For that type of thing, a db would certainly be useful. And as Michael
mentioned, the information would need to be editable from the web.

Once you have all that info it would be nice to search on it and then
browse the images by location or people in it.  Once I got over my most
recent bout of procrastination I was going to work on adding that for my
personal use.  I figured I'd make an attempt to have it configurable so
that a db backend is just optional and Apache::Gallery would still be
what it is without.

These have just been my thoughts.


On Wed, Jul 31, 2002 at 06:17:56AM -0700, Dave Preston scribbled:
> On Wed, Jul 31, 2002 at 09:31:36AM +0200, Michael Legart wrote:
> > So we need a admin interface, right? Should we let the httpd write 
> > imagename.xml/meta files along with the pictures or what does people
> > think about using a database instead? Is that a too big requirement
> > for the gallery?
> I'd keep it simple, if we're only talking about providing data for
> rotation and comments xml would be easiest for all parties.
> blah.jpg.xml or maybe just blah.xml
> <rotate>0</rotate>
> <comment>This is my photo. There are many like it but this one is
> or some such...
> It just seems better to me than adding a db and db abstraction layer
> dependency for such a simple task.