[KimDaBa] Re: RFC - seperating back and frontend

[Bo Thorsen]

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

Only connection is that if you have the connection, you can make another 
frontend that would be a command line frontend.

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

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

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

And I don't see kimdaba makes sense as a web service??

> - No X necessary, which is a big plus on a server machine

Only for a web frontend. Otherwise I don't see the point.

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

Scripting has come up several times on the mailing list, and that could be 
a nice addition though.

Bo.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFAbm+dmT99lwfUS5IRApQaAJ9C868kjbUcg3YJGP5856CBL64nRQCfROzo
JDyWk6/qmHMfJAPNoXCqr9k=
=V+56
-----END PGP SIGNATURE-----