Re: First Post! (+ Status)

["John Stowers" <john stowers gmail com>]

Apologies on sending this twice, I dont think the first reply went to the list..

On 6/24/07, john carr unrouted co uk <john carr unrouted co uk> wrote:

I can't see anything in the archives so I guess this is first post :D

Things have been hectic recently (i'm moving jobs so i've been doing a lot
of training for my successors) and i haven't got as much done as hoped.
Here be a quick run down of things that I have ongoing or need discussing.

Foresight
=========
There is an interest in having Conduit as a default install option in the
next major release of Conduit. In order to help make that a reality we
have 3 outstanding tasks:

1. Make iconfiy like Banshee (where "X"ing out of an app sends it to tray
instead of closing it)

OK I will look into this as it involves some yucky issues with closing dbus and gui threads, handling which was instantiated first, and other things

2. Option to start Conduit as part of session. There are a few ways to do
this, i'm not sure about the best option.
3. Working translation infrastructure

Help with this would be appreciated. Anyone out there familiar with how to do this in a python app?

Evolution
=========
Added support for the Evolution Calendar, which is as ready as Contacts
apart from needing an icon. Evolution Tasks is also fully supported but I
think I really need to create a new data-type before its release ready -
tasks are actually VTODO or something.

I've managed to break a bit of shared code out in to EvoBase. The biggest
thing is the put().

If we s/self.addressBookURI/self.uri then all 4 evolution dp's could have
the same get/set configuration and get uid - and thus i can shove those
functions in EvoBase.

Committed

F-Spot
======
Spoken to sde in #fspot. There was talk of creating an f-spot backend so
that apps like conduit and beagle can talk to f-spot without starting the
f-spot GUI. In the mean time i've said i'll take a look at the code and
see if I can wrap some dbus foo around their PhotoStore which should be
just what we need.

Any movement on this?

Tomboy
=====
Tomboy dbus is not capable of fully syncing everything we need to do a
perfect replica :-(

Yeah I agree, Tomboy people have rolled their own sync funtionality now, so what are peoples thoughts on our direction.

Personally I would like to finish up the Tomboy <--> Evo stuff, and then Google Notebook support when I get back from my holiday and have persistant net connectivity.

Network Sync
============
As you saw, it works! Although at the moment probably only for simple
cases. Syncing files is a no-no as my sub-conscious actively refuses to
allow something as horrid as pickling the contents of files in to memory
so they can be sent over the network.

Yeah, this is part of the discussion on whether we make the compare process two step. Something like a

class ResourceIdentifier:
 def __init__(self, uid, mtime, hash):
    pass
def compare(self, other):
    pass

could possibly be used in get() and returned from put(). By moving to this it could provide an upgrade path for those backends which want to use hashes instead of mtimes, and also we could pickle the whole lot into the DB which will be, well, easy.

Making compare twostep would then be something like

if can compare rids
 RidA.compare(RidB)
else
 A = Dataprovider.get(RidA)
 B = Dataprovider.get(RidB)
 A.compare(B)

That way we would only need to send Rids over the wire. Would this be better or is it too dirty a solution?

I think i'm holding off on the GUI for sharing dp's until we can merge the
MVC branch.

I agree

TestSyncPermutations
===================
The main goal here is to test each dataprovider against as many other
dataproviders as possible. Writing a test case for each combination would
be a complete pain so I've reduced it down to a set of common and generic
actions with a set of functions providing ready configured dp's that can
be plugged into the generic harness in an automatic way.

So far it tests 16 combinations of dataprovider in both two-way and
one-way cases. In the two-way case is starts with data in the source (but
not the sink). Then it runs the tests again with data in the sink (but not
the source).

I modified this test so that you need to set STRESS_TEST=YES for it to
run. This is mainly because i'm actively screwing around with it and don't
want it to interfere with the other tests.

Each sync operation is performed twice. This is a measure for detecting
UID/mapping problems. If the 2nd sync detected a change even though I
hadn't made a change then something is broken, so it causes a FAIL.

Right now i'm hacking on Evo support for it - it's struggling to create
ECalComponents for some reason. Then i'm going to get as many of the dp's
working with the net code as possible.

Any progress on this?

John

_______________________________________________
Conduit-list mailing list
Conduit-list gnome org
http://mail.gnome.org/mailman/listinfo/conduit-list