Re: [Zeitgeist] Zeitgeist API Ramblings

[Seif Lotfy]

And thus my suggestion to return only the event logs and optional another
dict of the uris and their metadata

2009/8/2 Mikkel Kamstrup Erlandsen 

> 2009/8/2 Siegfried Gevatter :
> > SNIP...
> > What I think we really need to decide now is how we want to represent
> > events and items (when returned by FindEvents et all).
>
> I think you hit the nail on the head here. I think the current Zg API
> leaves a blurry line for what Zeitgeist actually is. If we really
> stick to the "Zeitgeist is an event log" mantra we should not have to
> know about Items at all...
>
> If we move closer to the "log" concept the individual targets of a
> logged event consist solely of the data that is provided at event
> registration time. Just like a line in a log file only consist of the
> data you put there.
>
> As it stands you log an event on some given subject URL and Zg
> automagically knows something about this URL. This implies that Zg is
> also some weak content repository which is a bit problematic from a
> pedagogical point of view - and maybe also from a "separation of
> responsibilities point of view".
>
> --
> Cheers,
> Mikkel
>
>
___
Mailing list: https://launchpad.net/~zeitgeist
Post to : zeitgeist@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zeitgeist
More help   : https://help.launchpad.net/ListHelp

Re: [Zeitgeist] Zeitgeist API Ramblings

[Mikkel Kamstrup Erlandsen]

2009/8/2 Siegfried Gevatter :
> SNIP...
> What I think we really need to decide now is how we want to represent
> events and items (when returned by FindEvents et all).

I think you hit the nail on the head here. I think the current Zg API
leaves a blurry line for what Zeitgeist actually is. If we really
stick to the "Zeitgeist is an event log" mantra we should not have to
know about Items at all...

If we move closer to the "log" concept the individual targets of a
logged event consist solely of the data that is provided at event
registration time. Just like a line in a log file only consist of the
data you put there.

As it stands you log an event on some given subject URL and Zg
automagically knows something about this URL. This implies that Zg is
also some weak content repository which is a bit problematic from a
pedagogical point of view - and maybe also from a "separation of
responsibilities point of view".

-- 
Cheers,
Mikkel

___
Mailing list: https://launchpad.net/~zeitgeist
Post to : zeitgeist@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zeitgeist
More help   : https://help.launchpad.net/ListHelp

Re: [Zeitgeist] Zeitgeist API Ramblings

[Seif Lotfy]

Siegfried had a very nice idea of having two arrays as a return
one with all the eventinfos and one with all the iteminfos
this way we need to query the info of the events as well of the items only
once

2009/8/2 Mikkel Kamstrup Erlandsen 

> 2009/8/2 Seif Lotfy :
> > SNIP ...
> > 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)
>
> It needs to be an array of item dicts. An event can have several targets.
>
> --
> Cheers,
> Mikkel
>
>
___
Mailing list: https://launchpad.net/~zeitgeist
Post to : zeitgeist@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zeitgeist
More help   : https://help.launchpad.net/ListHelp

Re: [Zeitgeist] Zeitgeist API Ramblings

[Mikkel Kamstrup Erlandsen]

2009/8/2 Seif Lotfy :
> SNIP ...
> 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)

It needs to be an array of item dicts. An event can have several targets.

-- 
Cheers,
Mikkel

___
Mailing list: https://launchpad.net/~zeitgeist
Post to : zeitgeist@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zeitgeist
More help   : https://help.launchpad.net/ListHelp

Re: [Zeitgeist] Zeitgeist API Ramblings

[Siegfried Gevatter]

2009/8/2 Seif Lotfy :
> FindEventsOnly will return 1 dict with the eventinfo

What's the use case for that?

-- 
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

Re: [Zeitgeist] Zeitgeist API Ramblings

[Seif Lotfy]

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

Tell me what you think
Seif



2009/8/2 Siegfried Gevatter 

> 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

Re: [Zeitgeist] Zeitgeist API Ramblings

[Siegfried Gevatter]

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

Re: [Zeitgeist] Zeitgeist API Ramblings

[Seif Lotfy]

Hi guys!
I read the blogpost yesterday and I must say I think we are doing ok!

If we concentrate that the engine does nothing but log events the problem is
not as big as we think it is. Using DBus we can write extension that extend
the metadata we have about our items.

I don't see a full rewrite soon! Keep in mind its better to have a
technologie that fullfills use cases than a technology that no one knows
howto make real use of it! In our case we have our use cases and we fullfill
them unlike nepomuk and tracker IMHO!

I did think of making events not a subclass of items but in a OO view it
makes sense since we should be allowed to tag events as well as bookmark
them. So there is the only MAJOR change is see!

As for Query language and Backends i think they relate strongly! I would
recommend focusing on one backend at the moment! my opinion sqlite! and
querying we should stay with what we have! Sparql is just too dynamic for me
and a pain in the ass!

My opinion to get forward and stop being in a loop would be!

1. implement only one backend (if some1 wants an alternative backend they
can pay us or do it themselves)!
2. use mikkels ontology of events (makes sense and i think it is future
proof)
3. rework API and the DB to enhance performance!



2009/8/2 Mikkel Kamstrup Erlandsen 

> Hi Zeitgeisters!
>
> I wrote a longish blog post spilling my brains with a lot of Zeitgeist
> thoughts I've been brewing in my head lately. Maybe it is completely
> bonkers - http://www.grillbar.org/wordpress/?p=345, or how do you guys
> feel?
>
> Don't get me wrong - I don't want to throw the baby out with the bath
> water or start a complete rewrite or anything like that. I just see a
> lot of potential problems that I think we need to make conscious
> decisions about.
>
> Any comments or questions most welcome.
>
> --
> Cheers,
> Mikkel
>
> ___
> Mailing list: 
> https://launchpad.net/~zeitgeist
> Post to : zeitgeist@lists.launchpad.net
> Unsubscribe : 
> https://launchpad.net/~zeitgeist
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~zeitgeist
Post to : zeitgeist@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zeitgeist
More help   : https://help.launchpad.net/ListHelp