Creating tags/categories from FileImportBackend

[Warren Baird <photogeekmtl gmail com>]

Hi all,

So, in the interest of actually getting my data out of iPhoto before the 
end of the year, I've gone ahead and implemented a very simple xmp 
import mechanism that just assumes that any strings it finds in a bag 
are a tag that should be attached to the current photo.   This avoids 
all of the SemWeb issues I'm talking about in the other thread.

However, to get this to work, I ran into a couple of architectural 
issue, and I'm not sure how best to resolve them.

Issue 1:  TagStore is hidden inside PhotoStore.

FileImportBackend has the current PhotoStore, but it doesn't have a 
TagStore --- if I'm importing tags, I have no way to find the tag 
associated with a string without the TagStore.  The hackish solution I 
took was to add a GetTagByName() method to PhotoStore that is a slightly 
smarter wrapper around the TagStore method --- if the tag doesn't exist, 
it creates it at the top level and returns it.

I'm not 100% satisfied with this, since it doesn't seem like the 
PhotoStore should care about tags or their names, but functionally this 
works.   the only other viable solution I could think of would be to 
actually include a TagStore in the FileImportBackend object itself... 
But that seemed a big heavyweight.

Any preferences?   Is exposing the retrieval/creation of Tags and 
Categories through the PhotoStore Api acceptable?

Issue 2:  Deleting created tags on cancel.

To really be consistent, if the user tries to import from a directory 
and then cancels, we should probably delete any new tags that were 
created as part of the import operation.   Unfortunately this means that 
my current solution needs to be extended, since currently the 
FileImportBackend never knows which tags are new and which already 
existed.

It might be easier to just be sure we provide an easy way to delete 
unused tags - or groups of tags...

Any suggestions/comments/ideas?

So I'm basically fairly close to getting an import solution that is good 
enough for my purposes - it won't handling importing generic xmp data, 
but if you don't have any other bag entities it works fine.    I'll try 
to implement a more general solution if I can, but once my itch is 
scratched, I'll probably be more interested in spending time on the next 
6 f-spot issues that are itching me.   Do you think it makes sense to 
submit a patch for what I have, even if it isn't fully general?

Thanks,

Warren