[KimDaBa] Re: RFC - seperating back and frontend
bo at sonofthor.dk
Sat Apr 3 11:02:37 CEST 2004
-----BEGIN PGP SIGNED MESSAGE-----
On Saturday 03 April 2004 05:38, urs roesch wrote:
> 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).
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
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
> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the KimDaBa