On Sat, May 29, 2010 at 5:27 PM, Lionel Dricot <[email protected]> wrote: > Hello Luca, > > That's a very interesting question. It is possible (not sure) that it is > an historical decision. > > Your idea to refactorize that is a very good one. > > We also somewhat use the current callback to not oversync during > launch : we set the callback at the end so it cannot be called at the > beginning. > > But it's straightforward to do the same with signals. In fact, I think > that signals are a lot more powerful for that kind of stuffs.
And I think it also brings a clearer model of interaction between GTG objects. > >> - if a task changes its tags (and thus should be stored in a different >> backend) we have to change the sync function > > That point doesn't seem to be a problem. You have to change the uid > anyway. So why not the sync function ? > > >> It seems to be a bit faster than the current implementation (the trunk >> 39 seconds to load 1000 tasks is cut down to 25), but my test are really > > > That's an huge improvement ! That fact alone should convince us :-) Yes, that's almost 40%... kind of nice for something "a bit" faster ;-) > > > Lionel > > > > _______________________________________________ > Mailing list: https://launchpad.net/~gtg-contributors > Post to : [email protected] > Unsubscribe : https://launchpad.net/~gtg-contributors > More help : https://help.launchpad.net/ListHelp > -- Bertrand Rousseau _______________________________________________ Mailing list: https://launchpad.net/~gtg-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-contributors More help : https://help.launchpad.net/ListHelp
