[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gallery-devel
Subject:    Re: [Gallery-devel] [SoC] Tagging Terminology (Was: Image Tagging
From:       Paul Hinze <paul.t.hinze () gmail ! com>
Date:       2008-05-30 18:33:50
Message-ID: 20080530183350.GB3478 () beany ! gateway ! 2wire ! net
[Download RAW message or body]

Wow, great feedback everyone.  I'm very grateful for all of your
insights and opinions on this new feature.  Let me sort through some of
the responses and make some comments.

First of all, you have all correctly identified the problem of
terminology, which is definitely something we need to sort out in order
to be able to talk about this in a way that makes sense.  

I think Chad has the right idea when he talks about this feature as an
extension of both comments and tags.  I think the most intuitive way to
think about this project is *not* as adding a whole new *type* of extra
data but rather as adding support for a new *relationship* between
certain existing forms of extra data and specific regions of an image.

- Flickr:   "note" --> *comment* + *region*
- Facebook: "tag"  --> *tag*     + *region*

Gallery already has fairly solid support for both comments and tags, so
let's use what we've built.  I think the most elegant way to handle this
new feature would be to have it add the ability to associate a region of
an image with other Extra Data modules (within reason--looking at the
list of modules I'm thinking tags, comments, and maybe custom fields).
So when the feature is active, your tags and comments can also be mapped
to specific regions of an image if you so choose.

I agree with Andy that a monolithic Tags module is incompatible with the
Gallery Philosophy.  But...

> On the other hand, there's no module-dependency framework yet. If we
> want to avoid code and functionality duplication, a "image annotation"
> module would need to depend on the "tags" module to reuse its tag
> cloud, tag storage, tag albums, etc.
>
> Say a user wants the "image annotation" feature, the framework should
> figure out that it depends on the "tags" module in version x.y and
> install the tags module in the background.
> 
> But we're not there yet.

Andy's right that a module dependency framework is what would be most
useful here.  The "Image Region Support" (badass name pending) module as
I'm picturing it needs to interact with other modules that may or may
not be installed and may be of varying versions.  But we don't
necessarily *need* a full MDF--we can just have the new module check
what it needs to check.  This is more or less Andy's solution (B):

> B) Identify the parts in the tags module that can be reused (API, tag
> cloud, tag album, etc.), refactor them slightly such that they can be
> exposed via an API / factory implementation / block and reuse them
> from your module. Add some code in the module's needsConfiguration() /
> autoConfigure() method to verify that the tags module is installed and
> active.

This is the direction in which I'm planning to start working.

> Remember: The tags module still needs to be moved to the official
> codebase.  It still needs some cleanup and tests.

If we can identify a list of things that need to be done, I might be
able to take care of this along the way.

Thanks again everyone, and keep the comments/thoughts/$0.02 rolling in!

Paul

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]
[prev in list] [next in list] [prev in thread] [next in thread]