Re: [Printing-architecture] [lsb-discuss] LSB 4.0 and printing

Re: [Printing-architecture] [lsb-discuss] LSB 4.0 and printing

[Till Kamppeter]

What can be added without problems is SANE, as this is in every common 
distro and with the strong trend on multi-function devices it is very 
important for hardware vendors to make driver packages. It also allows 
to expand the initiative on distribution-independent driver packages to 
scanners (including stand-alone devices).

Doing uplifts, like CUPS 1.1.x -> 1.2.x is not possible as LSB 4.0 is 
based on the same enterprise distros as 3.2. Why not 3.3 then? We should 
raise the major number for new enterprise distros as base and the minor 
for a new LSB based on the same enterprise distros. WDYT?

Any suggestions on what else to add to the printing requirements?

We will also talk in Austin on the joint session of LSB and OpenPrinting 
about that subject.

    Till

Jeff Licquia wrote:
> The LSB 4.0 project plan 
> (https://www.linux-foundation.org/en/ProjectPlan40) has this to say 
> about printing requirements:
> 
> "Requirements being worked on by Printing Workgroup."
> 
> So I'm checking to see if this is, in fact true.  Does the OpenPrinting 
> workgroup have any requirements they'd like to see in LSB 4.0?
> _______________________________________________
> lsb-discuss mailing list
> lsb-discuss@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss
> 

Re: [Printing-architecture] [lsb-discuss] LSB 4.0 and printing

[Klaus Singvogel]

Till Kamppeter wrote:
> What can be added without problems is SANE, as this is in every common 
> distro and with the strong trend on multi-function devices it is very 
> important for hardware vendors to make driver packages. It also allows 
> to expand the initiative on distribution-independent driver packages to 
> scanners (including stand-alone devices).

The question is for me, if SANE will become a mandatory package
or will it be an optional package only (btw. is there any such
concept in the LSB?).

The background I'm asking is not hard to understand. Running a few
servers, where no users are sitting in front of, I've no need to do
things like scanning or similiar. But the SANE package is a pretty
large one, and therefore it's bloating the disk usage only without
any further advantage.

Kindly regards,
	Klaus.
-- 
Klaus Singvogel
SUSE LINUX Products GmbH
Maxfeldstr. 5                     E-Mail: Klaus.Singvogel@SuSE.de
90409 Nuernberg                   Phone: +49 (0) 911 740530
Germany                           GnuPG-Key-ID: 1024R/5068792D  1994-06-27

SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)

Re: [Printing-architecture] [lsb-discuss] LSB 4.0 and printing

[Klaus Singvogel]

Johannes Meixner wrote:
> I would very much appreciate it if SANE1 was LSB standard.

Still asking myself, why this package should become mandatory for all
kind of machines then, especially why for servers?

Kindly regards,
	Klaus.
-- 
Klaus Singvogel
SUSE LINUX Products GmbH
Maxfeldstr. 5                     E-Mail: Klaus.Singvogel@SuSE.de
90409 Nuernberg                   Phone: +49 (0) 911 740530
Germany                           GnuPG-Key-ID: 1024R/5068792D  1994-06-27

SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)

Re: [Printing-architecture] [lsb-discuss] LSB 4.0 and printing

[Till Kamppeter]

Lets's a SANE only to the desktop part of the LSB. Is this possible?

    Till

Klaus Singvogel wrote:
> Johannes Meixner wrote:
>> I would very much appreciate it if SANE1 was LSB standard.
> 
> Still asking myself, why this package should become mandatory for all
> kind of machines then, especially why for servers?
> 
> Kindly regards,
> 	Klaus.

Re: [Printing-architecture] [lsb-discuss] LSB 4.0 and printing

[Klaus Singvogel]

Johannes Meixner wrote:
[...]
> The same question applies for printing:
> 
> Should printing be mandatory for all kind of machines
> in particular for servers which never submit a print job
> (e.g. a plain mail server or a plain web server)?

Printing a job to a server can be done without any user interaction.
So I can see the arguments why a server machine can easily be used
as a print server too (for spooling).

But scanning usually requires interaction, like turning pages on the
scanner, pressing some buttons, watching previews, cutting the image,
etc. This cannot be done without having a user sitting in front of the
machine, and IMHO this contradicts the server declaration. Therefore
I don't see a need to blow a server with SANE packages additional.

I thought, I already gave this hint in my first posting...

Regards,
	Klaus.
-- 
Klaus Singvogel
SUSE LINUX Products GmbH
Maxfeldstr. 5                     E-Mail: Klaus.Singvogel@SuSE.de
90409 Nuernberg                   Phone: +49 (0) 911 740530
Germany                           GnuPG-Key-ID: 1024R/5068792D  1994-06-27

SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)

Re: [Printing-architecture] [lsb-discuss] LSB 4.0 and printing

[Klaus Singvogel]

Johannes Meixner wrote:
> 
> Have a network scanner (a scanner with ethernet connection)
> in an office for several people.

If the scanner has ethernet connection, any user can install drivers
on his _desktop_. No need to restrict installation on a _server_, or?

> Run the scanner driver (the SANE backend) together with
> the saned on an arbitrary server machine somewhere in
> a locked server room to have both the driver and the
> access permission stuff under full control of the admin
> of the central server.

What's the advantage of your model? It seems not very practicable and
a bit uncommon to me.

Restricting printing access is easy to explain: every single page
printed out costs resources (paper, toner, etc).

But scanning?

Why restricting a network scanner to special users and not to a
special, secure place? If there is no trust to all of the users, why
is the network scanner physical accessible to anyone, with danger of
thefts, and the scanning restricted to users? Why not locking the
scanner into a restricted room?

I neither see how you can prevent scanning by the bad guys, if the
scanner is still accessible by (physical) anyone and (by software)
through whole network?

I would suggest to setup a special desktop machine with limited
physical access in such an scenario into a special secured room. IMHO
more secure.

Another solution for your example might be to setup a a _desktop_
machine and use (in a limited way) as a server for above scenario. No
need to blow up all the other server machines with unnecessary scanner
software.

And I think it is a very limited, uncommon scenario you describe.
Let us stay at the more common real life examples, please.

> Run the scanning frontend together with the SANE "net"
> meta-driver on the individual user's workstation where
> it doesn't harm others if one user corrupts his workstation.

Workstation means a desktop machine right? So again: scanning with
SANE is done on the desktop machine.

Kindly regards,
	Klaus.
-- 
Klaus Singvogel
SUSE LINUX Products GmbH
Maxfeldstr. 5                     E-Mail: Klaus.Singvogel@SuSE.de
90409 Nuernberg                   Phone: +49 (0) 911 740530
Germany                           GnuPG-Key-ID: 1024R/5068792D  1994-06-27

SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)

Re: [Printing-architecture] [lsb-discuss] LSB 4.0 and printing

[Ira McDonald]

Hi,

My two cents...

I agree with Klaus.  Network scanning (remote submission of scan jobs)
is ALWAYS done from a client desktop machine directly to the networked
scanner or multifunction device.  Adding SANE packages to a Linux server
never makes sense in the real world - just one more needless security risk.

Cheers,
- Ira

-- 
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music/High North Inc
email: blueroofmusic@gmail.com
winter:
 579 Park Place Saline, MI 48176
 734-944-0094
summer:
 PO Box 221 Grand Marais, MI 49839
 906-494-2434


On Thu, Mar 27, 2008 at 12:55 PM, Klaus Singvogel <kssingvo@suse.de> wrote:
> Johannes Meixner wrote:
>  >
>  > Have a network scanner (a scanner with ethernet connection)
>  > in an office for several people.
>
>  If the scanner has ethernet connection, any user can install drivers
>  on his _desktop_. No need to restrict installation on a _server_, or?
>
>  > Run the scanner driver (the SANE backend) together with
>  > the saned on an arbitrary server machine somewhere in
>  > a locked server room to have both the driver and the
>  > access permission stuff under full control of the admin
>  > of the central server.
>
>  What's the advantage of your model? It seems not very practicable and
>  a bit uncommon to me.
>
>  Restricting printing access is easy to explain: every single page
>  printed out costs resources (paper, toner, etc).
>
>  But scanning?
>
>  Why restricting a network scanner to special users and not to a
>  special, secure place? If there is no trust to all of the users, why
>  is the network scanner physical accessible to anyone, with danger of
>  thefts, and the scanning restricted to users? Why not locking the
>  scanner into a restricted room?
>
>  I neither see how you can prevent scanning by the bad guys, if the
>  scanner is still accessible by (physical) anyone and (by software)
>  through whole network?
>
>  I would suggest to setup a special desktop machine with limited
>  physical access in such an scenario into a special secured room. IMHO
>  more secure.
>
>  Another solution for your example might be to setup a a _desktop_
>  machine and use (in a limited way) as a server for above scenario. No
>  need to blow up all the other server machines with unnecessary scanner
>  software.
>
>  And I think it is a very limited, uncommon scenario you describe.
>  Let us stay at the more common real life examples, please.
>
>  > Run the scanning frontend together with the SANE "net"
>  > meta-driver on the individual user's workstation where
>  > it doesn't harm others if one user corrupts his workstation.
>
>  Workstation means a desktop machine right? So again: scanning with
>  SANE is done on the desktop machine.
>
>  Kindly regards,
>
>
>         Klaus.
>  --
>  Klaus Singvogel
>  SUSE LINUX Products GmbH
>  Maxfeldstr. 5                     E-Mail: Klaus.Singvogel@SuSE.de
>  90409 Nuernberg                   Phone: +49 (0) 911 740530
>  Germany                           GnuPG-Key-ID: 1024R/5068792D  1994-06-27
>
>  SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
>  _______________________________________________
>  Printing-architecture mailing list
>  Printing-architecture@lists.linux-foundation.org
>  https://lists.linux-foundation.org/mailman/listinfo/printing-architecture
>

Re: [Printing-architecture] [lsb-discuss] LSB 4.0 and printing

[Till Kamppeter]

So then let's add SANE1 to the LSB, but as a desktop requirement, so 
that if we do splitting that it gets desktop-only.

One question: Is libgtk2 currently required on servers?

    Till


Ira McDonald wrote:
> Hi,
> 
> My two cents...
> 
> I agree with Klaus.  Network scanning (remote submission of scan jobs)
> is ALWAYS done from a client desktop machine directly to the networked
> scanner or multifunction device.  Adding SANE packages to a Linux server
> never makes sense in the real world - just one more needless security risk.
> 
> Cheers,
> - Ira
> 

Re: [Printing-architecture] [lsb-discuss] LSB 4.0 and printing

[Klaus Singvogel]

Till Kamppeter wrote:
> One question: Is libgtk2 currently required on servers?

Good question, hard to answer.

It might help, why and from which application this requirement
came from. Lets decide then.

Usually if a user installs Gnome desktop on his server, then it
might be a good idea to have it in the system -- but I think that
this requirement should come from Gnome itself then.

Kindly regards,
	Klaus.
-- 
SUSE LINUX Products GmbH,  GF: Markus Rex,  HRB 16746 (AG Nuernberg)
Maxfeldstr. 5 - 90409 Nuernberg - Germany /// Phone: +49-911-74053-0
GnuPG-Key-ID: 1024R/5068792D  1994-06-27

Re: [Printing-architecture] [lsb-discuss] LSB 4.0 and printing

[Klaus Singvogel]

Johannes Meixner wrote:
> On Mar 27 17:55 Klaus Singvogel wrote
> [whether or not it may make sense or not
>  to have scanning software on a server]
> 
[...]
> All I wanted to point out is that running scanner drivers
> on a server can be done and can make sense.
> 
> I never said that running scanner drivers on a server
> is the usual way to access a scanner.
[...]

Thanks for agreeing to us.

To my knowledge LSB is only setting up a basic installation
for a system. Therefore bloating the system unnecessary should
be avoided. It's not about forbidding distributions to add the
scanner packages on their media for server installation, and not
about preventing users to install such packages on their servers,
it's only about to leave packages in the basic setup away, where
a common use doesn't make sense.

Kindly regards,
	Klaus.
-- 
Klaus Singvogel  -  Maxfeldstr. 5  -  90409 Nuernberg  -  Germany
Phone: +49-911-74053-0
GnuPG-Key-ID: 1024R/5068792D  1994-06-27
SUSE LINUX Products GmbH,  GF: Markus Rex,  HRB 16746 (AG Nuernberg)

Re: [Printing-architecture] [lsb-discuss] LSB 4.0 and printing

[Till Kamppeter]

Johannes Meixner wrote:
> Hello,
> 
> On Mar 26 22:34 Till Kamppeter wrote (shortened):
>> What can be added without problems is SANE
> 
> "SANE Standard Version 1.0" (the so called "SANE1")
> to be precise, see
> http://www.sane-project.org/docs.html
> 
> I would very much appreciate it if SANE1 was LSB standard.
> 
> As Till already mentioned:
> Without a scanning standard in LSB (which is compatible
> with the LSB printing standard), there is just no support
> for all-in-one devices in LSB.
> 

Having scanning covered by the LSB standard will not only help to get 
printer manufacturers fully support their multi-function devices, it 
will also help scanner manufacturers to ship Linux drivers for their 
devices.

> But I should mention that there is since a long time
> the discussion on sane-devel@lists.alioth.debian.org
> how to move forward with SANE.
> 

There was again a longer posting about SANE2 today on the SANE mailing 
liat. See below.

> Unfortunately - as far as I understand it - the planned
> SANE2 API would not be backward-compatible with SANE1
> which is a main reason - as far as I understand it - why
> there is no real progress how to move forward with SANE.
> 

We must standardize on SANE1, as this is in the distros. SANE2 will for 
sure take at least a year until it comes out when work on it would start 
today. And it will take two more years until it will make it into all 
enterprise distros.

> Perhaps the experience of LSB people with API upgrades
> could even help the SANE developers to find a solution
> how to move forward with SANE.

With a good planning one can perhaps even reach backward compatibility. 
Or one could write a piece of glue code to plug SANE1 drivers into SANE2.

    Till

--------------------------------------------------------------------------

Subject: [sane-devel] SANE2 standard completion
From: stef.dev@free.fr
To: sane-devel@lists.alioth.debian.org

	Hello,

	before any work can start on SANE 2, the current proposal has to be 
completed.

	The major change is the image data format. SANE 2 will be able to 
handle new formats easily (which matches the current needs, especially 
regarding ir
  channel). There will be 2 major image format, one pixel oriented and 
the other will give images as a mime attachment. There is also standard 
part for button handling.

	Here is a summary of the differences between SANE 1 and SANE 2 proposal 
standards:

structures changes:
	- the SANE_Device struct has more fields, giving contact information 
about the devices in case of bug, and the ability to send device 
capability flags
	- the SANE_Parameters changes to suit the image format improvement. It 
also gives new informations such as a proposed filename and X/Y dpi.
	
options changes:
	- capability hidden and allways settable added
	- more commonly used options are now part of the standard

SANE operations changes:
	- sane_open has a SANE_Device ** parameter
	- scanner's button handling

newtwork operation:
	The Network Protocol chapter seems to lag behind the SANE 1 chapter, 
and the SANE_NET_OPEN call needs to be updated to reflect sane_open 
evolution.

		The current proposal is in good shape, and the change regarding image 
format seems to suit the current need for new formats. Converting 
current backends
to SANE2 doesn't seem that difficult.

	But before starting, there are some things I'd like to see in the new 
standard:
	- the current code flow is
	sane_init
		sane_open
			sane_start
				sane_read
			sane_cancel
		sane_close
	sane_exit
	
		rather than calling sane_cancel at the end of scan, I'd like to have a 
sane_end function. Leaving the use of sane_cancel for canceling the scan 
like it allready does. This new function would do about the same, but 
code flow would be cleaner and easier to understand:
	sane_init
		sane_open
			sane_start
				sane_read
			sane_end
		sane_close
	sane_exit
	
	- the proposed button handling would surely be better if we create 
sane_lock_buttons(), sane_update_buttons() and sane_unlock() buttons, 
instead
of doing this with control options.
	
	- we should also add something about panels. Would some control options 
be enough,  or do we also need some lock/update/unlock behavior ?
	
	- there are some issues about backends configuration. In order to be 
detected, some backends need their  configuration files tweaked. I think 
that
having well-known configuration options would improve  the situation and 
would
also let us have a common way of accessing configuration parameters across
backends.
	
	- do we want to improve warmup handling ? Currently there is no 
feedback when warming-up is going on, which is sometime confusing, we 
can have the feeling that nothing is happening. Do we want a 
sane_warm_up() or a
SANE_STATUS_WARMING_UP would be enough ?
	
	There are other points that I feel they could be improved, but could be 
done as we develop SANE2:
	- we need a sane type for scanner buttons. Either we rename the 
SANE_TYPE_BUTTON to SANE_TYPE_SOFT_BUTTON and use SANE_TYPE_BUTTON for
physical buttons, or we create a SANE_TYPE_HARD_BUTTON. So that a 
frontend can easily detect hardware buttons. There should be a list of 
well-known buttons
description to use when  possible.
	- a SANE_TYPE_PANEL would be handy
	- since there are well-know options there should be well-known groups, 
and the SANE_CAP of these options should also be given.
	- a SANE_STATUS_LOCKED could be added to handle the case where the 
hardware lock of a scanner has been left.
	
Regards,
	Stef
	
		

-- sane-devel mailing list: sane-devel@lists.alioth.debian.org 
http://lists.alioth.debian.org/mailman/listinfo/sane-devel Unsubscribe: 
Send mail with subject "unsubscribe your_password" to 
sane-devel-request@lists.alioth.debian.org

Re: [Printing-architecture] [lsb-discuss] LSB 4.0 and printing

[Till Kamppeter]

Theodore Tso wrote:
> 
> So it would be difficult even if the newer (trial-use) version of the
> component is a strict superset of the mandatory component?
> 
> I can understand that if an interface has actually *changed* between
> the two versions, life would be hard; but if it's just a matter of
> marking some interface as trial-use, and others as required, would
> that still be hard?


About the CUPS interfaces I can say that nothing was removed between 
CUPS 1.1.x and 1.2.x. There are only new interfaces and features added.

    Till