[KimDaBa] Re: RFC - seperating back and frontend

[urs roesch]

Bo Thorsen [bo at sonofthor.dk] wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Saturday 03 April 2004 05:38, urs roesch wrote:
> > Howdy everyone,
> 
> Hi
> 
> > I had this idea the other day and thought I throw it at the list and
> > especially Jesper to find out if it should be sent straight to
> > /dev/null or if it is something that should be looked at.
> >
> > I think Kimdaba could take another leap forward by seperating the
> > backend (scanning images, keeping the xml file up to date, etc..) from
> > the frontend (displaying picture on the screen, add picture
> > categorizations, etc...). Additionally defining a general API that
> > other apps or scripting languages can hook into without having to do
> > all the gut work. I imaging the server part (backend) could also be
> > used over the network allowing a bunch of people in an office to have
> > one picture repository instead of everyone having a seperate copy (I do
> > know that it might be possible to do the same thing over a network file
> > system like NFS).
> 
> I'll just make a few quick comments on the parts below.
> 
> > The major plus points I see are:
> >
> >   - Easy scripting, even if the repository is not local
> 
> This could be done by DCOP as well. Or by embedding a python interpreter. 
> Or both. It's not something that would come from separating the front and 
> back ends. It's actually a completely different problem.

DCOP is part of KDE AFAIK and kimdaba has to run for it to be usable as a scripting interface, which is not exactly what I thought of. Having python embedded is not a bad idea, but not everyone knows python. E.g. having libkimdaba scripting would become much easier, given someone writes the language bindings.
 
> Only connection is that if you have the connection, you can make another 
> frontend that would be a command line frontend.

Not really, if I want a commandline interface, I could implement it via DCOP. I already mentioned that DCOP has too many dependencies for my taste. 
 
> >   - Easy collaboration between multiple people on the same set of
> > pictures
 
> I fail to see how this would make a difference? You need to share the 
> picture directory anyway, and you can do that already now. I did this on 
> my wifes desktop by going to the pictures dir (in my home dir) with 
> konqueror and dragging the dir to her desktop and choosing to set up a 
> link. And gave her write access of course.

You forgot to mention if it was done via a network file system or on the same machine. Depending on kimdaba's file locking, when both of you are working on the same set of pictures simultaniously, what happens? If you ever worked over NFS, to name but one FS, you know that file locking can be a pain in the neck. A designated server process could easily handle multiple connections and save you the pain.
 
> But I see nothing here that would benefit from a separation. If you're 
> thinking about a client server idea, you're smoking something seriously 
> interesting that I need a link to :-)

Well since you asked already I let you in on my secret, but please don't tell anybody. <URL:http://synthetik.ch/~urs/fun/nudy/>

However I'm pleased to announce not to be the only one that's bonkers. Canto's Cumulus <URL:http://www.canto.com/>[1] seems to have a whole product line based on a client server architecture. And GIFT (GNU Image Finding Tool) <URL:http://www.gnu.org/software/gift/> seems to be client server, tho their search algorithm is based on image content. 

> > - A variety of frontends e.g. Web, <insert Favorite OS> 
 
> Sorry to burst your bubble, but that's usually a pipe dream. I have yet to 
> see a single separation case that actually did result in other frontends 
> using the backend.

Librsync is a project that tries to be become a replacement for rsync's big memroy footprint and already has rdiff-backup, pysync and duplicity as frontends. 
 
> And I don't see kimdaba makes sense as a web service??

Why not, I can think of a few cases. E.g. Instead of making seperate pages for each event or person you took pictures of simply send them a single URL. The page let's them see the photos you permission them to see and they can download the ones they like. The big plus is that compared to static output the user can do searching and limit the output the same way you could do it in kimdaba. With all the keywords and options that kimdaba provides, you can easily make something better then all those web image repositories out there. Another option is for your friends to upload pictures they have that are of interest to you. The script puts it into the right directory and starts adding them to the xml file. This is much easier then burning CDs and distributing them. Your right insofar that the scenarios mentioned above do not need a service running, a library with language bindings would do.    
 
> > - No X necessary, which is a big plus on a server machine
 
> Only for a web frontend. Otherwise I don't see the point.

Guess I'm old-school, but a designated server doesn't need to run X. At least none of the 1000+ hosts at work do and only a handfull of them are webservers. Having the backend seperate without X would allow you to easily start it as a service on boot time.
 
> > One good example of such an architecture is giFT
> > <URL:http://gift.sourceforge.net/> which has a very easy API to connect
> > to backend with clients on multiple platforms. If you are a CLI junkie
> > like me you can use the superb giFTcurs app
> > <URL:http://www.nongnu.org/giftcurs/> or Apollon
> > <URL:http://apollon.sourceforge.net/> if you prefer KDE to name but a
> > couple.

> > Disclaimer: As I am not a C++ programmer and have not looked at the
> > code I don't know if it is actually feasible, hence some insight from a
> > 'doability' perspective would be appreciated.
 
> It's not a question of wether it could be done, because that is of course 
> possible. It's a question of wether it would make sense.

Hence I politely asked for comments ;)
 
> Scripting has come up several times on the mailing list, and that could be 
> a nice addition though.

Agreed on that one.

ciao,

--urs

[1] Somehow deep-linking does not work on their site, so I can't point you to a good page where they list a particular product. 
 
> Bo.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (GNU/Linux)
> 
> iD8DBQFAbm+dmT99lwfUS5IRApQaAJ9C868kjbUcg3YJGP5856CBL64nRQCfROzo
> JDyWk6/qmHMfJAPNoXCqr9k=
> =V+56
> -----END PGP SIGNATURE-----