gtg-gsoc team mailing list archive

[Paul Natsuo Kishimoto <mail@xxxxxxxxxxxxxxxxxxx>]

On Tue, 2010-06-22 at 16:31 +0200, Lionel Dricot wrote:
> I would like to propose the following schedule:
> - Everything that can break heavily should be merged before GUADEC
> - 1st of August will be feature freeze. We only allow bugfixes from that
> point.
> - 1st of September is string freeze and code freeze. We release 0.2.9
> - 10th of September: we release 0.3 (so we can be included in Ubuntu
> 10.10)

  Sounds good to me!

> Paul: I've a problem. Currently, we use display directly our filtered tree
> in the GTK treeview. That's the purpose of filtered tree and that's allow
> us to have bare metal performances.
> 
> I don't see how this can be sent through DBus without a huge performance
> gap. What's your opinion  on this ?
> 
> FYI, I was tired of the bugs in all our tree implementations when stressed
> with Bryce's taskset. More: bugs had to be solved twice: once for tagtree,
> once for tasktree. I'm thus putting everything related to tree (Tree,
> TreeNode, FilteredTree, FiltersBank) in one big generic library that I
> called "liblarch" (because the larch is a tree you can recognize from quite
> a long way away. The laaaarch.).  
> 
> This library will be used by tags and tasks and will provide an easy,
> unified interface to view a tree, as weel a GTK frontend.
> 
> I've started working on it without breaking GTG at all by, guess what,
> writing the tests first then implementing (jml will be proud of me)! It
> works, I've already spotted one bug in the filteredtree !  So, currently,
> it's in tools/larch/ and is only used by unit tests. The interface that you
> can use is in __init__.py, everything else will be private and parts of the
> internal implementation.

  We noticed the same problem! I sent mail to the gtg-contributors list
about this: https://lists.launchpad.net/gtg-contributors/msg00218.html —
Karlo had some comments.

Briefly:

      * I had not noticed liblarch, but will look at it today.
      * I am astounded there's no standard way to do trees in Python. If
        you Google about tree data types, all you get is a bunch of
        people receiving snooty replies to "use lists", as if that's a
        complete & self-evident solution...
      * Technically what we have is a "directed acyclic graph"; the
        common definition of "tree" doesn't allow multiple parents. I
        recall someone mentioning multiple parents were now possible in
        GTG.
      * Abstracting all tree-ish functionality out of Tag/Task is
        certainly the most sensible thing to do.
      * Whatever happens, there *must* be some tree-ish data structure
        on the server side of GTG, so that the server can make sure the
        data set is clean.
      * Any client (GTK, CLI, web, etc.) *may* want to understand the
        hierarchy of tasks. Or, it may not care about that. If it does,
        it would make sense, to the user, for the hierarchy to behave
        the same across all clients.
      * Did you guys see
        https://code.launchpad.net/~khaeru/+junk/dbus-magic , from my
        last weekly report? If not, please look at the client.py file
        there.

My opinion:

  I have to admit I am not very familiar with how the *TreeView classes
work. I know there is a lot of code there, and evidently a lot of work
has gone into making sure it works properly and *quickly*.

  In C programming, most data structures are implemented with pointers.
Each node/list item/tree leaf/whatever also has a pointer to the data
associated with that node. Traversing the data structure is fast because
pointers are moved/changed, but the data stays in place.

  In my e-mail above, one of the ideas is to basically use the tag UUID
as a "pointer". In the dbus-magic code, the client calls
Task('782e6c00-1286-41ef-91f5-953d03279d25') to get a proxy to the
server-side Task with that UUID.

  So, without enough knowledge to be 100% confident, what I am angling
towards is:

     1. The GTG server will have a fast, complete, filterable tree
        implementation, in which the nodes are the actual Task / Tag
        objects.
     2. GTG clients will have a sort of "proxy tree", where the nodes
        are strings (Task or Tag IDs). ONLY WHEN THEY NEED TO, they will
        use Tag('..') and Task('...') to "dereference" these "pointers"
        and get at the actual object data.
     3. Clients will use DBus methods against the server to alter the
        tree.
     4. The server will emit DBus signals when the tree is changed,
        which can be caught by clients and used to trigger UI updates.
        Using signals also means, for example, the GTK UI can refresh
        when changes are made using the CLI.

  The success of this really depends on how the *TreeViews traverse &
deal with the trees. For simple hierarchical operations ("Get the IDs of
all children/siblings/ancestors of ___"), it would eliminate the need to
do any DBus calls. If there are many, complex interactions, there would
certainly be a slowdown.

P.S. I don't know how familiar you all are with SQL, but you might think
of filtering by analogy to SQL stored procedures
(http://en.wikipedia.org/wiki/Stored_procedure).

Anyway, I'm glad we're talking about this now, it's an important topic!
Thoughts? Should I CC this mail back to ~gtg-contributors?

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