Re: GSoC 2011: Synchronizing F-Spot data



I would consider it assuming I am even qualified to do so. I don't know what is required.


Tim



On Tue, Apr 5, 2011 at 3:47 PM, Simon Lindgren <simon n lindgren gmail com> wrote:
Ok,

I have submitted my proposal to the GSoC system.

http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/simonlindgren/1

Tim, would you consider mentoring this project?

mån 2011-04-04 klockan 20:07 +0200 skrev Simon Lindgren:
> mån 2011-04-04 klockan 12:04 +0200 skrev Sven Utcke:
> > Hello Simon,
> >
> > > > > > > Now I need to find a mentor.
> > > > >
> > > > > If you are looking for one on this list, you might want to
> > > > > clarify what the requirements for / expectations of a mentor
> > > > > are...
> >
> > [...]
> >
> > > Ugh, minutes after sending I found this:
> > > http://people.gnome.org/~federico/docs/summer-of-code-mentoring-howto/index.html
> >
> > Ok, sounds as if you really need one of the F-Spot developers, so I am
> > definitely out.
>
> That's too bad... :(
> The list is not exactly overflowing with candidates...
>
> > > > Yes, and I looked at it briefly. It handles concurrent access too, but
> > > > that is only true for files that are actually synced by Unison. If
> > > > storing metadata as .xmp sidecars and then some other file format for
> > > > the tags, the import rolls, the versioning and so on, then Unison could
> > > > be a workable solution for all of the synchronization.
> >
> > You could simply sync the database, couldn't you?  You would need to
> > write some conflict resolution code, but as sqlite3 can be translated
> > to text and back to db format, this ought to be fairly
> > straightforward...
> >
>
> Ah, yes, that would be possible too... my suggestion is probably
> over-complicated :)
>
> > > > I mainly see one issue with Unison: It requires the server and the
> > > > client to be running the same version of the program. I think a
> > > > natural step for a thing like this is to expand it to also include
> > > > a web service so people don't need to host their own servers. And
> > > > with Unison this might raise problems with versioning.
> >
> > Yeah, that is a _mayor_ pain with unison.  Others work around this by
> > making there own unison executable part of the client...
> >
> > Sven
>
> Yes, that could be doable... but there is still the issue of the server
> using the "wrong" version. It would work fine for the web service part
> though, and the case of using your own server could be done by using the
> system-installed Unison and leaving the task of keeping the unison
> versions in-sync to the user (most likely capable of that, if he/she has
> a server :P).
>


--
Simon Lindgren




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