From: Michael Sweet <mike@easysw.com>
To: "McDonald, Ira" <imcdonald@sharplabs.com>
Cc: printing-architecture@freestandards.org
Subject: Re: [Printing-architecture] Request for comment to PCM draft
Date: Sat, 11 Feb 2006 19:07:43 -0500 [thread overview]
Message-ID: <43EE7C4F.2000603@easysw.com> (raw)
In-Reply-To: <CFEE79A465B35C4385389BA5866BEDF00C7ED3@mailsrvnt02.enet.sharplabs.com>
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
next prev parent reply other threads:[~2006-02-12 0:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-11 19:21 [Printing-architecture] Request for comment to PCM draft McDonald, Ira
2006-02-12 0:07 ` Michael Sweet [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-02-13 17:36 Ide Kentaro
2006-02-13 17:06 McDonald, Ira
2006-02-06 0:38 Ide Kentaro
2006-02-10 21:50 ` Michael Sweet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43EE7C4F.2000603@easysw.com \
--to=mike@easysw.com \
--cc=imcdonald@sharplabs.com \
--cc=printing-architecture@freestandards.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.