Refuses to log events without subjects

[Mikkel Kamstrup Erlandsen]

Zeitgeist says:

Traceback (most recent call last):
  File "/usr/share/zeitgeist/_zeitgeist/engine/main.py", line 497, in _insert_event_without_error
    return self._insert_event(event, sender)
  File "/usr/share/zeitgeist/_zeitgeist/engine/main.py", line 508, in _insert_event
    raise ValueError("Illegal event format: No subject")
ValueError: Illegal event format: No subject

If I send it an event without a subject. The reason why I am doing that is because I am trying to log whenever an app is launched. Like for instance when I launch the Gnome calculator. This way I can have "most popular apps" listings and what not :-)

So my request: Can we lax the requirement for events to have a subject?

[Seif Lotfy (seif)]

+1 for me dude

On Wed, Aug 18, 2010 at 11:12 PM, Mikkel Kamstrup Erlandsen <
<email address hidden>> wrote:

> Public bug reported:
>
> Zeitgeist says:
>
> Traceback (most recent call last):
> File "/usr/share/zeitgeist/_zeitgeist/engine/main.py", line 497, in
> _insert_event_without_error
> return self._insert_event(event, sender)
> File "/usr/share/zeitgeist/_zeitgeist/engine/main.py", line 508, in
> _insert_event
> raise ValueError("Illegal event format: No subject")
> ValueError: Illegal event format: No subject
>
> If I send it an event without a subject. The reason why I am doing that
> is because I am trying to log whenever an app is launched. Like for
> instance when I launch the Gnome calculator. This way I can have "most
> popular apps" listings and what not :-)
>
> So my request: Can we lax the requirement for events to have a subject?
>
> ** Affects: zeitgeist
> Importance: Undecided
> Status: New
>
> --
> Refuses to log events without subjects
> https://bugs.launchpad.net/bugs/620109
> You received this bug notification because you are subscribed to The
> Zeitgeist Project.
>
> Status in Zeitgeist Framework: New
>
> Bug description:
> Zeitgeist says:
>
> Traceback (most recent call last):
> File "/usr/share/zeitgeist/_zeitgeist/engine/main.py", line 497, in
> _insert_event_without_error
> return self._insert_event(event, sender)
> File "/usr/share/zeitgeist/_zeitgeist/engine/main.py", line 508, in
> _insert_event
> raise ValueError("Illegal event format: No subject")
> ValueError: Illegal event format: No subject
>
> If I send it an event without a subject. The reason why I am doing that is
> because I am trying to log whenever an app is launched. Like for instance
> when I launch the Gnome calculator. This way I can have "most popular apps"
> listings and what not :-)
>
> So my request: Can we lax the requirement for events to have a subject?
>
>
>

--
This is me doing some advertisement for my blog http://seilo.geekyogre.com

[Markus Korn (thekorn)]

Hmm, I think the main question here is: How do events for "launching applications look like?"

From how I understand your description I think you want something like:
event = Event.new_from_values(
   timestamp=1,
   interpretation=ACCESS_EVENT,
   manifestation=USER_ACTIVITY,
   actor="/path/to/application.desktop"
)

But in my opinion this is wrong, launching events should look like

event = Event.new_from_values(
   timestamp=1,
   interpretation=ACCESS_EVENT,
   manifestation=USER_ACTIVITY,
   subject_uri = "/path/to/executable",
   subject_interpretation=EXECUTABLE,
   subject_manifestation=SOFTWARE_ITEM
)

So the bug should be more about allowing empty actors (which is working I think)

And a query for "most popular apps would be the union of
"events where actor is APP" and "events with ACCESS_EVENT and subj_uri points to `which APP` (or the exec field in the .desktop file)"

[Mikkel Kamstrup Erlandsen (kamstrup)]

Markus, I had a similar idea to begin with, but I don't think that works for the general case of launching app X with a list of N uris (N=0, 1, 2, 3, ...). To me it would be ugly if launching an app without uri args is different than launching an app with N uris.

Alternatively we log first the "launch executable" event and then an access event with N subjects for that actor. I don't think that's very nice modelling though, and it's not nice to query for clients either...

[Markus Korn (thekorn)]

As I mentioned already on IRC, although I don't like the idea of having events without a subject (because it's conceptual: "something is happening, but we don't know what") I think this is the easiest solution for the usecase of a GIO dataprovider which sits in the middle of the application which launches another app and the new app itself.
And I also think that this solution is kind of abusing the actor field, I mean it's not the app which is about to be launched which is doing something when the event is triggered.

But the most important concern was raised by mhr3 on IRC: the fact that events can have no subjects will most likely break some clients, because until now the client can assume that each event has at least one subject.

I would *really* like to take some time to discuss a more suitable solution, but I understand that we might need to make some compromises if we want to have such AppInfo.launch() dataprovider soonish

Markus

[Seif Lotfy (seif)]

I would like to have a soltuion where the actor is the environment that
launches tha app and the subject is the app itself...
However his could mess up AJ terribly unless I query for all subjects except
for those of type software_item

Querying this and sroting it by mostusedactor will give us most launched but
not most used :/

On Thu, Aug 19, 2010 at 6:42 PM, Markus Korn <email address hidden> wrote:

> As I mentioned already on IRC, although I don't like the idea of having
> events without a subject (because it's conceptual: "something is happening,
> but we don't know what") I think this is the easiest solution for the
> usecase of a GIO dataprovider which sits in the middle of the application
> which launches another app and the new app itself.
> And I also think that this solution is kind of abusing the actor field, I
> mean it's not the app which is about to be launched which is doing something
> when the event is triggered.
>
> But the most important concern was raised by mhr3 on IRC: the fact that
> events can have no subjects will most likely break some clients, because
> until now the client can assume that each event has at least one
> subject.
>
> I would *really* like to take some time to discuss a more suitable
> solution, but I understand that we might need to make some compromises
> if we want to have such AppInfo.launch() dataprovider soonish
>
> Markus
>
> --
> Refuses to log events without subjects
> https://bugs.launchpad.net/bugs/620109
> You received this bug notification because you are subscribed to The
> Zeitgeist Project.
>
> Status in Zeitgeist Framework: New
>
> Bug description:
> Zeitgeist says:
>
> Traceback (most recent call last):
> File "/usr/share/zeitgeist/_zeitgeist/engine/main.py", line 497, in
> _insert_event_without_error
> return self._insert_event(event, sender)
> File "/usr/share/zeitgeist/_zeitgeist/engine/main.py", line 508, in
> _insert_event
> raise ValueError("Illegal event format: No subject")
> ValueError: Illegal event format: No subject
>
> If I send it an event without a subject. The reason why I am doing that is
> because I am trying to log whenever an app is launched. Like for instance
> when I launch the Gnome calculator. This way I can have "most popular apps"
> listings and what not :-)
>
> So my request: Can we lax the requirement for events to have a subject?
>
>
>

--
This is me doing some advertisement for my blog http://seilo.geekyogre.com

[Mikkel Kamstrup Erlandsen (kamstrup)]

On 19 August 2010 18:55, Seif Lotfy <email address hidden> wrote:
> I would like to have a soltuion where the actor is the environment that
> launches tha app and the subject is the app itself...
> However his could mess up AJ terribly unless I query for all subjects except
> for those of type software_item

How is that? Do you just query for everything? In that case your code
must be ready to accept *everything*. Otherwise we impose an
artificial limitation of what data you can log in ZG. GAJ can not
expect ZG data sources to behave nicely since we deliberately made the
InsertEvent API very forgiving.

[Mikkel Kamstrup Erlandsen (kamstrup)]

On 19 August 2010 18:42, Markus Korn <email address hidden> wrote:
> As I mentioned already on IRC, although I don't like the idea of having events without a subject (because it's conceptual: "something is happening, but we don't know what") I think this is the easiest solution for the usecase of a GIO dataprovider which sits in the middle of the application which launches another app and the new app itself.
> And I also think that this solution is kind of abusing the actor field, I mean it's not the app which is about to be launched which is doing something when the event is triggered.
>
> But the most important concern was raised by mhr3 on IRC: the fact that
> events can have no subjects will most likely break some clients, because
> until now the client can assume that each event has at least one
> subject.
>
> I would *really* like to take some time to discuss a more suitable
> solution, but I understand that we might need to make some compromises
> if we want to have such AppInfo.launch() dataprovider soonish

Ok. I tend to agree. Another factor is also that a specific "app
launched" event also fits better in a semantic world where we share
data with Tracker.

From a technical POV it is however not possible to write a generic DP
by using a GIO extension point hook for AppInfo.launch(). As I also
mentioned on IRC the extension point code has no way of knowing which
app it's running inside. Michal mentioned that we could use getpid()
-> bamfdaemon to look up the .desktop file for the app we run inside,
but I am not very happy about that prospect.

As the GApplication/GtkApplication APIs are still in the making we may
be able to influence them so that you pass the desktop id of your app
in the constructor. I'll talk to the G/Gtk guys about this...

[Seif Lotfy (seif)]

@Kamstrup: I think your reasoning today why you chose to go with thekorn's proposition is spot on.

<seif> installed launched
<seif> and the empty subjects issue
<seif> what do u think
<seif> ?
<kamstrup> seif, for libzgs module I settled on setting the launched app as the subject
<seif> kamstrup, :/
<seif> kamstrup, i think the empty subjects would be a better idea
<seif> kamstrup, what event interpretation did u use
<seif> ?
<kamstrup> seif, i was nervous for dupe entries in the db
<seif> how dupe?
<kamstrup> if I open house.jpg in eog by clicking it in nautilus
<kamstrup> the module would fire off the same event as the datahub
<seif> uhm yeah
<kamstrup> while semantically there is in fact difference between launching an app and an app opening a document
<seif> but but but
<seif> kamstrup, thus i want to introduce some new ontology interpretations for event
<seif> "launch"
<seif> "installeD"
<seif> mainly
<seif> uninstalled too :P
<kamstrup> seif, I think that goes against the basic premise we have been building the onto on
<seif> kamstrup, how?
<seif> kamstrup, explain more
<seif> :)
<kamstrup> seif, installing an app == zg:CREATE_EVENT with subj manif nfo:SOFTWARE_ITEM
<seif> kamstrup, ok this is right
<kamstrup> and the event manif would be SYSTEM_NOTIFICATION or something
<seif> and the actor being the installation software
<kamstrup> seif, indeed
<seif> apt or software center
<seif> ok
<seif> but launchd
<seif> did u make it a visit event
<seif> ?
<kamstrup> seif, it's a zg:ACCESS_EVENT on a subject with interp nfo:SOFTWARE and manif nfo:SOFTWARE_ITEM
<seif> actor?
<thekorn> wohhhoo, 7me starts to like ontologies
<kamstrup> actor is the app lauching the app
<seif> in this case unity?
<seif> thekorn, ur cute :P
<kamstrup> and if we can't figure out what that is, we just don't set the actor
<seif> kamstrup, good idea
<seif> ok
<kamstrup> seif, right now the actor in unity is application://mutter
<seif> no need to extend ontology then