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