First Post! (+ Status)

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.

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

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.

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.

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

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.

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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]