---------- Forwarded message ---------- From: Seif Lotfy <s...@lotfy.com> Date: 2009/8/2 Subject: Re: [Zeitgeist] Zeitgeist API Ramblings To: Siegfried Gevatter <rai...@ubuntu.com> Cc: Mikkel Kamstrup Erlandsen <mikkel.kamst...@gmail.com>, zeitgeist@lists.launchpad.net
Most of the magic is the expiring tags crap and some similar usages and tags! However my main concern now is we have to move along and not depend on the fact that tracker wants to release! Give me a release and then we can see if we can depend on it! Let us concentrate with our current tools and release something stable and reac hthe dead end before we start rethinking everything because we will always want to change stuff thus never actually delivering! So now we stay with SQLite and our current DB design (- endstamps) we can take another lok at the queries again to create better indecies! As for events: Mikkel kinda summed up the ontology of events: > Zeitgeist Items has metadata such as content type, mimetype, source type > (where they are from fx. filesystem, web page, email account, …), URL. > > Events have such metadata as timestamp, the app emitting the event, what > type of event (user action, system notification), what happended (created, > modified, deleted, etc.), and some more. > To sum up: FindEventsOnly will return 1 dict with the eventinfo EventInfo: - timestamp - source (uri of actor or app) - subject (uri of the target as in doc or whatever) - type (activity, notification) - action (created, modified, deletec, etc..) - -------------------------------------------------------------------------- - tags (marking this special event) - bookmark (also marking this special event) FindEvents however will retrun the EventInfo dict as well as the following dict (How we do it will be optimized i have a solution for that) TargetInfo: - We will stay with our representation<http://live.gnome.org/GnomeZeitgeist/DatabaseDesign#head-fd4ae10d36917f617c003262560bedc9a927bd93> Tell me what you think Seif 2009/8/2 Siegfried Gevatter <rai...@ubuntu.com> Hey, > > I have to admit I haven’t looked at Tracker yet (so maybe once I see > it I may change my opinion), but at the moment my idea is that once > Tracker supports events (so that we can store everything in there and > don’t need to keep events in our own database, which wouldn’t work > performance-wise given the sort of queries we have) we should switch > over to it. > > With that approach I’d see Zeitgeist kind of as an “extension” to > Tracker, where it’s functions would be on one side, the logging of > events, and on the other providing a high-level D-Bus API to easily > access events and to get relationships between them (Seif’s magic); > this way we get to keep a very simple to use API but applications > needing more advanced stuff (or maybe requiring more fine-grained > control on what to fetch for performance reasons) have the chance to > query Tracker directly. What are your thoughts on this? > > This Tracker stuff would probably be something to discuss at the > end-of-the-year Hackfest (if we get to do it - I hope so), I just > thought I'd say this now before someone gets the idea to implement > some weird query system in Zeitgeist :). > > What I think we really need to decide now is how we want to represent > events and items (when returned by FindEvents et all). > > -- > Siegfried-Angel Gevatter Pujals (RainCT) > Ubuntu Developer. Debian Contributor. > >
_______________________________________________ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
