gtg-contributors team mailing list archive

[Paul Natsuo Kishimoto <mail@xxxxxxxxxxxxxxxxxxx>]

On Tue, 2010-12-07 at 13:12 -0800, Bryce Harrington wrote:
> On Tue, Nov 30, 2010 at 09:12:02AM -0800, invernizzi.l@xxxxxxxxx wrote:
> > Hello,
> > On Mon, Nov 29, 2010 at 6:55 AM, Lionel Dricot <ploum@xxxxxxxxx> wrote:
> > > I'm with Bertrand ATM, discussing how to get GTG out of my shit.
> > >
> > > With Bertrand, we came to the following proposition for you guys:
> > >
> > > Given that:
> > > A) it looks that liblarch is, itself, a good thing
> > > B) our bug are coming from liblarch-gtk (because gtk is stateful when it
> > > comes to its TreeModel)
> > >
> > > We propose to abandon the idea of a direct TreeModel/Liblarch
> > > interaction. Instead, liblarch-gtk will maintain a gtk.TreeStore that
> > > will be in sync with Liblarch.ViewTree.
> > 
> > That's exactly what I was writing a few days ago, just to see if it
> > was feasible.
> > It seems pretty straightforward, and we don't need to deal with signals at all.
> > Plus, adding the ability to remember  subtask ordering seems also easy.
> > I've sketched a multithreaded example in [0], in case you want to take a look.
> > 
> > By the way, since we don't need to write all the methods required by
> > the gtk interface anymore,
> > we can also simplify liblarch a lot (which might be good for maintainance).
> 
> <snip>
> 
> >From this experience, I've also concluded that the problems seem to be
> in the gtk layer, and that decoupling them would probably alleviate a
> lot of problems.
> 
> One other idle thought I've had...  What if the UI was built atop dbus
> api calls, with the backend running as a service?

This was supposed to become the outcome of my GSoC. The main obstacles
were the ongoing, rapid development of liblarch and, as Lionel and
Bertrand have again discovered, the close interaction between liblarch
and liblarch-gtk.

The basic design trade-off is how data and model behaviour is handled by
(A) duplication on the client (UI) side versus (B) DBus calls to the
backend. Specifically:
      * Are all task properties (dates, status, text, title) copied over
        to identical client-side Task objects, or does the UI query the
        server-side Task over DBus for this information, when needed?
      * Can the UI alter a client-side liblarch tree and expect those
        changes to be pushed back to the server-side tree? - OR - does
        it manipulate the server-side tree via DBus, THEN refresh its
        local copy?
      * Does the server filter trees and provide a list of the displayed
        nodes to the client? Or does the client do its own filtering,
        unknown to the server? How does this work when 2+ clients are
        connected to the same backend?
      * How does the UI access and alter the unique configuration
        requirements of each backend in the datastore? 100% DBus? Does
        it rewrite a config file then trigger a backend reload?

I suspect there are speed issues with passing too much information over
DBus. Also, as more is done on the server-side, the DBus interface grows
larger and more complex. On the other hand, the UI code simplifies
considerably.

If anyone is interested, my (incomplete) attempts to address these
questions in code are still available on LP.

-- 
Paul Natsuo Kishimoto

SM candidate, Technology & Policy Program (2012)
Research assistant,  http://globalchange.mit.edu
http://paul.kishimoto.name          +16173026105

Attachment: signature.asc
Description: This is a digitally signed message part