gtg-contributors team mailing list archive

[Karlo Jež <karlo.jez@xxxxxxxxx>]

On Wed, Jun 16, 2010 at 5:41 PM, Paul Natsuo Kishimoto <
mail@xxxxxxxxxxxxxxxxxxx> wrote:

> Hi all,
>
>  I am figuring out how the DBus interface of the GTG server is going to
> look. If you haven't already, please have a look at
>        http://paul.kishimoto.name/300 and
>        http://live.gnome.org/gtg/SoC/2010/PaulKishimoto/DBusNotes
>
> What I've discovered is:
>      * Considering only the main data objects (Tasks, Tags), the
>        picture is straightforward.
>      * The overall picture is more complicated :P
>
> I would value your input on one simple and one complex point:
>
> SIMPLE
>
> GTG/tools/dates.py contains several classes:
>
>        object
>         +-- GTG.tools.dates.Date
>              +-- GTG.tools.dates.FuzzyDate
>                   +-- GTG.tools.dates.FuzzyDateFixed
>              +-- GTG.tools.dates.NoDate
>              +-- GTG.tools.dates.RealDate
>
>  These are used for several attributes of any Task. We can't pass
> fully-formed Python objects over DBus, because the code on the other end
> may not be in Python. I intend to spec ISO 8601 strings for dates, with
> the added, special values 'now', 'soon', 'later' and 'none', which will
> have defined meanings.
>
>  For the GTG client side, I will provide a class or function Date that
> accepts a string for the constructor and essentially returns a FuzzyDate
> object. Client-side code will look like:
>
>  # get a DBus proxy for a task
>  t = Task('cd0f3cbd-3c6f-453e-9740-ec971f85c1af')
>  # retrieve the task start date as a string, construct an object
>  sd = Date(t.start_date)
>  # set the task start date using a string
>  t.start_date = str(sd)
>  # or like this, the proxy object calls str() for you
>  t.start_date = sd
>
>  How does this seem?
>
> COMPLEX
>
>  Tags and Tasks are subclasses of TreeNodes. The current GTK UI relies
> heavily on classes like TagTreeView, TaskTreeView (and friends), which
> in turn reference -Model classes, which in turn rely on things like
> TagStore and FilteredTree, which are subclasses of Trees and contain
> TreeNodes.
>
>  This represents a problem because references to object instances go
> back and forth between code under GTG/core/ and GTG/gtk/. That can't
> happen once separation occurs.
>
> Broadly, my question is,
>
>        Should all data *structures* involving Tasks and Tags live on
>        the server side
>
>        OR
>
>        Should the client use classes analogous to the server-side ones
>        to manipulate data structures?
>
> In the former case, interrogating a tree in any way (does a node have
> children, finding the root node, finding the path of a node) will
> involve a DBus call.
>
> In the latter case, those things can happen on the client side; but a
> mirror of the task tree needs to be maintained. I envision this
> happening by passing a chunk of text containing task IDs:
>
>        '4d9cf2a6-1030-4ff4-8d9b-f0608f694840'
>                '4c89e6ee-3b7a-41e7-8757-6c8d9aa33968'
>                        'c8ff728e-9754-4f48-9771-ce2277aa1011'
>                        '6ae3b560-aff1-43e8-97f2-482a73f4e3dc'
>                                '6b30ac23-4be3-43aa-8095-096f3d35c866'
>                'b00a1be1-89d3-45ff-9041-4ed337bf204b'
>                        '06085441-637c-4680-ae57-29117f414487'
>        '3cbbb007-dc62-4ecc-9327-cbe5e747b22e'
>                'de53b231-97d4-4e9a-b923-985a42f4e5c3'
>                        '292c87ae-868a-4f05-b895-c6ddfbbde08a'
>
> ...which encodes hierarchy. The client will manipulate a tree of strings
> (lightweight) and obtain & query the a DBus proxy for each Task only
> when necessary. One downside here is that there will need to be some
> mechanism for keeping the mirror up to date.
>
>  Does anyone have a preference here?
>

I'm not sure if this method offers benefits over the current model in which
child and parent ids are part of task information.
You have to parse the task tree either way.
If there is manipulation of the tree, that means that tree structure has
changed on the client side - which I think should immediately be reflected
on the server.

What could be added are some return/add parent/child calls to the dbus api
which could simplify tree operations.

>
> Cheers,
> --
> Paul Kishimoto
> MASc candidate (2010), Flight Systems & Control Group
> University of Toronto Institute for Aerospace Studies (UTIAS)
>
> http://paul.kishimoto.name — +19053029315
>
> _______________________________________________
> Mailing list: https://launchpad.net/~gtg-contributors<https://launchpad.net/%7Egtg-contributors>
> Post to     : gtg-contributors@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~gtg-contributors<https://launchpad.net/%7Egtg-contributors>
> More help   : https://help.launchpad.net/ListHelp
>
>