[dev] Horde_Share_Base::listShares()

Chuck Hagenbuch chuck at horde.org
Sat Jan 15 21:11:44 UTC 2011


Quoting Michael Rubinsky <mrubinsk at horde.org>:

> Quoting Chuck Hagenbuch <chuck at horde.org>:
>
>> One of the lessons for me from the DataTree library was that mixing  
>> trees in with storage *and* auth was a nightmare for scaling. I'd  
>> rather keep the tree structure out of the Share driver, and  
>> potentially even move Ansel to tags instead of explicitly nested  
>> galleries...
>
> I'd *really* like to keep the ability to nest galleries. I like to  
> explicitly group images together in a gallery tree, and give each  
> grouping/sub-gallery a nice caption and description. By using *only*  
> tags-as-navigation you lose some of that flexibility. Depending on  
> how the user tags their images, this can also get unwieldy. It is  
> not uncommon for people to have a fair amount of tags on each image  
> e.g., the lens used, environmental descriptors (fog, rain, clouds),  
> type of scene (landscape, portrait), dynamic range... you get the  
> idea. If you are talking about making pseudo-galleries out of each  
> tag present on each image in that gallery, then you'll end up with  
> potentially hundreds (alright, maybe a slight exaggeration) of  
> "sub-galleries" under each top-level bucket along with some images  
> that aren't tagged at all. You would also likely have many of the  
> same sets of subgalleries under each top-level bucket.  This also  
> comes with it's own set of performance and usability issues.
>
> Navigation wise, because of the way I like my galleries structured,  
> if I'm looking for images from my cousin's 2nd birthday party, I'd  
> have to probably navigate to the "Family" bucket (assuming we still  
> have top level buckets/galleries), find the "birthday" tag, then  
> find the "Jessica" tag - assuming I've managed to tag every single  
> image with the proper tags to do this. I'm guessing generating a  
> permalink or utilizing a slug for this collection of images wouldn't  
> be pretty either. I'd prefer to just dump all the images into a  
> "Jessica's Second Birthday Party" gallery in my gallery tree - under  
> the Family gallery - and if I want every image in the gallery to be  
> found by a certain tag search, I can just tag the gallery instead of  
> having to tag all 50 images.
>
> Yeah, I could change my tagging scheme, use what I want as a caption  
> as the tag text, or just resign myself to using all top-level  
> galleries, but I like structuring my galleries in a certain way,  
> without having the application's limitations dictate how I have to  
> organize things.
>
> Don't get me wrong, I like the idea of browsing tags as galleries -  
> and that is already possible across all galleries in Ansel. I just  
> also want to have the flexibility to explicitly create a nested  
> gallery structure.
>
> Setting aside my personal preferences, I have found it tricky to  
> deal with permissions during tag searches, since the permissions are  
> not directly associated with the image, but with the image's  
> gallery. I have had to wrestle with this in Ansel while implementing  
> the tag browsing. There is no way to filter on permissions during  
> the tag search phase or to ascertain permissions on an image  
> returned by that tag search without first loading each returned  
> image's gallery. This might not be as large an issue if we still  
> have top-level buckets, since every image within the bucket would  
> have the same perms, but that still comes with it's own set of  
> usability issues/questions...
>
> Eh, just meant to say "Please don't remove nested galleries." I  
> guess I got a bit long-winded and carried away. Move along, that is  
> all... :)

Fair enough - how do you feel about merging the hierarchical and  
non-hierarchal drivers, though? :)

-chuck


More information about the dev mailing list