[KimDaBa] RFC - seperating back and frontend

[urs roesch]

Howdy everyone, 

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

The major plus points I see are:

  - Easy scripting, even if the repository is not local
  - Easy collaboration between multiple people on the same set of pictures
  - A variety of frontends e.g. Web, <insert Favorite OS>
  - No X necessary, which is a big plus on a server machine

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. 

ciao, 

--urs