Just a collection of classes . . . or more?

Submitted by TizzyD on April 28, 2007 - 01:22.

Tagging Framework

Specifically:

Why no main factory class? Should you have something more akin to a MVC pattern set for starting the subsystem?
Should the taggable objects implement some type of observer? In that way, rather than having to directly call handleFileManagement, the object receives a signal back that something has changed. It might be a bit more cumbersome at first, but it would significantly improve the encapsulation.
I also think that you've let some leakage occur in a few of the classes. Case in point: NNTag shouldn't have a useCount. A calling app should just ask the taggedObjects collection for its count, not go through some method of the object.
I did not see any handling around serialization and archival. Is the expectation that any concrete classes implement those methods?
As I have mentioned before, I would have tags as something more akin to a common collection, rather than having each app implement their own. Apps may have private tags, but tags are public, shared across links, files, or anything else.

At least a few questions/opinions to start...
You gotta understand that I'm not so much of a bits and bytes coder but more of an application architect. So I think more about abstraction, encapsulation, and the means to extend/decorate or otherwise leverage components throughout an app. That's how I'm looking at this library.

Hey TizzyD, I will try to

Hey TizzyD,

I will try to clarify your questions

A factory pattern will be useful once the tags can be shared between apps, you are right. I think NNSimpleTag goes a long way, but sometimes it might not suffice. It should be fairly easy to implement something like that without breaking the API, so this will come as needed.
I don't really know what you mean by using the MVC pattern for starting the subsystem, could you perhaps elaborate on that?
You are right, this would be a better way. I think there was a reason why I didn't write it like that, but I have to check that again.
Yeah, you are right there, of course this could lead to problems, but calling taggedObjects actually starts a synchronous/blocking spotlight search for the tags, which could take some time, and so useCount is there as a performance enhancement, because Punakea needs it quite a lot for determining the tag size in the cloud, and there it doesn't matter if it is off by a bit.
This is all handled by NNTags at the moment. The developer can specify a location for the tag db (plist) to be saved, and every NNTag subclass has to conform to NSCoding, as does NNSimpleTag.
This is actually what we have been planning to do from the beginning. It is a bit more complicated though, there has to be a seperate process managing the tag db, etc., so we decided to wait if there was any interest before developing any further.

I hope I could answer some of your questions. If you have any other questions, or want to use the library in an application, please tell us!

Thanks for the quick

Thanks for the quick reply.

As for the MVC: A typical approach for such services, IMHO. I thought you'd use something like an NNTagManager, and then from that, an app would query all the tags. The NNTagManager would determine, based on user preferences, the underlying engine implementation--systems like a plist-based simple system or a more-robust service-oriented model--by composite. Thus, the implementation details of the actual engine are hidden--whether it's file based, database-based, or even network-based (?!)--but the ultimate implementation would be completely encapsulated. No way to errantly instance objects that should not be there, so to speak.

As for the count: I can see the optimization needed there, given Spotlight's poor performance. Is Spotlight necessarily the best engine for storing a tag for a document? It may be better to store such information separately, then update Spotlight as an additional option. From time to time, I have to completely rebuild my Spotlight indexes, and so I'm afraid such meta data is not persistent across rebuilds. Furthermore, given a real Core Data engine, you should be able to perform a count query with subsecond performance.

As for the service: yes, there is interest. You see, I'm sick of writing AppleScript/Python/etc. etc. to keep different plists in sync between apps.

I've been thinking for some time of the gap between the apps I use and the tagging they all perform. I use Mail/MailTags, iGTD, Journaler, iCal, del.icio.us (through Cocoalicious), Quicksilver, several Omni apps, and a few others I think would greatly benefit from a common tag service. I started doing some research to create my own, then to start to solicit input from the various development teams from each of the apps to have them consider putting in an interface to use the proposed tag library. Each app could have its own internal implementation and then an option to use the tag library.

If we want to talk more about this service idea, I'd love to get something more robust than just simple comments in a forum started. To me, this was to be the promise of WinFS, and I think we in the Mac community can easily do far better. I only wish I had their budget ;-)

. . . TizzyD

The framework is now

The framework is now opensource, you can have a closer look at it if you want to :). As you will see, there is work to be done, but hopefully we will have time to improve it after the next release of Punakea. In the meantime, if you want to do any work on it or have any comments, don't hesitate to tell us, we would welcome additional hands! :)

As for the Spotlight index. Don't be afraid, the tags are not stored in the spotlight index but in the .DS_Store file of the directory where the tagged file is in. Thus when the spotlight index is rebuilt, the tags are also indexed again. We do of course want to have additional means of storing this info.