[sane-devel] ICC support - summing up

[Julien BLACHE]

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