How we describe events/items/annotations
We should rethink how we understand events. I thinḱ of and event as a one instance happening as in "opened" "saved" "closed" not "opening" "saving" and "closing"
I proposed a new definition of events so instead of sending 1 big dict with shit load of info! We should separate those into two dicts. One descibes the info of the event (as in the source of the event as well as the type of the event) and another describes the target (in our case documents websites and notes :P)
Mikkel proposed this ontology:
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
- annotations (such as tags, comments on this specific event)
- 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)
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
Annotations can be seen here
http://
- We will use the events in a list and items in a dict
- Make place for multiple subjects per event
Blueprint information
- Status:
- Complete
- Approver:
- Markus Korn
- Priority:
- Essential
- Drafter:
- Mikkel Kamstrup Erlandsen
- Direction:
- Needs approval
- Assignee:
- Siegfried Gevatter
- Definition:
- Superseded
- Series goal:
- Accepted for 0.3
- Implementation:
-
Implemented
- Milestone target:
-
0.3.0
- Started by
- Seif Lotfy
- Completed by
- Siegfried Gevatter
Related branches
Sprints
Whiteboard
*** Discussion:
Natan: I don't feel strongly about this one way or another. If it's only an issue of convenience then its fine by me.
Mikkel: This is not about convenience. This is about Zeitgeist needing a well thought out and flexible event model and API if we want to make it as part of the Gnome 3 core. As Zg is in the moment of writing I would veto any kind of core inclusion -- Mikkel
Seif: We need to have a solution for the annotation ASAP
Work Items
Dependency tree
* Blueprints in grey have been implemented.
