Set API specs

Registered by Seif Lotfy on 2010-11-06

We should define all DBus API methods here.
The DBus objects for cheers are

- Cheers (the main daemon):
    - Get Trophy Sets
    - Get Trophies
    - Delete Trophy Sets
    - Delete Trophies

- Trophy Set:
    - Get Trophies
    - Delete Trophies
    - Get Title
    - Get ID
    - Get Stock Icon
    - Get Description
    - Get Record Type

- Trophy
    - Get Title
    - Get ID
    - Get Stock Icon
    - Get Description
    - Get Record Type
    - Get Application
    - Get Annotations

Blueprint information

Status:
Not started
Approver:
Cheers
Priority:
Essential
Drafter:
Cheers
Direction:
Needs approval
Assignee:
Manish Sinha (मनीष सिन्हा)
Definition:
New
Series goal:
Accepted for 0.1
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

Stuart: I think that this isn't quite the right way to do the D-Bus API. The idea behind D-Bus objects is rather like desktopcouch records; you're allowed to have lots of them. I suggest that each trophy and trophy set should be a D-Bus object, rather than there being one object with "gettrophy" methods on it.
---
Here is an IRC Log

<seiflotfy> I had a long thought about the issue last night
<seiflotfy> i want to simplfy it for later
<seiflotfy> i am not really convinced we shoudl have a dbus object for every
trophy
<seiflotfy> it sounds nice but its over complcating things
<aquarius> why not? Why surface one magic RPC-style object?
<aquarius> it's no more over-complex than the other way, I think
<seiflotfy> i get your point
<seiflotfy> ur right
<aquarius> and it opens up the idea of, for example, easily being able to
monitor both one trophy and one trophy set and all trophies for signals,
which is hard to do the other way :)
<aquarius> cool
<seiflotfy> more or less one can still work rPC style even if every trophy
is a dbus object
<seiflotfy> so I will work out the datamodel then so we can expose torphies
and sets as objects
<aquarius> cool.
<seiflotfy> but can we first work out the current issues
<seiflotfy> i think later its gonna be easy to change the returns to
dbus-objects
<aquarius> so a trophy's d-bus object path would be /trophies/<trophy-id>
<aquarius> REST API :-)
<seiflotfy> sure
<seiflotfy> aquarius, get trophies will then return a set of dbus objects
<seiflotfy> aquarius, does it make sense
<aquarius> I think so, yep
<aquarius> although really you wouldn't get trophies; you'd get a trophy
set, and a trophyset would have a gettrophies method
<aquarius> and there'd be a gettrophysets method on the top level object
<seiflotfy> aquarius, it could be possible that a trophy is orphane
<seiflotfy> d
<seiflotfy> so sometimes trophies odnt belong to sets
<seiflotfy> -.-
<aquarius> that seems a bit weird...
<seiflotfy> aquarius, yeah
<seiflotfy> aquarius, its legit
<seiflotfy> thus my opinion to get_trophies will give you all trophies
<seiflotfy> and get_trophy_sets will give you all sets
<seiflotfy> then u can ask a set for get_trophies
<aquarius> it may be worth having a "virtual trophy set" called
"unallocated" or something that trophies without sets go in
<aquarius> just for consistency
<seiflotfy> aquarius, dunno
<seiflotfy> so cheers.get_trophies will give you all trophies
<seiflotfy> cheers.get_trophy_set will give you sets
<seiflotfy> and set.get_trophies will give oyu trophies of the set
<seiflotfy> so maybe ur right
<seiflotfy> yeah
<seiflotfy> ur rigth
<seiflotfy> would make sense to have the unallocated set
<aquarius> that way you can refer to trophy_object.set without always having
to have "if trophy_object.set is not None" in front of it :)
<aquarius> makes hacking easier

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.