Yiannis Belias <jonnyb at hol.gr> wrote: Hi,
> Of course you're right. I failed to recend the link with the > suggested work-flow, sorry. > http://orion.freehost.gr/gsoc-sane-workflow#B > What I meant above, was replacing the call at step (5)a with a call > to a new get_icc_profile(). > That call is made by the oyranos backend. The frontend would get the > icc data from oyranos. You're still missing out on what Allan and I told you both in different terms: the frontend cannot know it's scanning over the network. It also cannot know how many saned instances are involved in the chain. Of course you can try to hack you way around that by parsing the device name string, but that string is to be considered an opaque object that's not open to interpretation by anyone but the first backend in the chain. To make that clear, scanning through the network gives a device name like net:10.23.12.42:<device name> with <device name> being the device name as seen by the remote saned server. Which means net:10.23.12.42:net:saned.foo.org:<devicename> is what you get when you chain two network backends. There is no reason why this cannot become net:<hash> or something alike that will in effect be totally unintelligible to anyone but the net backend in the future. There is also no reason why the name of the backend should appear in this string - this is purely a design decision of the dll backend. Parsing the device name should not be attempted. Only the first backend in the chain knows how to interpret it. You can try to hack your way around that, but it's going to be horribly fragile and a nightmare to maintain. Even if you were to do this, the Oyranos backend still has to connect to the remote saned instance. If saned is running through inetd, this just cannot happen. If saned is running standalone, you're not out of the woods just yet. You need to somehow point saned to the correct session so it can pass the correct handle to its local Oyranos backend. But even then, there's still a potential issue if the Oyranos backend fetches options behind the frontend's (or saned's) back. It's especially touchy with saned and the net backend as we're already walking on the line with the standard here. > I'm just trying to make sure that I didn't miss a possibility for > making this work with the least disturbance on the sane codebase. The issue is actually in coming up with the appropriate solutions to the applicable set of problems. Can't come up with the former if you don't have the latter well-defined, and really it's only starting to appear out of the fog now. I have some doubts as to the scalability and supportability of what you're proposing wrt scanner/options fingerprinting. This is going to require some serious manpower to maintain over time, at all levels: Oyranos upstream, local admin, user. Though you're correct about the SHA1 and error reporting. I thought the Oyranos repository was central, but it's actually on the machine. I'm really not sure about that in an environment with a lot of devices. Looks like it requires some heavy maintenance to spread ICC profiles around on all user machines and keep everything in sync. Out of the scope of your project, but still. JB. -- Julien BLACHE <http://www.jblache.org> <jb at jblache.org> GPG KeyID 0xF5D65169
