[Printing-architecture] Request for comment to PCM draft

[Printing-architecture] Request for comment to PCM draft

[Ide Kentaro]

Hi, folks,

I posted link of PCM draft document to OpenPrinting web site.
<http://www.openprinting.org/moin.cgi/OpenPrinting/PrintChannelManager>

I would like you to comment these documents with two viewpoints.

	1. Architecture
		If you predict that a problem occurs to your system with this architecture,
		point out the problem, please.

	2. License
		My questions are "Which license is better for us?" and
		"As for we should we select the license that was unified
		with all the Open Printing documents? ".

		We chose BSD like license to PCM specification, today.
		But some other documents chose another license as FDL.
		One of the license of a BSD derivation may be easy to accept,
		in the case that the application in business with one,
		although it is natural to use FDL and the licenses of
		other GNU derivations, if I think with the position
		that says FSG.
		So, comment your idea about license of these documents, please.

Best regards,
--
Kentaro Ide
VA Design Engineering  Group
Seiko Epson Corp.

Re: [Printing-architecture] Request for comment to PCM draft

[Michael Sweet]

Ide Kentaro wrote:
> Hi, folks,
> 
> I posted link of PCM draft document to OpenPrinting web site.
> <http://www.openprinting.org/moin.cgi/OpenPrinting/PrintChannelManager>
> 
> I would like you to comment these documents with two viewpoints.
> 
> 	1. Architecture
> 		If you predict that a problem occurs to your system with this architecture,
> 		point out the problem, please.

1. Architecture Diagram

    It isn't clear how this will work with CUPS; the architecture
    diagram references an "Open Printing System", but the diagram
    does *not* match up with how CUPS interfaces with and discovers
    devices.

    Basically, I'd focus on the PCM design/architecture itself, and
    then show possible interfaces with other apps like CUPS, SANE,
    and so forth.  All of the PCM stuff should be in the middle,
    possible apps/users at the top, and devices at the bottom.

2. Device Discovery

    The spec and API only focus on accessing a particular device.
    There is no way to discover or enumerate devices, which is
    most definitely going to be needed.

3. Asynchronous I/O, Non-Blocking IO, and/or Timeouts

    The read and write APIs need to support non-blocking I/O or at
    least basic timeouts so that an application can communicate
    without getting hung/deadlocked.

    It would also be useful to get a file descriptor or some
    other mechanism so that you can poll() or select() for
    ok-to-read/write conditions.

    Without this, you are forced to use threading which is
    problematic.

> 	2. License
> 		My questions are "Which license is better for us?" and
> 		"As for we should we select the license that was unified
> 		with all the Open Printing documents? ".
> 
> 		We chose BSD like license to PCM specification, today.
> 		But some other documents chose another license as FDL.
> 		One of the license of a BSD derivation may be easy to accept,
> 		in the case that the application in business with one,
> 		although it is natural to use FDL and the licenses of
> 		other GNU derivations, if I think with the position
> 		that says FSG.
> 		So, comment your idea about license of these documents, please.

As far as licensing goes, BSD or LGPL is suitable for the code, but
simple copyright (with FSG as the copyright holder) should be used
for the spec since you don't want to have others modify the spec
once it has been accepted.

That is, specifications/standards documents are normally controlled
by the organization that produced them...

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com

RE: [Printing-architecture] Request for comment to PCM draft

[McDonald, Ira]

Hi,

Per current work (and minutes) of the FSG/OP Architecture WG,
both Status Monitoring and Device Discovery are first-class
_independent_ modules of the FSG "Open Printing System".

PCM should be _strictly_ concerned with establishing connections 
and/or paths to already _known_ services and devices and passing 
data.

Neither PCM nor Status Monitoring should ever attempt to do 
their own device discovery.

The purpose of the FSG "Open Printing System" architecture is NOT
simply to serve the convenience (and current implementation design) 
of CUPS (or any other printing software).

Neither is the purpose simply to serve desktop printing needs.

The purpose is to define a single common printing architecture 
that spans from very low-bandwidth devices (e.g., PDAs and 
cellphones) to professional production printing devices and
can be implemented on any Linux, UNIX, or other operating
system.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

> -----Original Message-----
> From: printing-architecture-bounces@lists.freestandards.org
> [mailto:printing-architecture-bounces@lists.freestandards.org]
> On Behalf
> Of Michael Sweet
> Sent: Friday, February 10, 2006 4:50 PM
> To: Ide Kentaro
> Cc: printing-architecture@freestandards.org
> Subject: Re: [Printing-architecture] Request for comment to PCM draft
> 
> 
> Ide Kentaro wrote:
> > Hi, folks,
> > 
> > I posted link of PCM draft document to OpenPrinting web site.
> > 
> <http://www.openprinting.org/moin.cgi/OpenPrinting/PrintChanne
> lManager>
> > 
> > I would like you to comment these documents with two viewpoints.
> > 
> > 	1. Architecture
> > 		If you predict that a problem occurs to your 
> system with this architecture,
> > 		point out the problem, please.
> 
> 1. Architecture Diagram
> 
>     It isn't clear how this will work with CUPS; the architecture
>     diagram references an "Open Printing System", but the diagram
>     does *not* match up with how CUPS interfaces with and discovers
>     devices.
> 
>     Basically, I'd focus on the PCM design/architecture itself, and
>     then show possible interfaces with other apps like CUPS, SANE,
>     and so forth.  All of the PCM stuff should be in the middle,
>     possible apps/users at the top, and devices at the bottom.
> 
> 2. Device Discovery
> 
>     The spec and API only focus on accessing a particular device.
>     There is no way to discover or enumerate devices, which is
>     most definitely going to be needed.
> 
> 3. Asynchronous I/O, Non-Blocking IO, and/or Timeouts
> 
>     The read and write APIs need to support non-blocking I/O or at
>     least basic timeouts so that an application can communicate
>     without getting hung/deadlocked.
> 
>     It would also be useful to get a file descriptor or some
>     other mechanism so that you can poll() or select() for
>     ok-to-read/write conditions.
> 
>     Without this, you are forced to use threading which is
>     problematic.
> 
> > 	2. License
> > 		My questions are "Which license is better for us?" and
> > 		"As for we should we select the license that was unified
> > 		with all the Open Printing documents? ".
> > 
> > 		We chose BSD like license to PCM specification, today.
> > 		But some other documents chose another license as FDL.
> > 		One of the license of a BSD derivation may be 
> easy to accept,
> > 		in the case that the application in business with one,
> > 		although it is natural to use FDL and the licenses of
> > 		other GNU derivations, if I think with the position
> > 		that says FSG.
> > 		So, comment your idea about license of these 
> documents, please.
> 
> As far as licensing goes, BSD or LGPL is suitable for the code, but
> simple copyright (with FSG as the copyright holder) should be used
> for the spec since you don't want to have others modify the spec
> once it has been accepted.
> 
> That is, specifications/standards documents are normally controlled
> by the organization that produced them...
> 
> -- 
> ______________________________________________________________________
> Michael Sweet, Easy Software Products           mike at easysw dot com
> Internet Printing and Document Software          http://www.easysw.com
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.freestandards.org
> http://lists.freestandards.org/cgi-bin/mailman/listinfo/printi
> ng-architecture
> 

Re: [Printing-architecture] Request for comment to PCM draft

[Michael Sweet]

McDonald, Ira wrote:
> Hi,
> 
> Per current work (and minutes) of the FSG/OP Architecture WG,
> both Status Monitoring and Device Discovery are first-class
> _independent_ modules of the FSG "Open Printing System".
> 
> PCM should be _strictly_ concerned with establishing connections 
> and/or paths to already _known_ services and devices and passing 
> data.
> 
> Neither PCM nor Status Monitoring should ever attempt to do 
> their own device discovery.

OK, so it is basically worthless then?

The level of implementation in the current spec implies something
that is much more than what you are describing.  The *operating
system* already provides the kind of interface you are describing.

 From what I understand of the current spec, PCM is concerned with
multiplexing access to devices so that they can be used by
multiple services.  In order for that to work, applications that
use PCM MUST be able to enumerate/discover devices that are
managed by it.  Whether this happens in PCM or not is not
particularly important, but it has to happen someplace, and the
PCM spec MUST reference the mechanism that is used...

> The purpose of the FSG "Open Printing System" architecture is NOT
> simply to serve the convenience (and current implementation design) 
> of CUPS (or any other printing software).

Quite frankly, I don't care.  But if you want what you are defining
to work with existing software, it MUST coexist with and "serve the
convenience of" CUPS and other existing printing software.

> Neither is the purpose simply to serve desktop printing needs.
> 
> The purpose is to define a single common printing architecture 
> that spans from very low-bandwidth devices (e.g., PDAs and 
> cellphones) to professional production printing devices and
> can be implemented on any Linux, UNIX, or other operating
> system.

Good luck with reimplementing IPP and PSI, Ira...

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Publishing Software        http://www.easysw.com

RE: [Printing-architecture] Request for comment to PCM draft

[McDonald, Ira]

Hi Michael,

Sorry for giving offense by my note.

The strict downscoping of PCM to transport/session manager
has been documented in FSG/OP Architecture minutes and notes
since mid-2005.

I didn't personally make up the architecture.  

Oh well...

Regards,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

> -----Original Message-----
> From: Michael Sweet [mailto:mike@easysw.com]
> Sent: Saturday, February 11, 2006 7:08 PM
> To: McDonald, Ira
> Cc: Ide Kentaro; printing-architecture@freestandards.org
> Subject: Re: [Printing-architecture] Request for comment to PCM draft
> 
> 
> McDonald, Ira wrote:
> > Hi,
> > 
> > Per current work (and minutes) of the FSG/OP Architecture WG,
> > both Status Monitoring and Device Discovery are first-class
> > _independent_ modules of the FSG "Open Printing System".
> > 
> > PCM should be _strictly_ concerned with establishing connections 
> > and/or paths to already _known_ services and devices and passing 
> > data.
> > 
> > Neither PCM nor Status Monitoring should ever attempt to do 
> > their own device discovery.
> 
> OK, so it is basically worthless then?
> 
> The level of implementation in the current spec implies something
> that is much more than what you are describing.  The *operating
> system* already provides the kind of interface you are describing.
> 
>  From what I understand of the current spec, PCM is concerned with
> multiplexing access to devices so that they can be used by
> multiple services.  In order for that to work, applications that
> use PCM MUST be able to enumerate/discover devices that are
> managed by it.  Whether this happens in PCM or not is not
> particularly important, but it has to happen someplace, and the
> PCM spec MUST reference the mechanism that is used...
> 
> > The purpose of the FSG "Open Printing System" architecture is NOT
> > simply to serve the convenience (and current implementation design) 
> > of CUPS (or any other printing software).
> 
> Quite frankly, I don't care.  But if you want what you are defining
> to work with existing software, it MUST coexist with and "serve the
> convenience of" CUPS and other existing printing software.
> 
> > Neither is the purpose simply to serve desktop printing needs.
> > 
> > The purpose is to define a single common printing architecture 
> > that spans from very low-bandwidth devices (e.g., PDAs and 
> > cellphones) to professional production printing devices and
> > can be implemented on any Linux, UNIX, or other operating
> > system.
> 
> Good luck with reimplementing IPP and PSI, Ira...
> 
> -- 
> ______________________________________________________________________
> Michael Sweet, Easy Software Products           mike at easysw dot com
> Internet Printing and Publishing Software        http://www.easysw.com
> 

RE: [Printing-architecture] Request for comment to PCM draft

[Ide Kentaro]

Hi,

As Ira says, PCM don't have device discovery mechanism within itself.
PCM rely the function of device discovery on the other module of Open Printing System.
In my recogunition, Architecture-team discuss about these architecture
that iclude device discovery and device information management, so on.
After architecture fixed, PCM will be modifing specification or adjusting
in implementation for ensure consistency.

In the other hand, we, printing-japan team, design PCM specification with
existence printing system in mind but solo-PCM can't implemet to existence printing system like as CUPS.
What I'm trying to say is, combined some Open Printing module and glue code
will be coexistence with CUPS or other system.

Implementation study of Open Printing project will be serve as good example.
<http://lx1.avasys.jp/OpenPrintingProject/index_e.html>


Michael Sweet wrote
| As far as licensing goes, BSD or LGPL is suitable for the 
| code, but simple copyright (with FSG as the copyright holder) 
| should be used for the spec since you don't want to have 
| others modify the spec once it has been accepted.
| 
| That is, specifications/standards documents are normally 
| controlled by the organization that produced them...

That's right.
And we need uniform license for documents of Open Printing, doesn't?
The point of my question is it.

Anyway, I'll try to discuss a license and your comment in meeting of Printing-Japan, ongoingly.

Best regards,
Kentaro Ide