[Printing-architecture] RE: [Printing-summit] RE: where is th e info on driver directories

[Petrie, Glen]

Olaf

Thanks for all your help and feedback.  I will follow your recommendations
and suggestions.  I will try to summarizes our discussion and present it the
OP architecture team for review.  Again, thanks.

glen

> -----Original Message-----
> From: Olaf Meeuwissen [mailto:olaf.meeuwissen at avasys.jp]
> Sent: Monday, November 12, 2007 4:11 PM
> To: Petrie, Glen
> Cc: Olaf Meeuwissen; printing-architecture at lists.freestandards.org;
> printing-summit at lists.linux-foundation.org
> Subject: Re: [Printing-architecture] RE: [Printing-summit] RE: where is th
> e info on driver directories
> 
> I've got only very little time ...
> 
> "Petrie, Glen" <glen.petrie at eitc.epson.com> writes:
> 
> > < ... snip ... >
> >
> >> Eh, why not just add an option to /usr/bin/pdpca to list what is
> >> there.  For your example:
> >>
> >>   pdpca --dev guten --list
> >>
> >> You could even have options to get a list of valid arguments for the
> >> --dev option.  Why make the user navigate the file system if a tool
> >> can do it for them?
> >
> > [gwp] ok, there is a single 'controlling' pdpca application which can
> invoke
> > a developer specific version of a pdpca and the 'controlling' pdpca is
> > location in 'foo' with a actual path added to the system $PATH variable.
> 
> The "controlling" pdpca lives in /usr/bin/pdpca (on FHS/LSB compliant
> systems).  Systems that do not even have /usr/bin in their default
> PATH are perverse.
> 
> > Then the 'controlling' pdpca would have options as
> >
> > pdpca --list 			: list the possible developers
> > pdpca --devel foo --list	: list the options for the developers
> >
> > to actually execute, use
> >
> > pdpca [-t,-h,-i,-s] --devel foo [option]
> >
> > this would now locate and execute the requested/actual pdpca
> >
> > Now the user/HD does not need to know where the actual pdpca app's are
> but
> > the 'controlling' pdpca will.  But again, as you suggest, the system
> $PATH
> > variable is updated to include the developer path to their pdpca.
> 
> That's not what I suggested and would unnecessarily pollute the user's
> environment.  The LSB DDK can take care of symlinking the "actual"
> pdpca apps to /usr/bin/, which is in the user's PATH.
> 
> > I can [not]
> > remember if you suggested using a new system $PDPCA variable which would
> > have the path for the actual pdpca software or just use the system $PATH
> > variable (which is getting pretty long considering printing is not the
> only
> > thing needing path info).
> 
> I did not suggest using a PDPCA environment variable.
> 
> > The alternative to using system variables for each developer is to use
> the
> > directory structure I have been proposing along with the 'controlling'
> pdpca
> > (the 'controlling' pdpca does a $PATH entry).
> 
> As Till also mentioned, we already have an agreed upon directory
> structure.  Those "actual" pdpca apps should live in
> /opt/<supplier>/bin and can follow the naming convention you
> suggested.
> 
> >   This way printing things are
> > collected under one directory and there may not be a need for linking
> > (things are in known locations which I see a good approach for the goal
> of
> > making printing easier on Linux including all aspects for retrieving
> > capabilities, drivers, etc).
> 
> As a matter of fact, I'm also not much in favour of symlinking all
> those "actual" pdpca apps below /usr/bin.  The "controlling" pdpca can
> quite easily search for "actual" pdpca apps in all /opt/<supplier>/bin
> directories and build lists dynamically.  Even with say a hundred
> suppliers with a hunderd test apps each, that would not be a big
> overhead.  The "controlling" pdpca does not have to be a speed daemon
> when it comes to finding the right info/app.
> 
> Besides, it could create a cache if speed becomes an issue.
> 
> > < ... snip ... >
> >
> >> FWIW, manufacturer, developer and supplier are three different hats.
> >> It just so happens that there's usually only one or two heads wearing
> >> them.
> >
> > [gwp] Actually I would like to see use establish the definition for the
> > three entities in context of printing drivers and printers.  To get the
> > discussion rolling I suggest the following as starting points.
> >
> > Manufacturer:
> > -- The Company, Project, Entity or Person who Company's, Project's,
> Entity's
> > or Person's name is affixed to a hardware unit.
> 
> Must be my English, but this doesn't quite parse for me.  If you mean:
> 
>   The Company, Project, Entity or Person whose name is affixed to a
>   hardware unit.
> 
> then that's something I can agree with.
> 
> > ----- This means that an OEM company is not the "Manufacturer".
> Although an
> > OEM company produced the actual hardware; the OEM company name is not
> > affixed to the product.
> >
> >
> > Developer:
> > -- The Company, Project, Entity or Person who Company's, Project's,
> Entity's
> > or Person's name is affixed to a software application.
> 
> Same parse error here.
> 
> > ----- This means that an OEM software company is not the "Developer".
> > Although the OEM company produced the actual software; the OEM company
> name
> > is not affixed to the product.
> >
> >
> > Supplier:
> > -- The Company, Project, Entity or Person who distributes the hardware
> or
> > software but may or may not be the Company, Project, Entity or Person
> who
> > Company's, Project's, Entity's or Person's name that is affixed to the
> > hardware or software.
> 
> And again.
> Actually, I think it's enough for a supplier to distribute the
> software and have their name affixed to it.  I don't see the point of
> the hardware distribution part.
> 
> > ----- RedHat can be a supplier of Epson Printer Drivers but they are the
> > Developer or the Manufacturer.  However, when someone refers to "the
> Epson's
> > Printer Driver" which may be produced by an OEM or subcontractor for
> Epson
> > but Epson affixes their name to the driver; then, Epson is still the
> > Manufacturer and Developer along with be the possible Supplier.
> >
> > So for the pdpca application it is not Supplier, but the Developer that
> is
> > being specified.
> >
> > If the actually printer is being specified, then it we would refer to
> the
> > Manufacturer.
> >
> > Glen
> 
> Hope this helps,
> --
> Olaf Meeuwissen             FLOSS Engineer -- EPSON AVASYS Corporation
> FSF Associate Member #1962           sign up at http://member.fsf.org/
> GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97  976A 16C7 F27D 6BE3 7D90
> Penguin's lib!       -- I hack, therefore I am --               LPIC-2