Merge lp://staging/~manishsinha/cheers/basic-working-filemonitor-and-parse-json-trophies into lp://staging/~cheers/cheers/couch

why use the domain name cheersproject.com
also i cant seem to see all files is this some kind of a fresh rewrite since the revision is set to 2

Am confused. Is this really a merge proposal into trunk? Or is it a brand new start from scratch?

(Not sure what the domain should be. Does cheers have a domain already?)

I am fixing as we speak. I am using the old dbus api with desktopcouch as a
DB. I will use the monitor solution from this branch.

On Fri, Nov 5, 2010 at 2:16 AM, Stuart Langridge <
<email address hidden>> wrote:

> Am confused. Is this really a merge proposal into trunk? Or is it a brand
> new start from scratch?
>
> (Not sure what the domain should be. Does cheers have a domain already?)
> --
>
> https://code.launchpad.net/~manishsinha/cheers/basic-working-filemonitor-and-parse-json-trophies/+merge/40149
> Your team Cheers is requested to review the proposed merge of
> lp:~manishsinha/cheers/basic-working-filemonitor-and-parse-json-trophies
> into lp:cheers.
>

We have a domain cheers-project.com already ready.

This isn't a complete fresh rewrite, but I took most of the old code from the previous version and developing slowly so that nothing breaks and secondly, so that the reviewers can have a better time reviewing than seeing thousands of lines changed in one merge request.

I am slowly incorporating the old code in this new branch so that there is no *workaronds* like we had in old codebase. This needs to be cleaner than before.

Adding to the above comment, doing this way will help every reviewer have a grasp on the whole codebase without actually having to look at it when it is done. Reviewing big codebase is tough(though cheers codebase wont grow so big) and a big code drop is difficult to gulp down.

So what should we have the dbus name and object path as? Originally it is org.gnome.cheers (which is somewhat we should not take). AFAIK Zeitgeist had org.gnome.zeitgeist due to historical reasons.

Hey guys I built on top of this branch into
https://code.launchpad.net/~cheers/cheers/dev
I separated the remote dbus api from the logic to keep things clean.
Please check the commit messages the code looks fine. All we need now is to
extends the remote api like in the old code...
Cheers
Seif

On Fri, Nov 5, 2010 at 8:49 AM, Manish Sinha <email address hidden> wrote:

> Adding to the above comment, doing this way will help every reviewer have a
> grasp on the whole codebase without actually having to look at it when it is
> done. Reviewing big codebase is tough(though cheers codebase wont grow so
> big) and a big code drop is difficult to gulp down.
>
> So what should we have the dbus name and object path as? Originally it is
> org.gnome.cheers (which is somewhat we should not take). AFAIK Zeitgeist had
> org.gnome.zeitgeist due to historical reasons.
> --
>
> https://code.launchpad.net/~manishsinha/cheers/basic-working-filemonitor-and-parse-json-trophies/+merge/40149
> 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://seilo.geekyogre.com

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.

Friends,

I am celebrating Diwali with my relatives. Will look at it tomorrow after 10UTC

happy diwali :)

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://code.launchpad.net/~manishsinha/cheers/basic-working-filemonitor-and-parse-json-trophies/+merge/40149
> 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://seilo.geekyogre.com

<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:

> happy diwali :)
>
> 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://code.launchpad.net/~manishsinha/cheers/basic-working-filemonitor-and-parse-json-trophies/+merge/40149
> > 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://seilo.geekyogre.com
>
>
> https://code.launchpad.net/~manis...