Re: F-Spot Meeting and Next goal

[Ruben Vermeersch <ruben savanne be>]

On Mon, 2006-10-09 at 21:57 +1000, Bengt Thuree wrote:
> Hi Ruben
> 
> Just wondering if you would be able to attend the next F-Spot meeting?
> (Monday October 9th, 20:30 UTC
>       * New York: 16:30
>       * Paris: 22:30
>       * Melbourne: 6:30 (the next day, 3d) )
> 
> The reason I am asking, is that your Job Scheduler [1] patch has been
> proposed as the next goal. I also saw that you updated it so it applies
> cleanly to CVS :) Great work, and it really works nice for me when I
> tested it :)
> 
> What do you think of having this patch as the next goal?
> If you are not able to make the meeting, perhaps you can send us your
> feelings, and if it is possible for you to update the patch based on
> possible feedback/comments?
> 
> Larry also did mention that this patch would be his next big patch to
> check and review.

Hi Bengt,

I'm highly flattered that my patch is being considered. Unfortunately, I
will not be able to attend the IRC meeting tonight due to social
obligations which I cannot outrun. I'll put my comments about the patch
in this email, feel free to paste it into the meeting.

The patch is functional and apart from a one-in-a-thousand-times hang
when closing f-spot, it should be bug-free (should investigate that
hang, but it doesn't really occur often). The patch is quite invasive
too as it's a combination of multiple patches:

* First, there's the GMCS patch, which switches f-spot to GMCS, AFAIK
this has been applied to HEAD, so we can ignore that.

* Secondly, there's the threaded database patch. It adds threading
support to the database layer, which is highly needed to do these kind
of things (as sqlite doesn't do threading). It also adds threaded
transaction support. It is based on the banshee database layer,
currently mostly a plain copy-paste. As Abock noted (and i agree with
him), that's quite a hack. The right way to do it is to put the
QueuedSqliteDatabase from banshee in some kind of shared library. Then
extend that class to TransactionalQueuedSqliteDatabase to add
transaction support to the existing QueuedSqliteDatabase. The current
code works fine (and rock solid), but if we want to look at the future,
sharing the database layer with banshee is the way to go. You might want
to ask Aaron about his opinion on this.

* And finally, there's the jobscheduler itself. It uses a kind of
persistent queueing model. There's an opportunity of sharing code with
banshee too here, as banshee has itself adopted a scheduler recently.
Banshee's scheduler doesn't allow for persistent jobs, but it does do
decent scheduling using a priority queue, my implementation is an 0(n)
list hack (as C# lacks a Priority Queue). Also missing is a way to show
visual feedback to the user. ActiveUserEvent (again, from Banshee) could
be used for this. Aaron once told me to contact gabaug for that, but I
haven't had the time.

So, it's working, but it needs work if we want a clean & neat design to
grow for the future. Personally, I think Aaron has a point in sharing
code (and I think Larry wanted this too), it adds consistency across the
apps (both in terms of code consistency as in terms of user interface).

That's about it, from the top of my head. I really hate not being able
to attend, but I will certainly follow the evolution in this (though
university takes up a lot of my spare time nowadays).

Cheers,
   Ruben


CC-ing to f-spot-list for the archives.


--
Ruben Vermeersch (rubenv)
http://www.savanne.be