I posted this suggestion in the Features and Bugs area
anonymously by mistake.
For those of use that run a webserver locally on either
Unix/Linux or even Windoze systems, it would be *very*
useful to be able to identify/point to an existing
local directory structure of images and have Gallery
simply scan through the directory(ies) and create
Albums for each directory. In the current
implementation, Gallery requires that all images be
uploaded to a webserver. This assumes that the user is
using a remote server in all cases to host the image
galleries. For those of us (and I suspect quite a few
of us) that run a webserver on our local system
(particularly Unix/Linux/Win2K/WinXP/MaxOSX), uploading
images simply creates duplicate copies of all of our
existing images, effectively wasting a considerable
amount of disk space on the local filesystem.
In creating the albums, the thumbnail and re-sized
images could either (a) be located in a user specified
directory tree or (b) located within subdirectories
within each directory containing the source images.
Obviously, it goes without saying that both the local
image directories and the thumbnail/re-sized image
directories would have to be visible to the locally
running webserver.
Posted: Sun, 2002-11-24 05:55
Posts: 7994
There are several issues with this. Yes, it's possible for G2 to scan your existing
directories and build albums from this structure. However, G2 really needs to have
its own copy of your files, if for no other reason than that it needs to be able to
move things around. I do plan to introduce the concept of an "image via URL"
item where the item in the G2 database is just a URI of a remote image. This
may do what you want .. but it also forces G2 to rely upon external data that may
go away without its knowledge. For now, it'll expect you to provide it with an
image and then manage that image itself.
I'll discuss your thumbnail location issues in your other post.
Posts: 4
when you say that G2 needs it's own copy of the data are you referring to the original or derivative images? Where exactly is this handled in the code, ImageContainer?
Posts: 7994
Oops, I see from your comment that you're probably looking at the API docs which
are sadly out of date. I've regenerated the API docs so they're more current now.
For those of you reading along, the API docs are here:
http://gallery.menalto.com/modules.php?op=modload&name=GalleryAPI&file=index&include=phpdoc_packagelist.html
(you can get to this by clicking "Dev Documents" to the left).
Albums, photos, and all other manageable objects in Gallery are instances of classes
that extend GalleryItem. Photos are stored as GalleryDataItem objects. A GalleryDataItem
is an item that stores and manages an actual data file (with a file extension,
mime type and size). Right now, I've only implemented 4 types of GalleryItem:
GalleryAlbumItem, GalleryMovieItem, GalleryPhotoItem and GalleryUnknownItem.
A GalleryAlbumItem manages a directory (and extends GalleryItem directly)
while the other three extend GalleryDataItem and expect to manage a file.
When using those three classes, Gallery expects that you will give it a file that it
can place into its directory tree and manage (rename, move, copy, etc).
Later on, we could introduce a GalleryLinkItem that extends GalleryItem but
can link to another object (either internal or external to Gallery) so that we
could (in theory) allow Gallery to manage external objects. This might
let us get Gallery to the point where you could give it a tree of objects
that live elsewhere on the filesystem and let it maintain links to those
files instead of copying them. Of course, that may run up against a lot of
open_basedir issues if the server is not configured properly, but it would
probably work.
Posts: 4
Ah, sorry about that. My memory of your class names was failing and I figured the api documents were being generated off CVS on a regular basis (no clue why I expected that, I just did ;] ).
This GalleryLinkItem is what interests me, I'll have to see what I can do about it, though it may be some time. Finals are coming.