<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
On Fri, Nov 5, 2010 at 5:01 PM, Seif Lotfy <email address hidden> wrote:
<seiflotfy> I had a long thought about the issue last night <trophy- id> get_trophy_ set will give you sets
<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/
<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.
<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
On Fri, Nov 5, 2010 at 5:01 PM, Seif Lotfy <email address hidden> wrote:
> happy diwali :) /code.launchpad .net/~manishsin ha/cheers/ basic-working- filemonitor- and-parse- json-trophies/ +merge/ 40149 seilo.geekyogre .com /code.launchpad .net/~manishsin ha/cheers/ basic-working- filemonitor- and-parse- json-trophies/ +merge/ 40149
>
> On Fri, Nov 5, 2010 at 4:57 PM, Manish Sinha <email address hidden> wrote:
>
> > Friends,
> >
> > I am celebrating Diwali with my relatives. Will look at it tomorrow after
> > 10UTC
> > --
> >
> >
> https:/
> > Your team Cheers is requested to review the proposed merge of
> > lp:~manishsinha/cheers/basic-working-filemonitor-and-parse-json-trophies
> > into lp:cheers.
> >
>
>
>
> --
> This is me doing some advertisement for my blog http://
>
>
> https:/
> Your team Cheers is requested to review the proposed merge of
> lp:~manishsinha/cheers/basic-working-filemonitor-and-parse-json-trophies
> into lp:cheers.
>
-- seilo.geekyogre .com
This is me doing some advertisement for my blog http://