Hey Here is my take again on the issue
An event is something that happens
Something happens needs and application to triger it and a target on which
the happening takes place (in our case a doc, note or webpage)
So my current proposal is to send around a tuple of 2 dicts that describe
1. eventinfo: timestamp, app, eventype, eventtags and eventbookmark (if
this specific event is important)
2. targetinfo: name, uri, tags, comment, mimetype, origin, source,
I think this makes sense to be honest and I hope most of you agree with me.
This way we can clearly sperate the info we have. PLEASE PLEASE AGREE :P
2009/7/16 Mikkel Kamstrup Erlandsen <mikkel.kamst...@gmail.com>
> 2009/7/16 markus korn <thek...@gmx.de>:
> > I just found a few issues and a few things I would like to discuss:
> > 1a.) although it is stated here otherwise, mimetype is not an optional
> > entry, the engine itself will discard events without a mimetype
> > 1b.) is mimetype really required for an event? Seif: as you are
> > working on this application watcher, what is the mimetype of a
> > CloseTab/CloseWindow event?
> I think that mimetype should be optional. By definition the mimetype
> of an item is about the binary format of the datastream the item
> represents. Events does not have binary datastreams hence they can not
> have a mimetype.
> The best approach is probably to require on on items that do have a
> datastream associated with them. In the case of Zg this probably means
> all non-event types...
> > 2a.) for the same reason, what is in such case the 'uri' of a
> > closetab/closewindow event?
> In the case of events I think it is the duty of the engine to assign
> them. This is a problem in the Zg API - not differentiating between
> "real items" and events.
> > 2b.) is 'uri' really required? What is the uri of a tag added as an
> > user activity (adding via GUI or such)?
> Like events, tags are not real items, but pure metadata and are
> probably best off if Zg internally provided a uri for them.
> > 3.) aren't "timestamp", "source", "content" the only required items?
> To some degree yes. Although that is probably really rooted in a
> problem with the API.
> > 4.) what should the engine do in case of invalid event dicts (required
> > items missing, wrong type, unknown keys like 'time', 'mimetypes' or
> > 'somerandom'? raise an Exception (noticed by the client) or just print
> > a warning to the logs and discard the event (client does not know
> > about it). currently we are doing a mix of both.
> Only if the engine can be absolutely certain that it is not dropping
> important data can it drop stuff silently. Genereally I am in the
> favor of throwing meaningful DBus errors whenever we decide to not
> accept data.
> Strictly defined error handling is just as important in an API as the
> return types of methods. Otherwise apps are shooting completely in the
> About the API: The current problem with the API is that we have a "do
> it all"-method, namely InsertItem(). The semantics of this method is
> really unclear. Zg deals with roughly three kinds of objects: Events,
> Real Objects(files, web pages, etc), and Virtual Objects (tags,
> ratings, and other annotation types). I think we must be very clear
> about how each type is handled. This may mean separating the API in to
> different parts.
> Mailing list:
> Post to : firstname.lastname@example.org
> Unsubscribe :
> More help : https://help.launchpad.net/ListHelp
Mailing list: https://launchpad.net/~zeitgeist
Post to : email@example.com
Unsubscribe : https://launchpad.net/~zeitgeist
More help : https://help.launchpad.net/ListHelp