zeitgeist team mailing list archive

[Mikkel Kamstrup Erlandsen <mikkel.kamstrup@xxxxxxxxx>]

2009/7/16 markus korn <thekorn@xxxxxx>:
><SNIP>
> 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
dark.

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.

Cheers,
Mikkel