OOooppss, I was a bit late and it is described in a better English than mine.
+10 EF. > Message du 28/03/08 19:09 > De : "Julien BLACHE" > > Based on the current saned, it can already be achieved: > - link saned statically to libsane-dll (what we know as libsane > today) > - ship libsane-net as libsane > - add a local connection to saned, typically a UNIX socket and listen > to that and that only unless general networking is explicitly > enabled. Ditto libsane only connects to the UNIX socket by > default. (the UNIX socket wins hands down against localhost/TCP) > > There, done. Keep all the underlying architecture as far as saned is > concerned. > > After that, implement whatever new feature you want in the > backends. The backends API is now a private API between saned and the > backends. Updates to the public SANE API as implemented by libsane > only requires changing libsane. As an added bonus, a compat layer can > probably be offered for current backends that cannot be modified. > > The network protocol will also probably need to change at some point, > I haven't thought about that particular point yet. More interactivity, > more status messages and the ability to feed scan data over a unique > TCP stream would be nice. > > User ACLs can be added to the mix. > > We're losing the ability to link an application to a backend directly > as is possible today, but it's seldomly use and we're getting rid of > those frigging side effects we have today. > > If we're redoing SANE, let's at least do it the right way. Investing > time and effort into something that'll only be marginally better than > what we have today makes no sense. > > JB. Cr?ez votre adresse ?lectronique pr?nom.nom at laposte.net 1 Go d'espace de stockage, anti-spam et anti-virus int?gr?s. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080330/a990045c/attachment.htm
