gtg-contributors team mailing list archive

[Paul Natsuo Kishimoto <mail@xxxxxxxxxxxxxxxxxxx>]

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?

Cheers,
-- 
Paul Kishimoto
MASc candidate (2010), Flight Systems & Control Group
University of Toronto Institute for Aerospace Studies (UTIAS)

http://paul.kishimoto.name — +19053029315

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