[Zeitgeist] Zeitgeist development methodology
Hi all, Please don't take this as ranting or any personal attack, but I have a few issues I think I need to bring up regarding the Zeitgeist Engine development - at least for making it possible for people in similar situations as me to participate. This email is motivated by the fact that I used almost all of the development time I had for today trying to catch up with changes and fixing the collection of regressions that had sneaked in since my last pull. - Commit messages, can we please write usable commit messages. It is very hard to keep track of the changes for people like me who can't be online all the time. Commit logs is my primary way to understand what has happened since my last pull. Write a line about each change you have made - not one line about the entire commit. - Testing, if one is doing non-trivial stuff in the engine.py and base.py modules for which we actually have unit test, please assert that these tests pass before you push your code. On my last update ZeitgeistEngine.insert_item() and get_item() where broken - which is silly because they are tested by test/zeitgeist-engine-engine-test.py. Unit tests: Here's how to run the unit tests in the test/ dir. Simply run: test/zeitgeist-engine-base-test.py and/or: test/zeitgeist-engine-engine-test.py I will not force everyone to write unit tests for everything (although I would like that - that's no secret :-)), but let's at the very least use those we have. When Zeitgeist really takes off we are going to deal with _crucial_ user data. If the Zeitgeist core is not *rock solid* and people loose data at odds, then we are in for a heck of a ride and Zeitgeist will loose users fast... -- 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] Directories installed in the system
2009/6/24 Siegfried Gevatter : > [Launchpad's lists are working again.] > > 2009/6/24 Mikkel Kamstrup Erlandsen : >> Maybe zeitgeist.api instead of .util - that way it is more clear that >> it is indeed public api. > > Wouldn't this cause confusion? If it was zeitgeist.api I'd expect it > to do the same as the D-Bus API. Well, I didn't think of this, but if you get that thought it probably means that 50% of the world would think that. I hate to be bikeshedding this - maybe zeigeistlib? That would be in line with a number of other Python libs like urllib and bzrlib. - or just make a decision, I promise I wont complain :-). It wont be a huge disaster changing the name before we really announce the API as stable. -- 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] Structure and items of an event object
2009/7/16 markus korn : > > 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 ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 397978] Re: Remove Storm ORM dependencie
** Branch linked: lp:~kamstrup/zeitgeist/zeitgeist-querymancer -- Remove Storm ORM dependencie https://bugs.launchpad.net/bugs/397978 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: New Bug description: In the current state of zeitgeist we are using python-strom ORM as our database engine, but we are doing big parts of our queries by hand anyway. So we should drop strom as soon as possible. ___ 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] Structure and items of an event object
2009/7/17 Seif Lotfy : > 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 > the event: > > eventinfo: timestamp, app, eventype, eventtags and eventbookmark (if this > specific event is important) > targetinfo: name, uri, tags, comment, mimetype, origin, source, content. > > 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 Sorry for the late response, but I don't think this makes a lot of sense. I think an event (or within Zeitgeist a "log entry") consists of five things: Event: - action: What happened (The URI of some formal action defined in an Events Ontology) - subject: What did it happen to (the target URI) - actor: The entity (app or other) from which the event was sent - timestamp: At what point in time did this happen (Unix epoch) - A persistent unique id for the event itself (a carefully constructed URI would do fine) Note that I am not sure that restricting 'actor' to applications is entirely future proof. What about web apps? If I am tracking events from Google Docs saying that the actor is Firefox is not good enough. What we need to know about items linked in event.subject: Item: - URI - Any annotations (such as tags, comments, and ratings) - Mimetype - Content type - Source type With these Event, Item (and indirectly Annotations) metaphors in place I think I would make sense to really differentiate them in the API. So instead of a Insert(event, item) I think we should have a: LogEvent(event_struct) Thus *no item struct here*. We also need apps to be able to inform us about they items, so a method like: RegisterIterm(item_struct) This method will also automagically update the item if it already exists. Calling RegisterItem will *not* implicitly generate an event. Items in their own right are timeless entities. With this mindset it also makes sense to differentiate the lookup functions, so we have something like: FindEvents(...filters...) FindItems(...filters...) -- 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] Structure and items of an event object
2009/7/20 Seif Lotfy : > > >> 2009/7/20 Mikkel Kamstrup Erlandsen SNIP > LOVE IT LOVE IT LOVE IT > however what happens if i want to log an event where the subject has not > been registered yet? My initial idea here was to accept that and create a dummy item for that uri. Haven't given it deep thought really -- 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] Structure and items of an event object
2009/7/20 Siegfried Gevatter : > I tend to agree with your comment but I'm unsure about one thing: > >>> With this mindset it also makes sense to differentiate the lookup >>> functions, so we have something like: >>> >>> FindEvents(...filters...) >>> FindItems(...filters...) > > Maybe I'm just misunderstanding that, but if you imply that FindEvents would > only return a reference to the item (eg., it wouldn't have the URI, title > nor anything else of that) I don't think that makes much practical sense. > Ie., that information is required almost always and having to do two calls > to get it is inconvenient; I'd like to keep the API as simple as possible > (but I agree that indeed it isn't ideal right now). Yeah, I think you are right. I purposely didn't suggest what FindEvents should return because, really, I am not sure. I fear that the full item data for each event might be a lot of overhead. Maybe some more clever DBus structure where we only return one copy of each item involved... Basic human interaction patterns will most likely mean that the same item will be replicated numerous times in the result if we don't do something about it. -- 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
[Zeitgeist] Zeitgeist API Ramblings
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
Re: [Zeitgeist] Zeitgeist API Ramblings
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
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
[Zeitgeist] [Bug 397978] Re: Remove Storm ORM dependency
I am working on a new engine called querymancer_engine.py in the branch lp:~kamstrup/zeitgeist/zeitgeist-querymancer-engine. Progress is good, but I have not completed the port away from Storm just yet (read:the engine is not in a working state). ** Branch linked: lp:~kamstrup/zeitgeist/zeitgeist-querymancer-engine ** Changed in: zeitgeist/0.3 Importance: Undecided => High ** Changed in: zeitgeist/0.3 Milestone: None => 0.2.1 ** Changed in: zeitgeist/0.3 Assignee: (unassigned) => Mikkel Kamstrup Erlandsen (kamstrup) ** Changed in: zeitgeist Importance: Medium => High ** Changed in: zeitgeist Milestone: 0.3 => 0.2.1 -- Remove Storm ORM dependency https://bugs.launchpad.net/bugs/397978 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: New Status in Zeitgeist Engine 0.3 series: New Bug description: In the current state of zeitgeist we are using python-strom ORM as our database engine, but we are doing big parts of our queries by hand anyway. So we should drop strom as soon as possible. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 397978] Re: Remove Storm ORM dependency
** Branch unlinked: lp:~kamstrup/zeitgeist/zeitgeist-querymancer -- Remove Storm ORM dependency https://bugs.launchpad.net/bugs/397978 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: New Status in Zeitgeist Engine 0.3 series: New Bug description: In the current state of zeitgeist we are using python-strom ORM as our database engine, but we are doing big parts of our queries by hand anyway. So we should drop strom as soon as possible. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 411399] [NEW] Comment annotations
Public bug reported: As it stands we have an item["comment"] field on our data items which is a single string. This contrasts what we actually have in the underlying datamodel where each comment is actually an annotation type. Meaning that the actual data model supports tagging comments, having events on them etc. The über simple hack would be to turn the comments into a list of strings, but that still doesn't work either - unless the strings in the list where the URIs of the comment items... Comments? (pun intended) ** Affects: zeitgeist Importance: Undecided Status: New ** Description changed: - As it stands we have an item["comment"] field on our data items. This - contrasts what we actually have in the underlying datamodel where each - comment is actually an annotation type. Meaning that the actual data - model supports tagging comments, having events on them etc. + As it stands we have an item["comment"] field on our data items which is + a single string. This contrasts what we actually have in the underlying + datamodel where each comment is actually an annotation type. Meaning + that the actual data model supports tagging comments, having events on + them etc. The über simple hack would be to turn the comments into a list of strings, but that still doesn't work either - unless the strings in the list where the URIs of the comment items... Comments? (pun intended) -- Comment annotations https://bugs.launchpad.net/bugs/411399 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: New Bug description: As it stands we have an item["comment"] field on our data items which is a single string. This contrasts what we actually have in the underlying datamodel where each comment is actually an annotation type. Meaning that the actual data model supports tagging comments, having events on them etc. The über simple hack would be to turn the comments into a list of strings, but that still doesn't work either - unless the strings in the list where the URIs of the comment items... Comments? (pun intended) ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 407369] Re: Define content and source types in one central place
** Changed in: zeitgeist Status: New => Fix Committed ** Changed in: zeitgeist/0.3 Status: New => Fix Committed -- Define content and source types in one central place https://bugs.launchpad.net/bugs/407369 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: Fix Committed Status in Zeitgeist Engine 0.3 series: Fix Committed Bug description: currently there are two places where content and source objects are defined * zeitgeist/datamodel.py (definition and URI abstraction) * _zeitgeist/engine/base.py (mapping, lookup, and caching content/source URI -> database ID) We should change this to * have the URI (etc.) definition in one central place * make it easily possible to added new content and source types * allow easy lookup in the database implementation * there should still be a datamodel module in the public API, which knows about all definitions but nothing about the database ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 404915] Re: Add API method to change annotations of an item
Note that this bug heavily interlinks with:
https://bugs.launchpad.net/zeitgeist/+bug/411399
--
Add API method to change annotations of an item
https://bugs.launchpad.net/bugs/404915
You received this bug notification because you are a member of
Zeitgeist-Engine, which is the registrant for Zeitgeist Engine.
Status in Zeitgeist Engine: New
Status in FUSE filesystem for zeitgeist: New
Bug description:
It would be nice to have a method in the DBus API to change the annotations
(tags/bookmarked) of an item. The item should be identified by its URI.
Something like this
ChangeAnnotation("file:///boo/bar/test.dat", {"tags": ["one", "two"],
"bookmarked": False})
The 2nd argument must at least contain one item.
___
Mailing list: https://launchpad.net/~zeitgeist
Post to : zeitgeist@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zeitgeist
More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 397978] Re: Remove Storm ORM dependency
I just merged lp:~kamstrup/zeitgeist/zeitgeist-querymancer-engine. And is *almost* working. Storm is stil the default backend though. To test it out set the ZEITGEIST_ENGINE=querymancer environment variable. -- Remove Storm ORM dependency https://bugs.launchpad.net/bugs/397978 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: New Status in Zeitgeist Engine 0.3 series: In Progress Bug description: In the current state of zeitgeist we are using python-strom ORM as our database engine, but we are doing big parts of our queries by hand anyway. So we should drop strom as soon as possible. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 411399] Re: Comment annotations
Right, as you described here also I take it: https://lists.launchpad.net/zeitgeist/msg00081.html -- Comment annotations https://bugs.launchpad.net/bugs/411399 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: New Bug description: As it stands we have an item["comment"] field on our data items which is a single string. This contrasts what we actually have in the underlying datamodel where each comment is actually an annotation type. Meaning that the actual data model supports tagging comments, having events on them etc. The über simple hack would be to turn the comments into a list of strings, but that still doesn't work either - unless the strings in the list where the URIs of the comment items... Comments? (pun intended) ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] Call for testing: querymancer engine
Hi all, With Siegfried's latest updates (and some trivial fixes from me) the Querymancer engine is ready for testing before we go gold in 0.2.1. We *REALLY* need your help to dust out any hidden regressions! To test it out start you Zeitgeist daemon with ZEITGEIST_ENGINE=querymancer in the environment. Fx. like: ZEITGEIST_ENGINE=querymancer ./zeitgeist-daemon -- 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
[Zeitgeist] Zeigeist vs launchpad teams
I was just trying to makte this very list open for the general public to subscribe. Turns out that this is not possible with the current Zg project structure. Launchpad (LP) has a one-to-one mapping of teams<->mailing list. So in effect all on this mailing list has commit access to lp:zeitgeist. What we need to do is set up a project topology like so: Zg Project (open) / \ Zg Engine(restr.) Zg UI (restr.) There is already a https://edge.launchpad.net/zeitgeist-project project, but no corresponding team, so no ML. Comments? -- 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
[Zeitgeist] [Bug 404914] Re: Inconsistency in FindEvents/CountEvents filter
My gut instinct says "Require arrays everywhere" in order to make the
API more uniform and clear - so that the signature of a filter can be
written a{sav} (instead of the weaker a{sv} as now).
--
Inconsistency in FindEvents/CountEvents filter
https://bugs.launchpad.net/bugs/404914
You received this bug notification because you are a member of
Zeitgeist-Engine, which is the registrant for Zeitgeist Engine.
Status in Zeitgeist Engine: New
Bug description:
Some of our filters (eg., tags, source, content, etc) take an array of
different possibilities, but uri does only take a single string; this should be
made more consistent (probably making the uri take an array too). Maybe we
could even consider accepting everywhere either a single value or an array.
___
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] Zeigeist vs launchpad teams
2009/8/12 Siegfried Gevatter : > We created http://launchpad.net/~gnome-zeitgeist-users for that. Hmmm... Ok, but it is not very discoverable then... Also the list name seems to imply this is about the UI development? -- 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
[Zeitgeist] [Bug 404914] Re: Inconsistency in FindEvents/CountEvents filter
> Well, stuff like "bookmarked" won't be an array ever. But wont that info be passed in the annotations in the new API? -- Inconsistency in FindEvents/CountEvents filter https://bugs.launchpad.net/bugs/404914 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: In Progress Bug description: Some of our filters (eg., tags, source, content, etc) take an array of different possibilities, but uri does only take a single string; this should be made more consistent (probably making the uri take an array too). Maybe we could even consider accepting everywhere either a single value or an array. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 404914] Re: Inconsistency in FindEvents/CountEvents filter
Actually I am talking about both. I stand by what you describe in comment 8 and I myself in comment 3 and you realize in comment 8 :-). But the question in comment 6 is about something else. The bookmarked True/False is also a too weak description. It is not fx. not compatible with the standard hierarchical bookmarks of the Places menu in the Gnome panel. Where ones has folders of bookmarks... -- Inconsistency in FindEvents/CountEvents filter https://bugs.launchpad.net/bugs/404914 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: In Progress Bug description: Some of our filters (eg., tags, source, content, etc) take an array of different possibilities, but uri does only take a single string; this should be made more consistent (probably making the uri take an array too). Maybe we could even consider accepting everywhere either a single value or an array. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 404914] Re: Inconsistency in FindEvents/CountEvents filter
Ok, but then I am basically saying that the only possible consumer of the "bookmark" field is the dedicated Zeitgeist UI. This design concerns me a little... -- Inconsistency in FindEvents/CountEvents filter https://bugs.launchpad.net/bugs/404914 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: In Progress Bug description: Some of our filters (eg., tags, source, content, etc) take an array of different possibilities, but uri does only take a single string; this should be made more consistent (probably making the uri take an array too). Maybe we could even consider accepting everywhere either a single value or an array. ___ 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] Testing Zeitgeist 0.2.1
2009/8/14 : > Hey, > > I'm attaching a tarball of the current zeitgeist-0.2 branch. Please test it > and see if there's anything missing before we can release 0.2.1. I'd like to > get it out tomorrow as on Monday I'm leaving for two weeks. I get a lot of log messages, that seems to indicate all is fine except: ERROR:zeitgeist.logger.datasources.evolution:Evolution database error: no such table: Sent Traceback (most recent call last): File "/usr/share/zeitgeist/_zeitgeist/loggers/datasources/evolution.py", line 90, in get_items_uncached " FROM Sent WHERE dsent>?", (self.last_timestamp,)).fetchall() OperationalError: no such table: Sent Next thing - which version of Gnome Zeitgeist should I test against this engine? And where can I download it? Last thing - we might want to switch off debug logging for the release. -- 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
[Zeitgeist] [Bug 425258] Re: origin should be a property of events, not items
Note that events should be regarded as sub types of items, meaning that an event is comprised of both the relevant row in the item table and the corresponding row in the event table. This means that events do in fact have origins. I do agree, however, that an origin is a URL, and as such should be stored in the uri table. Meaning that item.origin should converted to an INTEGER and be renamed to item.origin_id. -- origin should be a property of events, not items https://bugs.launchpad.net/bugs/425258 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: Triaged Bug description: Both http://live.gnome.org/GnomeZeitgeist/DatabaseDesign and our current implementation have "origin" as a property of items, but this makes no sense, as the origin can be different for every event and should as such be a property of it. (Further, to improve disk space usage we should save the actual value of it in the "uri" table). I'm filling this bug so that we don't remember to fix it, but please let's ignore it until we get the basic event/item separation stuff merged - most important stuff first. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 425258] Re: origin should be a property of events, not items
Would it be possible for anyone to throw up a draft of the new design? (keeping a copy of the old database design spec around...)? -- origin should be a property of events, not items https://bugs.launchpad.net/bugs/425258 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: Triaged Bug description: Both http://live.gnome.org/GnomeZeitgeist/DatabaseDesign and our current implementation have "origin" as a property of items, but this makes no sense, as the origin can be different for every event and should as such be a property of it. (Further, to improve disk space usage we should save the actual value of it in the "uri" table). I'm filling this bug so that we don't remember to fix it, but please let's ignore it until we get the basic event/item separation stuff merged - most important stuff first. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 435099] Re: zeitgeist needs a more powerful testing framework
I don't know a lot about nose, but can't you use nose to run the tests we already have and then accomplish what you want? My primary concern here is probably keeping the third party deps to a minimum - also for developers. Also I don't quite agree that it is so hard to run individual tests... just: ./foo-test.py MyTestClass.testFrobnicator Is that so bad? It is probably because I don't know what I am missing out on :-) -- zeitgeist needs a more powerful testing framework https://bugs.launchpad.net/bugs/435099 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: New Bug description: Right now zeitgeist is using pure python unittest plus a self written script to run all tests. I think there are cases where we need a more powerful testing framework, I suggest using nose [1]. Some examples: * we are using temporary databases for our tests, it would be nice if we could hook into a testfailure with a sqlite3 terminal to introspect the content and run queries manually before deleting the database * right now it is a pain to select individual testcases, nose can help us alot with this * at the moment we are just ignoring the output of logging, but especially in cases where a testcase fails this information is useful, nose has a plugin to capture this logs and append it to the report [1] http://somethingaboutorange.com/mrl/projects/nose/0.11.1/ ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 462890] Re: Add engine version identifier and expose this ID over the DBus API
This is a standardized DBus Properties interface we can use for this... We might also want to version our DBus interfaces (like fx. Tracker does since 0.7), but that is not exactly what this bug is about... -- Add engine version identifier and expose this ID over the DBus API https://bugs.launchpad.net/bugs/462890 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: New Bug description: The latest changes to the API demonstrate that we need an API version ID and we also should make this ID accessible over DBus, something like: >>> iface = DBusInterface() >>> iface.getVersion() '0.3' Sample usecases: * some (external) dataprovider might only work with some API versions * same for client ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 462890] Re: Add engine version identifier and expose this ID over the DBus API
I think it looks really good. Easy to extend with new properties, readable, as well as writable. You should propose the branch for a merge. -- Add engine version identifier and expose this ID over the DBus API https://bugs.launchpad.net/bugs/462890 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: In Progress Bug description: The latest changes to the API demonstrate that we need an API version ID and we also should make this ID accessible over DBus, something like: >>> iface = DBusInterface() >>> iface.getVersion() '0.3' Sample usecases: * some (external) dataprovider might only work with some API versions * same for client ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 483550] Re: [lp:~zeitgeist/zeitgeist/zeitgeist-resonance] make test/remote-test.py proper unittests
If you can convert test/remote-test.py to use the unittest module that is fine with me. I can not see any code in your linked branch though..? -- [lp:~zeitgeist/zeitgeist/zeitgeist-resonance] make test/remote-test.py proper unittests https://bugs.launchpad.net/bugs/483550 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: In Progress Bug description: I know mikkel had a hard time at the hackfest trying to make this dbus API tests unittests, but I think I found a solution for it. Having this test in unittests too would allow us to create one big testsuite for zeitgeist easily. I will add a branch with unittests for the remote API soonish ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 483585] [NEW] Update to use new logo everywhere
Public bug reported: During the hackfest we decided on a new logo (small blue ghost). We should update our presence on the web with this logo (ie. launchpad and elsewhere). I believe that Seif has the logo somewhere... ** Affects: zeitgeist Importance: Medium Assignee: Seif Lotfy (seif) Status: Triaged ** Changed in: zeitgeist Status: New => Triaged ** Changed in: zeitgeist Importance: Undecided => Medium ** Changed in: zeitgeist Assignee: (unassigned) => Seif Lotfy (seif) ** Changed in: zeitgeist Milestone: None => 0.3 -- Update to use new logo everywhere https://bugs.launchpad.net/bugs/483585 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: Triaged Bug description: During the hackfest we decided on a new logo (small blue ghost). We should update our presence on the web with this logo (ie. launchpad and elsewhere). I believe that Seif has the logo somewhere... ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 483556] Re: [lp:~zeitgeist/zeitgeist/zeitgeist-resonance] make the loading of extensions to the engine configurable
+1 -- [lp:~zeitgeist/zeitgeist/zeitgeist-resonance] make the loading of extensions to the engine configurable https://bugs.launchpad.net/bugs/483556 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: New Bug description: right now the relevancy-provider is loaded by default. Unfortunately this extension is kind of buggy and not well tested, so in case of errors while loading this extension the whole engine would fail to run. We need a configurable plugin-system for our extensions, and for now we should per default disable loading the relevancy provider. If this provider gets more stable we should easily be able to add this extension to the default extensions which are automatically loaded on engine initialization. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 483556] Re: [lp:~zeitgeist/zeitgeist/zeitgeist-resonance] make the loading of extensions to the engine configurable
There is quite a lot of whitespace twiddling in your branch, making it hard to review... I can not see exactly how you plan to load the extensions and how you plan to use the __public_methods__ of the extensions..? -- [lp:~zeitgeist/zeitgeist/zeitgeist-resonance] make the loading of extensions to the engine configurable https://bugs.launchpad.net/bugs/483556 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: In Progress Bug description: right now the relevancy-provider is loaded by default. Unfortunately this extension is kind of buggy and not well tested, so in case of errors while loading this extension the whole engine would fail to run. We need a configurable plugin-system for our extensions, and for now we should per default disable loading the relevancy provider. If this provider gets more stable we should easily be able to add this extension to the default extensions which are automatically loaded on engine initialization. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 483550] Re: [lp:~zeitgeist/zeitgeist/zeitgeist-resonance] make test/remote-test.py proper unittests
Ok. Looks sane to me, but I haven't tested it. If the three(?) tests still run and pass fine its fine to merge I think -- [lp:~zeitgeist/zeitgeist/zeitgeist-resonance] make test/remote-test.py proper unittests https://bugs.launchpad.net/bugs/483550 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: In Progress Bug description: I know mikkel had a hard time at the hackfest trying to make this dbus API tests unittests, but I think I found a solution for it. Having this test in unittests too would allow us to create one big testsuite for zeitgeist easily. I will add a branch with unittests for the remote API soonish ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 483603] Re: Use REAL for timestamps
We don't use seconds. We use milliseconds since the Unix epoch. I dislike floating point timestamps because of two things: * Python is the only language I have ever heard of that use floats for timestamps * Float-comparisons (and thus db-indexes) are less effective than integer comparisons -- Use REAL for timestamps https://bugs.launchpad.net/bugs/483603 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: New Bug description: Seconds are not fine-grained enough to differentiate events, so we should store the timestamps as floating-point numbers. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 483556] Re: [lp:~zeitgeist/zeitgeist/zeitgeist-resonance] make the loading of extensions to the engine configurable
I think that extensions should expose their own DBus APIs. The engine could expose its server-object to allow extensions to do this cleanly... Regarding the two underscores; the gobject bindings use such constructs as well (for __properties__ and __signals__). So if we have a *really* good reason to keep it like this then I think we could do it. Otherwise we should have something more clean (eg. a simple method or class property). -- [lp:~zeitgeist/zeitgeist/zeitgeist-resonance] make the loading of extensions to the engine configurable https://bugs.launchpad.net/bugs/483556 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: In Progress Bug description: right now the relevancy-provider is loaded by default. Unfortunately this extension is kind of buggy and not well tested, so in case of errors while loading this extension the whole engine would fail to run. We need a configurable plugin-system for our extensions, and for now we should per default disable loading the relevancy provider. If this provider gets more stable we should easily be able to add this extension to the default extensions which are automatically loaded on engine initialization. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 483603] Re: Use timestamps with milliseconds granularity (was: use REAL)
>> We don't use seconds. We use milliseconds since the Unix epoch. >Do we? I believe you meant to say "o rly?!" :-) Anyway, in the places where I've coded I've used int(time.time()*1000) and time() returns seconds since the Epoch... While walking the dog I had some further thoughts on why reals/floats are such a bad idea...: * We can not use == for comparison. This means that we can not use a simple CONSTRAINT in the SQL to guard against duped events. Furthermore an Event "equals" function becomes meaningless becuase we can not do == on the timestamps. We can only use a "roughly equals" by checking that the timestamps lie within a small delta. * We lock down our internal data representation because we can not use "bit fiddling" with floats. As an example from the real world I had to pack a timestamp into a 64 bit int (in the lower 40 bits) and use the remaining 24 bits to hold a unique id. This gave a *huge* performance increase in my particular situation - AND allowed me to keep backwards compat with a DB schema. Tricks like these are not possible if we hard code ourselves to a float -- Use timestamps with milliseconds granularity (was: use REAL) https://bugs.launchpad.net/bugs/483603 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: New Bug description: Seconds are not fine-grained enough to differentiate events, so we should store the timestamps as floating-point numbers. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 483603] Re: Use timestamps with milliseconds granularity (was: use REAL)
Siegfried stated on IRC yesterday that he was in favor of the milliesecond resolution using an INTEGER column (ie. what we have now). I think this means that we have rough consensus..? As for use cases with sub-second resolution think of messaging (IRC, IM). If I continuously say "spam" on IRC I can easily send you 3-4 messages/s. Basically any situation where a user can flood some app with events with repeated button clicks. Alternate things include events generated by external sources where network latency or other factors may tend to "cluster" events send to you. -- Use timestamps with milliseconds granularity (was: use REAL) https://bugs.launchpad.net/bugs/483603 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: New Bug description: Seconds are not fine-grained enough to differentiate events, so we should store the timestamps as floating-point numbers. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 483556] Re: [lp:~zeitgeist/zeitgeist/zeitgeist-resonance] make the loading of extensions to the engine configurable
I think I like the engine.extensions.some_extension_method() approach the best. This way alternate extensions can provide the same method and the caller does not need to know who implements it. -- [lp:~zeitgeist/zeitgeist/zeitgeist-resonance] make the loading of extensions to the engine configurable https://bugs.launchpad.net/bugs/483556 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: In Progress Bug description: right now the relevancy-provider is loaded by default. Unfortunately this extension is kind of buggy and not well tested, so in case of errors while loading this extension the whole engine would fail to run. We need a configurable plugin-system for our extensions, and for now we should per default disable loading the relevancy provider. If this provider gets more stable we should easily be able to add this extension to the default extensions which are automatically loaded on engine initialization. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 485433] Re: Dont' raise an exception when a duplicate event is detected
For duplicate events this I think that Markus' proposal is OK. But do we have any other error scenarios when inserting events? What is the solution in this case then? -- Dont' raise an exception when a duplicate event is detected https://bugs.launchpad.net/bugs/485433 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: New Bug description: 19:52 thekorn: raising an exception on "Duplicate event detected" is evil 19:53 thekorn: tell me how you want recent.py to work this way 19:53 RainCT, catch this exception 19:54 thekorn: doesn't help, if I'm sending 50 event and event 10 is already there then events 11-50 won't get inserted 19:55 RainCT, ok, so the only problem is when you are importing the existing history? 19:55 thekorn: no, with the current one too, because recent.py doesn't know when the last run was 19:55 RainCT, let's open a "critical" bugreport for it 19:56 this has to be discussed and needs more thoughts 19:56 (we should workaround that in some way but still the Zeitgeist API not allowing this is a problem) ___ 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] GIO And the Magical Patch: A Zeitgeist Story
2009/11/19 Jason Smith : > Zeitgeist Developers, > > There is an amazing amount of activity surrounding the happenings of > Zeitgeist. Lots of excitement going on and obviously Zeitgeist will > continue to be an important part of the linux experience in the coming > years. Zeitgeist has not been without issues, there have been two major > ones I can think of. > > - The API is too complex > - The information quality is fairly low without lots of item providers > > The API issue has been largely addressed with the 0.3 release and I hope > the API can be stabilized almost completely at this point. The > information quality issue has also received considerable attention, > however I believe more can be done. I think you are right about this, and it is basically also what we agreed on in the hackfest. About the Zeitgeist API I actually think the new API is pretty sound (at least InsertEvent, GetEvent, and FindEventIds - we have not worked a lot on the last parts of the API). Just yesterday we landed a branch of mine adding a client lib (in Python for now) on top of the DBus interface. I think that it makes it pretty much as easy as it gets (modulo the fact that there are no sync methods in the API, only async; synchronous methods are made of evil). When we have some more experience with the client API in Python I'll start on a client lib in C/GObject. It is my hope that I can line it up with the inclusion of GVariant+GDBus in GLib, but I don't intend to block on it if the inclusion drags out. > In short I believe the problem with Zeitgeist is it works largely at the > application level. Getting individual applications to provide > information to Zeitgeist, or watching applications through wnck. > Instead, I believe a lot more can be achieved at the toolkit level with > a relatively small patch (or perhaps set of patches) to GIO and > libgnome-desktop. Indeed! I am glad you bring this up. I have been wanting to go down that route myself for a while - like hooking into GtkRecentManager etc. I have not looked much into it because we have been busy finalizing the API though. > By patching these parts of the toolkit, we can be notified easily of > every file the user intentionally opens, every applications they launch, > every process they use, quickly and efficiently with very little code. I > have attached a GIO patch that adds a new extension point into GIO that > allows a loadable GIO Module to track all launches of .desktop files. > This patch is early and should be considered beta quality, however it > provides the needed interface to begin writing a GIO module that will be > extremely useful to Zeitgeist. I have also included a skeleton (and very > quickly written) GIO module that essentially does nothing using this > extension point. > > I believe there to be good reason to look into getting this patch > upstreamed, and I believe it can be done in a reasonable time frame. The > benefit to Zeitgeist really could be amazing. I had a quick look at the patch and it looks pretty solid. I have not found the time to take it for a test spin though. I think it could be a good idea to write down a list of things we want to hook into in the lower levels to find out just how much hacking we need done to get to Zeitgeist nirvana. Off the top of my head I can't come up with anything more than app launching and GtkRecentManager, but it needs some more thought[1]. Then there are application level plugins off course, we track those on https://blueprints.launchpad.net/zeitgeist/+spec/zeitgeist-external-dataproviders. -- Cheers, Mikkel [1]: I am wary of hooking directly into GIO to track all IO ops as we might get too much "noise" here, although it would be wicked to track all file operations that was done through Nautilus (and any other GIO based file manager for that matter). ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 485698] Re: create an external dataprovider for evolution
Is there a related branch? I am also wondering if we can in some way hook us into the Tracker eplugin? -- create an external dataprovider for evolution https://bugs.launchpad.net/bugs/485698 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: In Progress Bug description: I'm using this bug to track progress for an evolution eplugin sending events to zeitgeist until I have a running version which is worth its own project. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 485966] Re: Using filters (text match / exclusion / etc)
Sorry; in the second paragraph above I meant "... events CAN'T have a..." -- Using filters (text match / exclusion / etc) https://bugs.launchpad.net/bugs/485966 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: New Bug description: - How can I get all events except those with interpretation VISIT_EVENT? - In case you give me above the awful answer "looking for all interpretations except VISIT_EVENT", how can I get all events except those from application "firefox.desktop"? - How can I get all those events whose URI ends with "myfile.txt"? - And those events whose title contains "zeitgeist"? ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 485966] Re: Using filters (text match / exclusion / etc)
For this question to make sense you have to give a use case and explain why it is not good enough to filter out events manually in the Firefox example. For nitpicking: events can have a "title that contains zeitgeist". They can have a subject with text field containing 'zeitgeist'. If we want to make such queries efficient we need a full text index on the event.subject_text column, which would require the FTS extension for sqlite and I am not quite sure that this is a standard dependency..? If we are serious about scaling to millions of events then we can never under any circumstance allow queries that force us into a table scan. And I think massive scalability is more important than esoteric queries, but this is simply my opinion, and up to discussion. If zeitgeist was implemented on top of something like Xapian or Lucene instead of SQLite we could allow more complex queries. But for the near- to mid term future I don't see that happening. On the negation issue I suppose we could add some sort of negation switch (fx '!') before the fields where we use controlled identifiers (that'd be uri, iterpretations, manifestation, mimetype, etc., but not payload or subject_text). But I still need a convincing argument showing that we need this... -- Using filters (text match / exclusion / etc) https://bugs.launchpad.net/bugs/485966 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: New Bug description: - How can I get all events except those with interpretation VISIT_EVENT? - In case you give me above the awful answer "looking for all interpretations except VISIT_EVENT", how can I get all events except those from application "firefox.desktop"? - How can I get all those events whose URI ends with "myfile.txt"? - And those events whose title contains "zeitgeist"? ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 486996] Re: testInsertGetWithoutTimestamp testcase fails
I think a nice default is to use the timestamp of object creation time. That was the idea behind the test at least, and indeed it also worked like that at some point (where the test worked). Otoh - the engine will use the current time as timestamp if the incoming event doesn't have one, so it might be nicer to leave it out... That said - Having the engine assign timestamps does give a slight lag on the stamps though, so that's why I prefer having the client generated. And just so that we are sure we agree; timestamps are millis since epoch, ie. int(time.time()*1000). In the Event case it needs to be a string, so wrap a str() around that. -- testInsertGetWithoutTimestamp testcase fails https://bugs.launchpad.net/bugs/486996 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: New Bug description: Running python test/resonance-engine-test.py I get one failed testcase == FAIL: testInsertGetWithoutTimestamp (__main__.ZeitgeistEngineTest) -- Traceback (most recent call last): File "test/resonance-engine-test.py", line 87, in testInsertGetWithoutTimestamp self.assertTrue(ev.timestamp) AssertionError -- I would have fixed this if I were totally sure what the correct fix is. Right now the default timestamp of an event is an empty string, which is why this testcase fails. Is this the expected behaviour, and should we fix the test. Or should the default timestamp be a string containing the timestamp of object creation time? ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 486996] Re: testInsertGetWithoutTimestamp testcase fails
@Seif: I think we can allow empty timestamps for convenience. And as I said in comment 1 paragraph 3; we meassure time in milliseconds, hence timestamps are genrated with int(time.time()*1000). -- testInsertGetWithoutTimestamp testcase fails https://bugs.launchpad.net/bugs/486996 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: Triaged Bug description: Running python test/resonance-engine-test.py I get one failed testcase == FAIL: testInsertGetWithoutTimestamp (__main__.ZeitgeistEngineTest) -- Traceback (most recent call last): File "test/resonance-engine-test.py", line 87, in testInsertGetWithoutTimestamp self.assertTrue(ev.timestamp) AssertionError -- I would have fixed this if I were totally sure what the correct fix is. Right now the default timestamp of an event is an empty string, which is why this testcase fails. Is this the expected behaviour, and should we fix the test. Or should the default timestamp be a string containing the timestamp of object creation time? ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 486996] Re: testInsertGetWithoutTimestamp testcase fails
@Seif: I wouldn't have to care about the timestamp format when sending events if my app doesn't need high precision timing. Just create the Event instance and send it along. Recall that not all apps will be written in Python and using our client libs... -- testInsertGetWithoutTimestamp testcase fails https://bugs.launchpad.net/bugs/486996 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: Triaged Bug description: Running python test/resonance-engine-test.py I get one failed testcase == FAIL: testInsertGetWithoutTimestamp (__main__.ZeitgeistEngineTest) -- Traceback (most recent call last): File "test/resonance-engine-test.py", line 87, in testInsertGetWithoutTimestamp self.assertTrue(ev.timestamp) AssertionError -- I would have fixed this if I were totally sure what the correct fix is. Right now the default timestamp of an event is an empty string, which is why this testcase fails. Is this the expected behaviour, and should we fix the test. Or should the default timestamp be a string containing the timestamp of object creation time? ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 487321] Re: Origin
WHY NOT?
--
Origin
https://bugs.launchpad.net/bugs/487321
You received this bug notification because you are a member of
Zeitgeist-Engine, which is the registrant for Zeitgeist Engine.
Status in Zeitgeist Engine: New
Bug description:
>> + origin =
>> info.get_uri().rpartition("/")[0]
WHY?
___
Mailing list: https://launchpad.net/~zeitgeist
Post to : zeitgeist@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zeitgeist
More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 485433] Re: Dont' raise an exception when a duplicate event is detected
I'll do this tonight, and update the unit tests accordingly ** Changed in: zeitgeist Assignee: Seif Lotfy (seif) => Mikkel Kamstrup Erlandsen (kamstrup) -- Dont' raise an exception when a duplicate event is detected https://bugs.launchpad.net/bugs/485433 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: Triaged Bug description: 19:52 thekorn: raising an exception on "Duplicate event detected" is evil 19:53 thekorn: tell me how you want recent.py to work this way 19:53 RainCT, catch this exception 19:54 thekorn: doesn't help, if I'm sending 50 event and event 10 is already there then events 11-50 won't get inserted 19:55 RainCT, ok, so the only problem is when you are importing the existing history? 19:55 thekorn: no, with the current one too, because recent.py doesn't know when the last run was 19:55 RainCT, let's open a "critical" bugreport for it 19:56 this has to be discussed and needs more thoughts 19:56 (we should workaround that in some way but still the Zeitgeist API not allowing this is a problem) ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 483603] Re: Use timestamps with milliseconds granularity (was: use REAL)
Yes. Plugins *must* send the timestamps in millis since the Epoch. If apps only use second granularity then we will have three zeroes in the end of the timestamps. -- Use timestamps with milliseconds granularity (was: use REAL) https://bugs.launchpad.net/bugs/483603 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: New Bug description: Seconds are not fine-grained enough to differentiate events, so we should store the timestamps as floating-point numbers. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 425258] Re: origin should be a property of events, not items
Yeah. We had a discussion about this at the hackfest and everyone agreed that origin must be a property of the subject(s). So the meaning og origin is "where does the subject come from?". For files it is the parent folder. For websites it is the root URL (eg. http://youtube.com). We do need to figure out however if we want trailing slashes on origin or not... That's another issue however. ** Changed in: zeitgeist Status: Triaged => Invalid -- origin should be a property of events, not items https://bugs.launchpad.net/bugs/425258 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: Invalid Bug description: Both http://live.gnome.org/GnomeZeitgeist/DatabaseDesign and our current implementation have "origin" as a property of items, but this makes no sense, as the origin can be different for every event and should as such be a property of it. (Further, to improve disk space usage we should save the actual value of it in the "uri" table). I'm filling this bug so that we don't remember to fix it, but please let's ignore it until we get the basic event/item separation stuff merged - most important stuff first. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 485433] Re: Dont' raise an exception when a duplicate event is detected
Fixed in revision #1157 ** Changed in: zeitgeist Status: Triaged => Fix Released -- Dont' raise an exception when a duplicate event is detected https://bugs.launchpad.net/bugs/485433 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: Fix Released Bug description: 19:52 thekorn: raising an exception on "Duplicate event detected" is evil 19:53 thekorn: tell me how you want recent.py to work this way 19:53 RainCT, catch this exception 19:54 thekorn: doesn't help, if I'm sending 50 event and event 10 is already there then events 11-50 won't get inserted 19:55 RainCT, ok, so the only problem is when you are importing the existing history? 19:55 thekorn: no, with the current one too, because recent.py doesn't know when the last run was 19:55 RainCT, let's open a "critical" bugreport for it 19:56 this has to be discussed and needs more thoughts 19:56 (we should workaround that in some way but still the Zeitgeist API not allowing this is a problem) ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 486996] Re: testInsertGetWithoutTimestamp testcase fails
Fixed in r1158 ** Changed in: zeitgeist Status: Triaged => Fix Released -- testInsertGetWithoutTimestamp testcase fails https://bugs.launchpad.net/bugs/486996 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: Fix Released Bug description: Running python test/resonance-engine-test.py I get one failed testcase == FAIL: testInsertGetWithoutTimestamp (__main__.ZeitgeistEngineTest) -- Traceback (most recent call last): File "test/resonance-engine-test.py", line 87, in testInsertGetWithoutTimestamp self.assertTrue(ev.timestamp) AssertionError -- I would have fixed this if I were totally sure what the correct fix is. Right now the default timestamp of an event is an empty string, which is why this testcase fails. Is this the expected behaviour, and should we fix the test. Or should the default timestamp be a string containing the timestamp of object creation time? ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 425258] Re: origin should be a property of events, not items
Siegfried, I think you make a good case. However I don't see it conflicting with what we have now though. Whether origin is something on the event or the subject(s) is purely a matter of how one looks at it now that we have a 1 to 1 mapping between events and subjects in the db. The tricky part is defining how we want to assign the origins for which types of events. It would be most useful to have a written spec here. Consider your download example (which is a good one btw!), what if I downloaded the files via a download manager app? Then the event context is lost and we have to resort to guess work to establish the origin (and likely use the host URL of the subject). Let's not go into these details here. We should have a spec! For me, I don't think it makes a lot of sense to talk about the origin (or root) of an event, events are intangible things. All relations to the physical world is described in the subjects. Furthermore it is technically impossible to use the event as the entity to store the origin since an event can have several subjects each with their own origin. Consider for instance if I select files ~/foo/bar.txt ~/other/one.txt and move them to the trash in Nautilus. This is one event, but each subject will have a different origin. Then there's the topic of full text searching. I think there are two sides of the matter you touch in your comment. 1) In relation origin, and 2) in the more general sense where we want full text search on any fields that make sense. So for 1), one reason that the parent folder is useful for file events is that we can look for "hot origins". Like we can detect that a lot of activity has been in the folder ~/Projects/zeitgeist in the past two days. We could for instance introduce new ResultTypes for the FindEventIds() method, like ResultType.MostRecentOrigin and ResultType.MostPopularOrigin. Such things can not be done easily with full text searching (it can be done though, and it is called "clustering", but no desktop search engine provides that atm. (and they likely wont in the near to mid-term future)). That said I still think that a full text search could be useful, but I don't think we should intermix it with our FindEventIds() method. Full text searching is very different in nature than strict SELECTS on a DB. We can maybe open up a separate bug report to discuss full text searching the events? -- origin should be a property of events, not items https://bugs.launchpad.net/bugs/425258 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Engine. Status in Zeitgeist Engine: Invalid Bug description: Both http://live.gnome.org/GnomeZeitgeist/DatabaseDesign and our current implementation have "origin" as a property of items, but this makes no sense, as the origin can be different for every event and should as such be a property of it. (Further, to improve disk space usage we should save the actual value of it in the "uri" table). I'm filling this bug so that we don't remember to fix it, but please let's ignore it until we get the basic event/item separation stuff merged - most important stuff first. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 447417] Re: Zeitgeist should have any kind of system to protect users privacy
Markus - we already have a DeleteEvents() method taking an array of ids. Just do FindEventIds(templates) and pass them to DeleteEvents. This makes it easy to do highly advanced event deletion schemes. As for blacklisting this is really an issue in apps pushing events to Zeitgeist I think. -- Zeitgeist should have any kind of system to protect users privacy https://bugs.launchpad.net/bugs/447417 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: Confirmed Bug description: Zeitgeist should respect the following use cases: * Tim has a directory ~/Videos/pr0n, he does not want zeitgeist to track any events regarding this directory * Tina played a card game at work and found out that this event is shown in her zeitgeist client, she would like to remove this event to hide it from her boss ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 447417] Re: Zeitgeist should have any kind of system to protect users privacy
I think that Siegfried has an important point. Since we like to relay events around the system the Zeitgeist core will need a blacklisting mechanism. There are several steps in such a solution as I see it... We need a matches_template(event_templ) method on the Event class. This will be mighty handy for lots of things. Then we we should IMHO not just broadcast any old event over the bus. We should do some kind of subscription service where apps register event templates they want to listen for. And then we only notify apps that have registered matching templates. Embedded in this subscription system should be a blacklisting mechanism. -- Zeitgeist should have any kind of system to protect users privacy https://bugs.launchpad.net/bugs/447417 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: Confirmed Bug description: Zeitgeist should respect the following use cases: * Tim has a directory ~/Videos/pr0n, he does not want zeitgeist to track any events regarding this directory * Tina played a card game at work and found out that this event is shown in her zeitgeist client, she would like to remove this event to hide it from her boss ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 435099] Re: zeitgeist needs a more powerful testing framework
Yeah, we've got the json importer now. That helps a lot at least. -- zeitgeist needs a more powerful testing framework https://bugs.launchpad.net/bugs/435099 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: New Bug description: Right now zeitgeist is using pure python unittest plus a self written script to run all tests. I think there are cases where we need a more powerful testing framework, I suggest using nose [1]. Some examples: * we are using temporary databases for our tests, it would be nice if we could hook into a testfailure with a sqlite3 terminal to introspect the content and run queries manually before deleting the database * right now it is a pain to select individual testcases, nose can help us alot with this * at the moment we are just ignoring the output of logging, but especially in cases where a testcase fails this information is useful, nose has a plugin to capture this logs and append it to the report [1] http://somethingaboutorange.com/mrl/projects/nose/0.11.1/ ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 488327] Re: Problems with unicode
I am pretty sure that the reason for this bug is that we would at times
try to decode an already decoded unicode string within our magical
UnicodeCursor class. I fixed this in lp:zeitgeist r1164.
--
Problems with unicode
https://bugs.launchpad.net/bugs/488327
You received this bug notification because you are a member of
Zeitgeist-Engine, which is the registrant for Zeitgeist Framework.
Status in Zeitgeist Framework: Confirmed
Bug description:
[rainct, zeitgeist-0.3]$ rm
/home/rainct/.local/share/zeitgeist/activity.sqlite*[rainct, zeitgeist-0.3]$
./zeitgeist-daemon DEBUG:zeitgeist.engine:Creating engine 'resonance'
INFO:zeitgeist.engine:Creating database:
/home/rainct/.local/share/zeitgeist/activity.sqlite
DEBUG:root:Checking for another running instance...
DEBUG:root:No running instances found.
INFO:root:S'està iniciant el servei Zeitgeist...
DEBUG:root:S'està actualitzant la base de dades amb noves activitats: Recently
Used Documents
ERROR:root:Error logging item from "Recently Used Documents":
org.freedesktop.DBus.Python.UnicodeEncodeError
Traceback (most recent call last):
File
"/home/rainct/Desenvolupament/Python/zeitgeist-project/zeitgeist-0.3/zeitgeist/../zeitgeist-datahub",
line 126, in _insert_events
self._client.InsertEvents(events)
File "/usr/lib/pymodules/python2.5/dbus/proxies.py", line 140, in __call__
**keywords)
File "/usr/lib/pymodules/python2.5/dbus/connection.py", line 622, in
call_blocking
message, timeout)
DBusException: org.freedesktop.DBus.Python.UnicodeEncodeError: Traceback (most
recent call last):
File "/usr/lib/pymodules/python2.5/dbus/service.py", line 702, in _message_cb
retval = candidate_method(self, *args, **keywords)
File
"/home/rainct/Desenvolupament/Python/zeitgeist-project/zeitgeist-0.3/zeitgeist/../_zeitgeist/engine/remote.py",
line 134, in InsertEvents
return _engine.insert_events(events)
File
"/home/rainct/Desenvolupament/Python/zeitgeist-project/zeitgeist-0.3/zeitgeist/../_zeitgeist/engine/resonance_engine.py",
line 442, in insert_events
return map (self.insert_event, events)
File
"/home/rainct/Desenvolupament/Python/zeitgeist-project/zeitgeist-0.3/zeitgeist/../_zeitgeist/engine/resonance_engine.py",
line 474, in insert_event
stext_id = _text.lookup_or_create(subj.text).id if subj.text else None
File
"/home/rainct/Desenvolupament/Python/zeitgeist-project/zeitgeist-0.3/zeitgeist/../_zeitgeist/engine/dbutils.py",
line 95, in lookup_or_create
ent = self.lookup(value)
File
"/home/rainct/Desenvolupament/Python/zeitgeist-project/zeitgeist-0.3/zeitgeist/../_zeitgeist/engine/dbutils.py",
line 79, in lookup
row = self._cursor.execute("""SELECT id FROM %s WHERE value=?""" %
self.get_name(), (value,)).fetchone()
File
"/home/rainct/Desenvolupament/Python/zeitgeist-project/zeitgeist-0.3/zeitgeist/../_zeitgeist/engine/resonance_engine.py",
line 70, in execute
parameters = [self.fix_unicode(p) for p in parameters]
File
"/home/rainct/Desenvolupament/Python/zeitgeist-project/zeitgeist-0.3/zeitgeist/../_zeitgeist/engine/resonance_engine.py",
line 65, in fix_unicode
obj = obj.decode("UTF-8")
File "/usr/lib/python2.5/encodings/utf_8.py", line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xed' in position 1:
ordinal not in range(128)
___
Mailing list: https://launchpad.net/~zeitgeist
Post to : zeitgeist@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zeitgeist
More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 488327] Re: Problems with unicode
I am wondering how I can link to a particular revision inside a branch in
launchpad bugs? Testing:
lp:zeitgeist:1164
1164:lp:zeitgeist
--
Problems with unicode
https://bugs.launchpad.net/bugs/488327
You received this bug notification because you are a member of
Zeitgeist-Engine, which is the registrant for Zeitgeist Framework.
Status in Zeitgeist Framework: Confirmed
Bug description:
[rainct, zeitgeist-0.3]$ rm
/home/rainct/.local/share/zeitgeist/activity.sqlite*[rainct, zeitgeist-0.3]$
./zeitgeist-daemon DEBUG:zeitgeist.engine:Creating engine 'resonance'
INFO:zeitgeist.engine:Creating database:
/home/rainct/.local/share/zeitgeist/activity.sqlite
DEBUG:root:Checking for another running instance...
DEBUG:root:No running instances found.
INFO:root:S'està iniciant el servei Zeitgeist...
DEBUG:root:S'està actualitzant la base de dades amb noves activitats: Recently
Used Documents
ERROR:root:Error logging item from "Recently Used Documents":
org.freedesktop.DBus.Python.UnicodeEncodeError
Traceback (most recent call last):
File
"/home/rainct/Desenvolupament/Python/zeitgeist-project/zeitgeist-0.3/zeitgeist/../zeitgeist-datahub",
line 126, in _insert_events
self._client.InsertEvents(events)
File "/usr/lib/pymodules/python2.5/dbus/proxies.py", line 140, in __call__
**keywords)
File "/usr/lib/pymodules/python2.5/dbus/connection.py", line 622, in
call_blocking
message, timeout)
DBusException: org.freedesktop.DBus.Python.UnicodeEncodeError: Traceback (most
recent call last):
File "/usr/lib/pymodules/python2.5/dbus/service.py", line 702, in _message_cb
retval = candidate_method(self, *args, **keywords)
File
"/home/rainct/Desenvolupament/Python/zeitgeist-project/zeitgeist-0.3/zeitgeist/../_zeitgeist/engine/remote.py",
line 134, in InsertEvents
return _engine.insert_events(events)
File
"/home/rainct/Desenvolupament/Python/zeitgeist-project/zeitgeist-0.3/zeitgeist/../_zeitgeist/engine/resonance_engine.py",
line 442, in insert_events
return map (self.insert_event, events)
File
"/home/rainct/Desenvolupament/Python/zeitgeist-project/zeitgeist-0.3/zeitgeist/../_zeitgeist/engine/resonance_engine.py",
line 474, in insert_event
stext_id = _text.lookup_or_create(subj.text).id if subj.text else None
File
"/home/rainct/Desenvolupament/Python/zeitgeist-project/zeitgeist-0.3/zeitgeist/../_zeitgeist/engine/dbutils.py",
line 95, in lookup_or_create
ent = self.lookup(value)
File
"/home/rainct/Desenvolupament/Python/zeitgeist-project/zeitgeist-0.3/zeitgeist/../_zeitgeist/engine/dbutils.py",
line 79, in lookup
row = self._cursor.execute("""SELECT id FROM %s WHERE value=?""" %
self.get_name(), (value,)).fetchone()
File
"/home/rainct/Desenvolupament/Python/zeitgeist-project/zeitgeist-0.3/zeitgeist/../_zeitgeist/engine/resonance_engine.py",
line 70, in execute
parameters = [self.fix_unicode(p) for p in parameters]
File
"/home/rainct/Desenvolupament/Python/zeitgeist-project/zeitgeist-0.3/zeitgeist/../_zeitgeist/engine/resonance_engine.py",
line 65, in fix_unicode
obj = obj.decode("UTF-8")
File "/usr/lib/python2.5/encodings/utf_8.py", line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xed' in position 1:
ordinal not in range(128)
___
Mailing list: https://launchpad.net/~zeitgeist
Post to : zeitgeist@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zeitgeist
More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 488327] Re: Problems with unicode
Fixed in r1166. We had another double decode of a unicode string in
querymancer.
** Changed in: zeitgeist
Status: Confirmed => Fix Released
--
Problems with unicode
https://bugs.launchpad.net/bugs/488327
You received this bug notification because you are a member of
Zeitgeist-Engine, which is the registrant for Zeitgeist Framework.
Status in Zeitgeist Framework: Fix Released
Bug description:
[rainct, zeitgeist-0.3]$ rm
/home/rainct/.local/share/zeitgeist/activity.sqlite*[rainct, zeitgeist-0.3]$
./zeitgeist-daemon DEBUG:zeitgeist.engine:Creating engine 'resonance'
INFO:zeitgeist.engine:Creating database:
/home/rainct/.local/share/zeitgeist/activity.sqlite
DEBUG:root:Checking for another running instance...
DEBUG:root:No running instances found.
INFO:root:S'està iniciant el servei Zeitgeist...
DEBUG:root:S'està actualitzant la base de dades amb noves activitats: Recently
Used Documents
ERROR:root:Error logging item from "Recently Used Documents":
org.freedesktop.DBus.Python.UnicodeEncodeError
Traceback (most recent call last):
File
"/home/rainct/Desenvolupament/Python/zeitgeist-project/zeitgeist-0.3/zeitgeist/../zeitgeist-datahub",
line 126, in _insert_events
self._client.InsertEvents(events)
File "/usr/lib/pymodules/python2.5/dbus/proxies.py", line 140, in __call__
**keywords)
File "/usr/lib/pymodules/python2.5/dbus/connection.py", line 622, in
call_blocking
message, timeout)
DBusException: org.freedesktop.DBus.Python.UnicodeEncodeError: Traceback (most
recent call last):
File "/usr/lib/pymodules/python2.5/dbus/service.py", line 702, in _message_cb
retval = candidate_method(self, *args, **keywords)
File
"/home/rainct/Desenvolupament/Python/zeitgeist-project/zeitgeist-0.3/zeitgeist/../_zeitgeist/engine/remote.py",
line 134, in InsertEvents
return _engine.insert_events(events)
File
"/home/rainct/Desenvolupament/Python/zeitgeist-project/zeitgeist-0.3/zeitgeist/../_zeitgeist/engine/resonance_engine.py",
line 442, in insert_events
return map (self.insert_event, events)
File
"/home/rainct/Desenvolupament/Python/zeitgeist-project/zeitgeist-0.3/zeitgeist/../_zeitgeist/engine/resonance_engine.py",
line 474, in insert_event
stext_id = _text.lookup_or_create(subj.text).id if subj.text else None
File
"/home/rainct/Desenvolupament/Python/zeitgeist-project/zeitgeist-0.3/zeitgeist/../_zeitgeist/engine/dbutils.py",
line 95, in lookup_or_create
ent = self.lookup(value)
File
"/home/rainct/Desenvolupament/Python/zeitgeist-project/zeitgeist-0.3/zeitgeist/../_zeitgeist/engine/dbutils.py",
line 79, in lookup
row = self._cursor.execute("""SELECT id FROM %s WHERE value=?""" %
self.get_name(), (value,)).fetchone()
File
"/home/rainct/Desenvolupament/Python/zeitgeist-project/zeitgeist-0.3/zeitgeist/../_zeitgeist/engine/resonance_engine.py",
line 70, in execute
parameters = [self.fix_unicode(p) for p in parameters]
File
"/home/rainct/Desenvolupament/Python/zeitgeist-project/zeitgeist-0.3/zeitgeist/../_zeitgeist/engine/resonance_engine.py",
line 65, in fix_unicode
obj = obj.decode("UTF-8")
File "/usr/lib/python2.5/encodings/utf_8.py", line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xed' in position 1:
ordinal not in range(128)
___
Mailing list: https://launchpad.net/~zeitgeist
Post to : zeitgeist@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zeitgeist
More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 447417] Re: Zeitgeist should have any kind of system to protect users privacy
>> templates they want to listen for. And then we only notify apps that >> have registered matching templates. > >Is this even possible at all with D-Bus? Yes. The direct solution is to have clients register some callback interface. The more elegant approach would be to send directed signals. Then a third approach would simply be using DBus Match rules (but I think this will restrict the API a bit). I am not 110% sure that directed signals are possible, but I think I read about it somewhere... -- Zeitgeist should have any kind of system to protect users privacy https://bugs.launchpad.net/bugs/447417 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: Confirmed Bug description: Zeitgeist should respect the following use cases: * Tim has a directory ~/Videos/pr0n, he does not want zeitgeist to track any events regarding this directory * Tina played a card game at work and found out that this event is shown in her zeitgeist client, she would like to remove this event to hide it from her boss ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 488550] Re: DB BUG: event id column is redundant
This is a coindidental match. The event.id column is not a primary key (as rowid is). We can have multiple subjects/event which will give more than one row with the same event id. ** Changed in: zeitgeist Status: New => Invalid -- DB BUG: event id column is redundant https://bugs.launchpad.net/bugs/488550 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: Invalid Bug description: we currently have the id in event set but if u notice it always matches the "rowid" since we just increment. This should be fixed and it will save us one index :) "rowid" is indexed by default ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 488656] Re: firefox extension: use XPCOM instead of communicating via files
How can you talk to Zeitgeist over XPCOM? Is there some bridging mechanism? Otherwise it might be useful to use a real DBus impl. for Xulrunner http://wiki.github.com/FireRabbit/mozjs-dbus -- firefox extension: use XPCOM instead of communicating via files https://bugs.launchpad.net/bugs/488656 You received this bug notification because you are a member of Zeitgeist-Engine, which is subscribed to Zeitgeist Data Providers. Status in Zeitgeist Data Providers: New Bug description: Due to a missing pyxpcom package in ubuntu karmic the firefox extension was hacked by files in the dbus communication process. this is VERY inefficient. We should use XPCOM instead. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 488656] Re: firefox extension: use XPCOM instead of communicating via files
Ah, now I get it. You want to load a Zeitgeist XPCOM component, written in Python, into Firefox, and then from that component import DBus (or simply zeitgeist.client.ZeitgeistClient). This component is then used to implement the extension in Javscript, or am I out on a limb? -- firefox extension: use XPCOM instead of communicating via files https://bugs.launchpad.net/bugs/488656 You received this bug notification because you are a member of Zeitgeist-Engine, which is subscribed to Zeitgeist Data Providers. Status in Zeitgeist Data Providers: New Bug description: Due to a missing pyxpcom package in ubuntu karmic the firefox extension was hacked by files in the dbus communication process. this is VERY inefficient. We should use XPCOM instead. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 488790] Re: inconsistency in DB
I am unsure what to do. I, for one, have several versions of Firefox installed. To identify which one sending the event we'd need the whole path to the .desktop file. OTOH getting the correct path to the .desktop file might not always be easy. In the .recently-used.xbel apps are identified simply by their name, eg. 'gedit'. So one way to generate a canonical application name would be to take the name of the .desktop file but strip the .desktop part. Eg /usr/share/applications/anjuta.desktop has name 'anjuta'. Since we are not required to use URIs everywhere I think that a simple application name like 'anjuta' is easiest to work with. If we want to add other types of actors they can come with their own namespace. Fx. if we want to store tweets with actor set to the person sending it we could use the mailto:john@gmail.com URI scheme to identify the contact. So in some sense applications are in the "default namespace" because they don't require an URI scheme. So in short i propose simply 'app'. -- inconsistency in DB https://bugs.launchpad.net/bugs/488790 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: New Bug description: Our DB has some inconsistency when we insert applications: recently used inserts something like /path/to/app.desktop while the other loggers use application://app.desktop WHICH ONE SHOULD IT BE ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 488067] Re: add more logging statements to the engine
We now have debug statements with timing and count for insert, find, and get. ** Changed in: zeitgeist Status: New => Fix Released -- add more logging statements to the engine https://bugs.launchpad.net/bugs/488067 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: Fix Released Bug description: The old version of the engine is more verbose, has more logging statements. For example it prints out if and how many objects are inserted into the database. This information is useful when developing a dataprovider to see if everything is working. We should re-add this statements. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 488967] [NEW] Add event notification and subscription system
Public bug reported:
Zeitgeist 0.2 relayed all incoming events over the bus. This might be a
bit over the top, but apps still need a way to get notified of events
elsewhere in the system.
This bug relates a lot to bug #447417 "Zeitgeist should have any kind of
system to protect users privacy" where a dynamic black listing system is
needed. This is sort of inverse to a notification system (only "sort of"
mind you).
I want to use this bug as a tracker an reminder for us/me to finish this
feature. I have it pretty cut out in my head, so if any one else starts
on this please ping me...
** Affects: zeitgeist
Importance: High
Assignee: Mikkel Kamstrup Erlandsen (kamstrup)
Status: Confirmed
** Changed in: zeitgeist
Status: New => Confirmed
** Changed in: zeitgeist
Importance: Undecided => High
** Changed in: zeitgeist
Assignee: (unassigned) => Mikkel Kamstrup Erlandsen (kamstrup)
** Changed in: zeitgeist
Milestone: None => 0.3.1
--
Add event notification and subscription system
https://bugs.launchpad.net/bugs/488967
You received this bug notification because you are a member of
Zeitgeist-Engine, which is the registrant for Zeitgeist Framework.
Status in Zeitgeist Framework: Confirmed
Bug description:
Zeitgeist 0.2 relayed all incoming events over the bus. This might be a bit
over the top, but apps still need a way to get notified of events elsewhere in
the system.
This bug relates a lot to bug #447417 "Zeitgeist should have any kind of system
to protect users privacy" where a dynamic black listing system is needed. This
is sort of inverse to a notification system (only "sort of" mind you).
I want to use this bug as a tracker an reminder for us/me to finish this
feature. I have it pretty cut out in my head, so if any one else starts on this
please ping me...
___
Mailing list: https://launchpad.net/~zeitgeist
Post to : zeitgeist@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zeitgeist
More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 488968] [NEW] Caching of Event objects for use with GetEvents
Public bug reported: We should cache the full Event objects in an LRUCache (of size something like 500 or less). We can update the cache in InsertEvents() and GetEvents(). The primary idea behind it is to massively speed up GetEvents(). Anyway not hugely important, just an optimization. ** Affects: zeitgeist Importance: Wishlist Status: Confirmed ** Changed in: zeitgeist Importance: Undecided => Wishlist ** Changed in: zeitgeist Status: New => Confirmed -- Caching of Event objects for use with GetEvents https://bugs.launchpad.net/bugs/488968 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: Confirmed Bug description: We should cache the full Event objects in an LRUCache (of size something like 500 or less). We can update the cache in InsertEvents() and GetEvents(). The primary idea behind it is to massively speed up GetEvents(). Anyway not hugely important, just an optimization. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 487321] Re: Origin
This bug is mostly about eactly what we want to store in origin, and how
to interpret origin exactly. I am deferring it to 0.3.1 because it's
unrealistic that we get full clarity on this before the weekend.
** Changed in: zeitgeist
Milestone: 0.3.0 => 0.3.1
--
Origin
https://bugs.launchpad.net/bugs/487321
You received this bug notification because you are a member of
Zeitgeist-Engine, which is the registrant for Zeitgeist Framework.
Status in Zeitgeist Framework: New
Bug description:
>> + origin =
>> info.get_uri().rpartition("/")[0]
WHY?
___
Mailing list: https://launchpad.net/~zeitgeist
Post to : zeitgeist@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zeitgeist
More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 485966] Re: Using filters (text match / exclusion / etc)
Do we really want to block 0.3.0 because of this bug? I would say no, otherwise we will ship some very untested code if we want to ship 0.3.0 this weekend. I say defer to 0.3.1, it's only a micro API break. -- Using filters (text match / exclusion / etc) https://bugs.launchpad.net/bugs/485966 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: New Bug description: - How can I get all events except those with interpretation VISIT_EVENT? - In case you give me above the awful answer "looking for all interpretations except VISIT_EVENT", how can I get all events except those from application "firefox.desktop"? - How can I get all those events whose URI ends with "myfile.txt"? - And those events whose title contains "zeitgeist"? ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 483556] Re: [lp:~zeitgeist/zeitgeist/zeitgeist-resonance] make the loading of extensions to the engine configurable
I believe Markus' branch was merged and the focus stuff removed for now? So we can close this bug? -- [lp:~zeitgeist/zeitgeist/zeitgeist-resonance] make the loading of extensions to the engine configurable https://bugs.launchpad.net/bugs/483556 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: In Progress Bug description: right now the relevancy-provider is loaded by default. Unfortunately this extension is kind of buggy and not well tested, so in case of errors while loading this extension the whole engine would fail to run. We need a configurable plugin-system for our extensions, and for now we should per default disable loading the relevancy provider. If this provider gets more stable we should easily be able to add this extension to the default extensions which are automatically loaded on engine initialization. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] Prepare for Zeitgeist 0.3.0 this weekend
Hi there, We a prepping up for rolling our first development release in the Zeitgeist 0.3 series (which will lead up to a stable 0.4 eventually). Our plan is to roll the release this weekend. So developers, please have a look over launchpad (fx. starting at https://launchpad.net/zeitgeist/+milestone/0.3.0) and see if anything is missing before we hit the button. Bear in mind that this is the _first_development_release_ in this series so we don't have to make things perfect. Better punt things to 0.3.1 than to have last-minute-panic hacks that always stays in the code base for longer than anyone likes. Happy hacking! 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
[Zeitgeist] [Bug 488967] Re: Add event notification and subscription system
If we want to re-instate the old system it is a matter of a few lines. But that would be a step back IMHO. And writing a full template based notification system could not be done in two hours by one. It's not a huge task, but definitely more than two hours :-) Besides, I really think we should stop shoveling features into 0.3.0 and go with a slimmer, more stable release, instead of one packed with features and API we need to change afterwards. -- Add event notification and subscription system https://bugs.launchpad.net/bugs/488967 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: Confirmed Bug description: Zeitgeist 0.2 relayed all incoming events over the bus. This might be a bit over the top, but apps still need a way to get notified of events elsewhere in the system. This bug relates a lot to bug #447417 "Zeitgeist should have any kind of system to protect users privacy" where a dynamic black listing system is needed. This is sort of inverse to a notification system (only "sort of" mind you). I want to use this bug as a tracker an reminder for us/me to finish this feature. I have it pretty cut out in my head, so if any one else starts on this please ping me... ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 488967] Re: Add event notification and subscription system
Let me add a comment here on why we can't just emit a signal to everyone... In the future it is not impossible that many apps are connected to Zeitgeist. Indeed if we have a hook in Gtk+ or Glib then *all* apps are connected to us. Thus we'd send a signal to all desktop processes - waking them up - meaning bad power and CPU usage. Especially on embedded devices and netbooks this could be notable. -- Add event notification and subscription system https://bugs.launchpad.net/bugs/488967 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: Confirmed Bug description: Zeitgeist 0.2 relayed all incoming events over the bus. This might be a bit over the top, but apps still need a way to get notified of events elsewhere in the system. This bug relates a lot to bug #447417 "Zeitgeist should have any kind of system to protect users privacy" where a dynamic black listing system is needed. This is sort of inverse to a notification system (only "sort of" mind you). I want to use this bug as a tracker an reminder for us/me to finish this feature. I have it pretty cut out in my head, so if any one else starts on this please ping me... ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 488967] Re: Add event notification and subscription system
I think I read somewhere in the Tracker changelogs that they committed a fix for this, but maybe I mistook a normal comment on the matter as a real committed fix... Regarding 0.3 status I think we should ship 0.3.0 without it. There's nothing stopping us having 0.3.1 next week already of we have good features and fixes lined up. It's just to make sure that we in fact get *something* out there. We are in danger of ending in perpetual-feature- creep lan otherwise... As I also stated to Seif I'd rather delay this a bit until we've figured out a good API, than ship something we have to change shortly after. -- Add event notification and subscription system https://bugs.launchpad.net/bugs/488967 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: Confirmed Bug description: Zeitgeist 0.2 relayed all incoming events over the bus. This might be a bit over the top, but apps still need a way to get notified of events elsewhere in the system. This bug relates a lot to bug #447417 "Zeitgeist should have any kind of system to protect users privacy" where a dynamic black listing system is needed. This is sort of inverse to a notification system (only "sort of" mind you). I want to use this bug as a tracker an reminder for us/me to finish this feature. I have it pretty cut out in my head, so if any one else starts on this please ping me... ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 488967] Re: Add event notification and subscription system
I am looking into the directed signals approach, and from a look at the DBus spec this should be possible. If we can somehow create our own dbus.lowlevel.SignalMessage then we can call set_destination(unique_name) on that. See http://dbus.freedesktop.org/doc/dbus-python/api/. Alse see http://dbus.freedesktop.org/doc/dbus-specification.html#message- protocol-messages. Nothing concrete yet - just a heads up. -- Add event notification and subscription system https://bugs.launchpad.net/bugs/488967 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: Confirmed Bug description: Zeitgeist 0.2 relayed all incoming events over the bus. This might be a bit over the top, but apps still need a way to get notified of events elsewhere in the system. This bug relates a lot to bug #447417 "Zeitgeist should have any kind of system to protect users privacy" where a dynamic black listing system is needed. This is sort of inverse to a notification system (only "sort of" mind you). I want to use this bug as a tracker an reminder for us/me to finish this feature. I have it pretty cut out in my head, so if any one else starts on this please ping me... ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 488967] Re: Add event notification and subscription system
Ok. I think I know how to do this now. I just need to find the time to actually write the code :-) Look at the nested emit_signal() method here: http://dbus.freedesktop.org/doc/dbus-python/api/dbus.decorators- pysrc.html#signal -- Add event notification and subscription system https://bugs.launchpad.net/bugs/488967 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: Confirmed Bug description: Zeitgeist 0.2 relayed all incoming events over the bus. This might be a bit over the top, but apps still need a way to get notified of events elsewhere in the system. This bug relates a lot to bug #447417 "Zeitgeist should have any kind of system to protect users privacy" where a dynamic black listing system is needed. This is sort of inverse to a notification system (only "sort of" mind you). I want to use this bug as a tracker an reminder for us/me to finish this feature. I have it pretty cut out in my head, so if any one else starts on this please ping me... ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 489186] [NEW] GetHighestTimestampForActor is superfluous
Public bug reported: The method GetHighestTimestampForActor is superfluous as far as I can tell. It can be simply done fully client side by using FindEventIds like so: template = Event.new_for_values(actor="gedit") ids = FindEventIds(TimeRange.until_now(), [template], StorageState.Any, 1, ResultType.MostRecentEvents) highest_timestamp_for_gedit = GetEvents(ids)[0].timestamp If I am right about this then I think we should remove it from the DBus API an simply implement a convenience method in ZeitgeistClient. ** Affects: zeitgeist Importance: Undecided Status: New -- GetHighestTimestampForActor is superfluous https://bugs.launchpad.net/bugs/489186 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: New Bug description: The method GetHighestTimestampForActor is superfluous as far as I can tell. It can be simply done fully client side by using FindEventIds like so: template = Event.new_for_values(actor="gedit") ids = FindEventIds(TimeRange.until_now(), [template], StorageState.Any, 1, ResultType.MostRecentEvents) highest_timestamp_for_gedit = GetEvents(ids)[0].timestamp If I am right about this then I think we should remove it from the DBus API an simply implement a convenience method in ZeitgeistClient. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 489194] [NEW] Implement storage monitor (devices and connectivity)
Public bug reported: This is a reminder bug. We need to write a "storage monitor" that manage the various storage mediums we can have event subjects stored on. The storage monitor should write any changes back to the 'storage' table in the DB. What we need to track is connection and disconnections of storage volumes (probably using gio) - ie. track whether or not files on USB thumb drives are available or not etc. Also the network connection state should be updated in the storage table so that we can filter out remote files and website on request. ** Affects: zeitgeist Importance: High Status: Confirmed ** Changed in: zeitgeist Milestone: None => 0.3.1 ** Changed in: zeitgeist Status: New => Confirmed ** Changed in: zeitgeist Importance: Undecided => High -- Implement storage monitor (devices and connectivity) https://bugs.launchpad.net/bugs/489194 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: Confirmed Bug description: This is a reminder bug. We need to write a "storage monitor" that manage the various storage mediums we can have event subjects stored on. The storage monitor should write any changes back to the 'storage' table in the DB. What we need to track is connection and disconnections of storage volumes (probably using gio) - ie. track whether or not files on USB thumb drives are available or not etc. Also the network connection state should be updated in the storage table so that we can filter out remote files and website on request. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 489186] Re: GetHighestTimestampForActor is superfluous
** Changed in: zeitgeist Status: New => Triaged ** Changed in: zeitgeist Assignee: (unassigned) => Mikkel Kamstrup Erlandsen (kamstrup) ** Changed in: zeitgeist Importance: Undecided => Medium ** Changed in: zeitgeist Milestone: None => 0.3.0 -- GetHighestTimestampForActor is superfluous https://bugs.launchpad.net/bugs/489186 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: Triaged Bug description: The method GetHighestTimestampForActor is superfluous as far as I can tell. It can be simply done fully client side by using FindEventIds like so: template = Event.new_for_values(actor="gedit") ids = FindEventIds(TimeRange.until_now(), [template], StorageState.Any, 1, ResultType.MostRecentEvents) highest_timestamp_for_gedit = GetEvents(ids)[0].timestamp If I am right about this then I think we should remove it from the DBus API an simply implement a convenience method in ZeitgeistClient. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 479985] Re: [lp:~zeitgeist/zeitgeist/zeitgeist-resonance] move code to compare two event/subject objects to the actual Event/Subject class
I added code to check if a given Event matches some tempalte event. We'll need that for notifications and bklacklisting. We don't have a method to check for strict equality though afaik... -- [lp:~zeitgeist/zeitgeist/zeitgeist-resonance] move code to compare two event/subject objects to the actual Event/Subject class https://bugs.launchpad.net/bugs/479985 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: New Bug description: "test/resonance-engine-test.py" has some code to check if two Event objects are the same. This code should not stay in the testcase, but should be in the Event/Subject class, as this code is useful in other places ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 488967] Re: Add event notification and subscription system
Cool that you did this test Markus! I am a bit troubled by the results though... I fear that signals are by definition always broadcasted. We may be able to work around this by setting a match rule on each signal connection on the client side, but I am not sure... Something like adding a named param. destination=bus.get_unique_name() to the line where we call object.connect_to_signal() in client.py. However it does not appear to be possible according to http://dbus.freedesktop.org/doc/dbus- python/api/dbus.proxies.ProxyObject-class.html#connect_to_signal. The alternative is to do our own simple monitoring system... Maybe adding two methods to the Log interface: InstallMonitor(in o client_monitor_path, in E event_template) RemoveMonitor(in o client_monitor_path) And then defining a new interface org.gnome.zeitgeist.Monitor with a single method Notify(in aE new_events) The way we'd do this in the engine is to remember the unique bus name of the caller in InstallMonitor() and then ping back on that address and object path client_monitor_path, on the interface org.gnome.zeitgeist.Monitor. We'd automagically drop monitors when clients disconnect by listening for NameOwnerChanged. Somehow I am nore inclined to the Monitor-solution... At least we can be sure that it will always work disregarding if the client remembers to set up the right match rules... -- Add event notification and subscription system https://bugs.launchpad.net/bugs/488967 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: Confirmed Bug description: Zeitgeist 0.2 relayed all incoming events over the bus. This might be a bit over the top, but apps still need a way to get notified of events elsewhere in the system. This bug relates a lot to bug #447417 "Zeitgeist should have any kind of system to protect users privacy" where a dynamic black listing system is needed. This is sort of inverse to a notification system (only "sort of" mind you). I want to use this bug as a tracker an reminder for us/me to finish this feature. I have it pretty cut out in my head, so if any one else starts on this please ping me... ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 489262] Re: Interpretation conventions
I think open/close/modify makes the most sense. I prefer 'modify' over 'save' since fx. editing a contact or something like that is done in an instant-apply dialog, without any notion of "saving". Of course this whole deal is just a corner of our bigger problem - that we need an event ontology. I'll start writing one down now, but it will not be ready for this weekend. So I think we should just go with open/close/modify for 0.3.0 and take our chance that we can build up a good ontology around that without having to break the ontology when we finalize it. -- Interpretation conventions https://bugs.launchpad.net/bugs/489262 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: Triaged Bug description: I think using visit/modified is non-sense I would push for replacing it with open/close/saved THIS IS CRITICAL FOR THE DATAPROVIDERS AS WELL AS CLIENT APPS ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 490110] Re: bug in client.py
This bug is probably not in client.py, but rather inside resonance_engine.py, where we generate the SQL in find_eventids(). If you can write a test case that triggers this, then that would be great. I don't know what Siegfrieds state of the no-more-querymancer branch is - the SQL generation code is probably rewritten there... -- bug in client.py https://bugs.launchpad.net/bugs/490110 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: New Bug description: Fiddling with the client.py i found this error i will write down the code first so u might understand where the problem is -- def insert_events(self): self.event_dict.clear() event = Event() event.set_interpretation(Interpretation.VISIT_EVENT.uri) event2 = Event() event2.set_interpretation(Interpretation.MODIFY_EVENT.uri) self.zg.find_event_ids_for_templates([event], self.handle_events1, [self.time*1000, (self.time+86399)*1000], num_events=5) #HERE I GET 9 items self.zg.find_event_ids_for_templates([event2], self.handle_events2, [self.time*1000, (self.time+86399)*1000], num_events=5) #HERE I GET 13 items self.zg.find_event_ids_for_templates([event, event2], self.handle_events, [self.time*1000, (self.time+86399)*1000], num_events=5) #HERE I GET 126 def handle_events1(self, x): print len(x) def handle_events2(self, x): print len(x) def handle_events(self, x=None): print "*", len(x) here the output again: 9 13 * 126 AFAIK 9+13=22 and not 126! somthing is wrong combining 2 event templates ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] ANNOUNCE: Zeitgeist 0.3.0
Hi, On behalf of the Zeitgeist team I am proud to announce our first development release, Zeitgeist 0.3.0, leading up to what will be our stable series which will be 0.4. It is our intent to aim for a 1.0 release as soon as we feel good about the stable series, but that is still a bit in the future. Now that we've crossed the initial hurdle in the rewrite we expect the release cycle to be much shorter than this one, although we have not settled on something strict yet. As many of you know the bulk work on this release was done in the Zeitgeist hackfest in Bolzano. Since we came back we been busy little bees polishing it up and fixing bugs - trying not to flame each others too much when discussing the designs :-) Working face to face in Bolzano gave us a unique chance to really discuss things through and get to the bottom of the details. This will also affect other developers a bit since... We were bad boys and decided to change both our internal database structures as well as our public DBus API. Sorry - but after long discussions we all agreed that this was for the best. The new design is leaps and bounds better than the old one. This means that you both have to give up on your old log database, and accept that there are no GUI written for the new API just yet. This is being worked on as you read this though! Something that might come as a shock to some other developers is that we decided not to store annotations and bookmarks within Zeitgeist. This should be done in Tracker or some other semantic metadata storage[1]. Zeitgeist answers only when and how data was accessed, but stores no information about the current state of the metadata. We will be working very closely with Tracker from now on since 0.7 is a blessed dependency for GNOME 2.30. Congrats to the Tracker Devs. You can download the release from: https://launchpad.net/zeitgeist/+download The NEWS entry reads: First development release leading up to the stable 0.4 series. This release features: - Complete rework of engine and DBus API. Read: apps written against 0.2.* will most certainly need an update (see fx. http://mail.gnome.org/archives/desktop-devel-list/2009-November/msg00019.html) - Public Python client API defined in zeitgeist.datamodel and zeitgeist.client modules - Documented public API with Sphinx (we'll have an URL for you shortly) - Changed Ontology from XESAM to Nepomuk. - Removed the Storm backend (obsoleted in 0.2.1). - Removed the Querymancer backend. - Support for event payloads (binary attachments to events) - An extension API for the core engine, allowing extensions direct access to the DB There are already a handful extensions things in the works here, you will hear more about this later There are a few DISCLAIMERS that needs to be attached to this: - The event notification/signals are not yet ready in the new DBus API. We expect to have that ready for 0.3.1. - We plan to support querying only for available items (eg. filtering out deleted files, not listing files on detached USB storage, etc.). However this feature is not fully supported yet, even though it is exposed in the API. - While we are pretty satisfied with the database layout, there may still be changes in the ontologies or concrete data extraction methods. This might require that users delete their log databases in order to rebuild them with the new definitions. Of course this will no longer happen when we go stable - Much related to the point above our event ontologies are not yet set in stone, and minor changes are expected - We have only one logger enabled for now. Namely the one monitoring your recent files. In coming releases this logger may well be deprecated in favour of application specific plugins. - And finally. Please note that this is a *development release*. We can not guarantee stability of services nor APIs, although we strive hard to keep things stable. Cheers, Mikkel [1]: There have been talk about defining (and implementing) a very simple DBus API for storing semantic annotations (bookmarks, tags, comments, ratings, etc). In our internal speak such a service is called a Repository. Tracker or Soprano would expose this API in most cases, but on platforms where they are not available the simple Repository implementation would be most handy. This being said, it is currently not a high priority to implement a Repository, there are alternatives ready in Tracker and Soprano. ___ 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] ANNOUNCE: Zeitgeist 0.3.0
2009/12/1 Neil Jagdish Patel : > Hey, > > Congratulations :) > > I've got it built and running, however have nothing to test it with -- > have the tests been ported over to the new API? They seem to fail with > broken D-Bus signatures. Also, are there any front-ends working with it > yet or is that effort beginning now (gnome-zeitgeist seems to have > stalled at the moment)? Which tests are you referring to? The unit tests pass fine... I put the API docs up on http://www.grillbar.org/zeitgeist/doc/0.3.0/, but we probably need a more authoritative location. The docs are still incomplete and could definitely use some inlined examples. Most notably though; the ontology definitions are missing from the docs (I have not figured out to automatically inject them into Sphinx). One has to look in zeitgeist.datamodel.py for the predefined Interpretations and Manifestations. -- 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
[Zeitgeist] [Bug 488967] Re: Add event notification and subscription system
I have te beginings of an implementation along the lines I describe above. It is still not ready for review, but I have it on lp:~kamstrup/zeitgeist/notification. ** Branch linked: lp:~kamstrup/zeitgeist/notification -- Add event notification and subscription system https://bugs.launchpad.net/bugs/488967 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: Confirmed Bug description: Zeitgeist 0.2 relayed all incoming events over the bus. This might be a bit over the top, but apps still need a way to get notified of events elsewhere in the system. This bug relates a lot to bug #447417 "Zeitgeist should have any kind of system to protect users privacy" where a dynamic black listing system is needed. This is sort of inverse to a notification system (only "sort of" mind you). I want to use this bug as a tracker an reminder for us/me to finish this feature. I have it pretty cut out in my head, so if any one else starts on this please ping me... ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] Planning for Zeitgeist 0.3.1
Hi, With 0.3.0 behind us it is time to plan what to aim for in 0.3.1. I wholeheartedly think that we should aim for a short release cycle, maybe with releases every month or so. Right now 0.3.1 is scheduled to 24/12 on LP and I think a deadline around that date is good. Considering that Christmas most probably will influence our sparetime negatively I think we shold be conservative in what we want to go in 0.3.1 - rather release a few days early than some time after new years eve. I created a 0.3.2 milestone on LP so we can defer bugs and blueprints to our next-next milestone. So - comments and critics of this plan, please! -- 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
[Zeitgeist] [Bug 491646] Re: Delete unused stuff from DB
Until we see evidence that our DB indeed clutters up in lots of unused URIs and whatnot (after some DeleteEvents), then I don't think the added complexity is worth it. A more pressing issue is to delete unused URIs after a DeleteEvents because of privacy reasons - it's fine that we delete all events about http://example.com/explicit_content, but we still have the URI in the 'uri' table. However, we have to make sure that the URI is not reffed by any other existing event before pruning it. But this seems to be another bug, although heavily related to this issue. -- Delete unused stuff from DB https://bugs.launchpad.net/bugs/491646 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: New Bug description: RainCT, I used REFERENCES table(column) ON DELETE CASCADE everywhere ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 489262] Re: Interpretation conventions
** Changed in: zeitgeist Milestone: 0.3.0 => 0.3.1 -- Interpretation conventions https://bugs.launchpad.net/bugs/489262 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: Triaged Bug description: I think using visit/modified is non-sense I would push for replacing it with open/close/saved THIS IS CRITICAL FOR THE DATAPROVIDERS AS WELL AS CLIENT APPS ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 490110] Re: bug in client.py
Seif has not been able to reproduce afaik, so marking as invalid ** Changed in: zeitgeist Status: New => Invalid -- bug in client.py https://bugs.launchpad.net/bugs/490110 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: Invalid Bug description: Fiddling with the client.py i found this error i will write down the code first so u might understand where the problem is -- def insert_events(self): self.event_dict.clear() event = Event() event.set_interpretation(Interpretation.VISIT_EVENT.uri) event2 = Event() event2.set_interpretation(Interpretation.MODIFY_EVENT.uri) self.zg.find_event_ids_for_templates([event], self.handle_events1, [self.time*1000, (self.time+86399)*1000], num_events=5) #HERE I GET 9 items self.zg.find_event_ids_for_templates([event2], self.handle_events2, [self.time*1000, (self.time+86399)*1000], num_events=5) #HERE I GET 13 items self.zg.find_event_ids_for_templates([event, event2], self.handle_events, [self.time*1000, (self.time+86399)*1000], num_events=5) #HERE I GET 126 def handle_events1(self, x): print len(x) def handle_events2(self, x): print len(x) def handle_events(self, x=None): print "*", len(x) here the output again: 9 13 * 126 AFAIK 9+13=22 and not 126! somthing is wrong combining 2 event templates ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 406054] Re: Export extensions and dataproviders into a new package
** Changed in: zeitgeist Milestone: 0.3.0 => 0.3.1 -- Export extensions and dataproviders into a new package https://bugs.launchpad.net/bugs/406054 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: Incomplete Bug description: We should take everything thath as nothing to do with the the engine itself or anything that communicates via dbus with the engine outside the package and create a new one or even a project called zeitgeist-dataproviders and zeitgeist-extensions. What do you think? ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 397715] Re: I18N of zeitgeist
I agree with Siegfried. It will be very convenient for apps if the
display_name of Categories (Interp. and Manif.) af translated
** Changed in: zeitgeist
Milestone: 0.3.0 => 0.3.1
--
I18N of zeitgeist
https://bugs.launchpad.net/bugs/397715
You received this bug notification because you are a member of
Zeitgeist-Engine, which is the registrant for Zeitgeist Framework.
Status in Zeitgeist Framework: Confirmed
Bug description:
zeitgeist is using gettext for I18N in various places, but its usage is
inconsistent. A quick grep with `grep -R -E "[^\_]\_{1}\(" .` shows we are
using gettext for:
- some logging messages
- the name and description of the FF DataProvider
- display name of Content and Source objects in our datamodel (real gettext
support is not implemented yet)
Thinking about this three items a bit I think none of them make sense at all.
Logging is for debugging purposes, in the future we will ask our user to add a
log file to a bugreport. If the logging messages are translated to a random
language we will hardly understand the content. Translating the display name of
Content and Source object also makes no sense, instead of this it should be
done by the client. This way one database can be accessed with different
language settings. And if we agree on the last two arguments, it also makes
less sense for the last item.
But just in case I'm missing the point here, and we decide to have I18N support
in zeitgeist we should decide which parts we would exactly like to translate,
and dig trough the code to add language support to related elements
consistently.
Markus
___
Mailing list: https://launchpad.net/~zeitgeist
Post to : zeitgeist@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zeitgeist
More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 489186] Re: GetHighestTimestampForActor is superfluous
I removed this method some time before we released 0.3.0. Marking as Fix Released ** Changed in: zeitgeist Status: Triaged => Fix Released -- GetHighestTimestampForActor is superfluous https://bugs.launchpad.net/bugs/489186 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: Fix Released Bug description: The method GetHighestTimestampForActor is superfluous as far as I can tell. It can be simply done fully client side by using FindEventIds like so: template = Event.new_for_values(actor="gedit") ids = FindEventIds(TimeRange.until_now(), [template], StorageState.Any, 1, ResultType.MostRecentEvents) highest_timestamp_for_gedit = GetEvents(ids)[0].timestamp If I am right about this then I think we should remove it from the DBus API an simply implement a convenience method in ZeitgeistClient. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 483550] Re: [lp:~zeitgeist/zeitgeist/zeitgeist-resonance] make test/remote-test.py proper unittests
** Changed in: zeitgeist Status: Fix Committed => Fix Released -- [lp:~zeitgeist/zeitgeist/zeitgeist-resonance] make test/remote-test.py proper unittests https://bugs.launchpad.net/bugs/483550 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: Fix Released Bug description: I know mikkel had a hard time at the hackfest trying to make this dbus API tests unittests, but I think I found a solution for it. Having this test in unittests too would allow us to create one big testsuite for zeitgeist easily. I will add a branch with unittests for the remote API soonish ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 489194] Re: Implement storage monitor (devices and connectivity)
Ok, let me jot some thoughts donw on this so we have it * All monitoring should be done async, without polling. Ie. using signals and callback, not sleep(5); check_drives(); * I think we can use gio.VolumeMonitor() to listen for connect/disconnect of volumes. Then we use gio.Volume.get_uuid() as the key in the 'storage' table. * I have not checked NetworkManager or ConnMan, but I am pretty sure that both provide some DBus API to get async notifications when the connection goes away and comes up. We should use the key 'inet' to store the connectivity state in the 'storage' table. * All online subjects requiring a connection to be available, should have their storage attribute set to 'inet' -- Implement storage monitor (devices and connectivity) https://bugs.launchpad.net/bugs/489194 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: Confirmed Bug description: This is a reminder bug. We need to write a "storage monitor" that manage the various storage mediums we can have event subjects stored on. The storage monitor should write any changes back to the 'storage' table in the DB. What we need to track is connection and disconnections of storage volumes (probably using gio) - ie. track whether or not files on USB thumb drives are available or not etc. Also the network connection state should be updated in the storage table so that we can filter out remote files and website on request. ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 488790] Re: What value should event.actor have?
** Summary changed: - What value should "actor" have? + What value should event.actor have? ** Changed in: zeitgeist Assignee: (unassigned) => Mikkel Kamstrup Erlandsen (kamstrup) ** Changed in: zeitgeist Importance: Undecided => High ** Changed in: zeitgeist Status: New => Triaged -- What value should event.actor have? https://bugs.launchpad.net/bugs/488790 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: Triaged Bug description: Our DB has some inconsistency when we insert applications: recently used inserts something like /path/to/app.desktop while the other loggers use application://app.desktop WHICH ONE SHOULD IT BE ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 489262] Re: Interpretation conventions
This is very related to the whole events ontology thing, and must also be meticulously documented in our API docs. Since I am knee deep in both, I'll assign this bug to myself. ** Changed in: zeitgeist Assignee: (unassigned) => Mikkel Kamstrup Erlandsen (kamstrup) -- Interpretation conventions https://bugs.launchpad.net/bugs/489262 You received this bug notification because you are a member of Zeitgeist-Engine, which is the registrant for Zeitgeist Framework. Status in Zeitgeist Framework: Triaged Bug description: I think using visit/modified is non-sense I would push for replacing it with open/close/saved THIS IS CRITICAL FOR THE DATAPROVIDERS AS WELL AS CLIENT APPS ___ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp
[Zeitgeist] [Bug 487321] Re: What value should subject.origin have?
** Summary changed:
- Origin
+ What value should subject.origin have?
** Changed in: zeitgeist
Assignee: (unassigned) => Mikkel Kamstrup Erlandsen (kamstrup)
** Changed in: zeitgeist
Importance: Undecided => High
** Changed in: zeitgeist
Status: New => Triaged
--
What value should subject.origin have?
https://bugs.launchpad.net/bugs/487321
You received this bug notification because you are a member of
Zeitgeist-Engine, which is the registrant for Zeitgeist Framework.
Status in Zeitgeist Framework: Triaged
Bug description:
>> + origin =
>> info.get_uri().rpartition("/")[0]
WHY?
___
Mailing list: https://launchpad.net/~zeitgeist
Post to : zeitgeist@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zeitgeist
More help : https://help.launchpad.net/ListHelp
