[Printing-architecture] Architecture meeting agenda 20030612. . .

[Printing-architecture] Architecture meeting agenda 20030612. . .

[Charles Hemstreet]

New meeting time for our architecture teleconference:

Every Thursday
1200-1300 PST
1300-1400 MST
1400-1500 CST
1500-1600 EST
2000-2100 UTC

There is a new call-in number:

          - *Toll Free Access Number:
            866-639-4758 (toll-free)
            574-935-6716 (toll)

          - Participant PIN:
            2124490

Agenda:

1) FSG/OP schedule
2) review of new architecture diagrams

These files are stored on the PWG anonymous FTP server at:

ftp://ftp.pwg.org/pub/pwg/fsg/architecture/arch1-6-12-03.jpg

ftp://ftp.pwg.org/pub/pwg/fsg/architecture/arch2-6-12-03.jpg

Thanks,
Charles

_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail

Re: [Printing-architecture] Architecture meeting agenda 20030612. . .

[Michael Sweet]

Charles Hemstreet wrote:
> New meeting time for our architecture teleconference:
> ...
> ftp://ftp.pwg.org/pub/pwg/fsg/architecture/arch1-6-12-03.jpg
> 
> ftp://ftp.pwg.org/pub/pwg/fsg/architecture/arch2-6-12-03.jpg

As I can't attend any of the teleconferences due to scheduling
conflicts, here are some comments on the current diagrams:

     1. The diagram separates the bidi handling from the driver,
        which won't work for several consumer inkjet devices that
        I personally know of.  Either remove this box or put it
        in-line so that the output from the printer driver can be
        massaged by the vendor filter.

        Example: the EPSON inkjet printers use a special packet
        mode via USB or parallel port to provide continuous status
        updates; this special handling can be put in a "monitor"
        filter in-line between the driver filter and backend to
        packetize the output and provide ink status, etc. as the
        job is printed.  If you implement it the way the diagram
        is, then the driver has to do all of the device-specific
        stuff (and that device-specific stuff varies based upon
        the interface, and it isn't always possible to automatically
        determine the right mode - it needs to be configurable)
        and the back-channel filter somehow needs to be able to
        send as well as recieve data without trashing the driver's
        output.

     2. There absolutely cannot be a direct link between a device
        backend or vendor filter and a vendor-supplied UI.  Such
        an interface opens up major security issues not to mention
        that it likely won't work in a networked environment and
        will kill any interoperability.

        Any driver/filter communications should be in the form of
        state information that is communicated to the scheduler,
        which can then provide the information to apps in a
        consistent way.  Vendors can provide UIs that query this
        information, and the *same* interface can be used by all
        vendors.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Printing Software for UNIX                       http://www.easysw.com

Re: [Printing-architecture] Architecture meeting agenda 20030612. . .

[Pete Zannucci]

Michael Sweet wrote:


> The diagram separates the bidi handling from the driver,
> which won't work for several consumer inkjet devices that
> I personally know of.  Either remove this box or put it
> in-line so that the output from the printer driver can be
> massaged by the vendor filter.

        > this special handling can be put in a "monitor"
        > filter in-line between the driver filter and backend
        > to packetize the output and provide ink status, etc.

You're correct Michael.  I had used the lines coming from the
driver going back to the spool system as really just an api/
interface to the backend (the possible owner of the library
that supports the common backend interface.  So in fact,
the bidi work would be done by the monitor.  I simplified it
because there are likely multiple users of the data and put
it in as an interface back through the spool system.  I will
try and think of a way to clarify it.

> There absolutely cannot be a direct link between a device
> backend or vendor filter and a vendor-supplied UI.

> Any driver/filter communications should be in the form of
> state information that is communicated to the scheduler,
> which can then provide the information to apps in a
> consistent way.  Vendors can provide UIs that query this
> information, and the *same* interface can be used by all
> vendors.

The interfaces for the bidi management will definitely have
to adhere to one single api set and be plug compatible otherwise
there is no need to a bidi spec.  Everyone can do it for their
devices.  As far as the scheduler that you suggest, I envision
that as just another layer of the backend processing.  The
bidi box is to merely show that the bidi stuff should be
isolated out and should be able to plug in via a common
interface.

I didn't focus on clarifying the bidi area as much because most
of the work everyone thought needed to be done was in the upper
portion of the system and providing an API that is usable
for an application.  The key to starting this and I think the
one real reason to start with PAPI is that applications can
be easily written and portable across systems.

As we dig deeper into the other subsystems we can map them out
better.  The primary reason for doing this level of a drawing
was to try and map out areas of work and not forget where the
components lie where.

Your comments are very helpful and we can put more information
into the drawing (though it is pretty busy right now).  Then
we can start breaking the low level drawing into succinct parts
so that we truly can be sure we didn't miss anything or any
interface.

Peter Zannucci

IBM Linux Technology Center
Open Source Software Development
Omni Print Project http://sourceforge.net/projects/omniprint
Austin, TX - Tel. 512-838-4687 (t/l 678) pzaan@us.ibm.com