[Printing-architecture] Request for comment to PCM draft
imcdonald at sharplabs.com
Mon Feb 13 09:06:20 PST 2006
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
I didn't personally make up the architecture.
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
email: imcdonald at sharplabs.com
> -----Original Message-----
> From: Michael Sweet [mailto:mike at easysw.com]
> Sent: Saturday, February 11, 2006 7:08 PM
> To: McDonald, Ira
> Cc: Ide Kentaro; printing-architecture at 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
More information about the Printing-architecture