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

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

[Petrie, Glen]

< ... snip ... >

> > /usr/lib/supplier/pdpca
> >
< ... snip ... > 

> <ira>
> Why do we need a directory pdpca at all?  Why can't a conforming
> pdpca application just have a simple filename that starts pdpca?
> And be in the SAME directory with the driver package?
> </ira>

< ... snip ... >

Ok! But ... the pdpca is not a driver or such software that will be used by
an application, spooler, print-manager or the system; who can navigate to
any predefined directory tree/structure. The pdpca is a tool; and, as such,
to be used by individuals to test the driver; so my motivation was to make
it easy to find but ....

Glen  

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

[Olaf Meeuwissen]

"Petrie, Glen" <glen.petrie@eitc.epson.com> writes:

> < ... snip ... >
>
>> > /usr/lib/supplier/pdpca
>> >
> < ... snip ... > 
>
>> <ira>
>> Why do we need a directory pdpca at all?  Why can't a conforming
>> pdpca application just have a simple filename that starts pdpca?
>> And be in the SAME directory with the driver package?
>> </ira>
>
> < ... snip ... >
>
> Ok! But ... the pdpca is not a driver or such software that will be used by
> an application, spooler, print-manager or the system; who can navigate to
> any predefined directory tree/structure. The pdpca is a tool; and, as such,
> to be used by individuals to test the driver; so my motivation was to make
> it easy to find but ....

In which case $bindir would be a good place.  The exact value of that
will depend on the options passed at build-time but is typically one
of /usr/bin or /usr/local/bin.

The idea here is that you have an $bindir/pdpca application that takes
options specifying the <dev> and <qual> from your spec to construct
the actual application's name, tests for its presence and starts it
passing along all unused options.  Normally you would have you PATH
set to something reasonable you you would just run it as:

  pdpca --dev <dev> --qual <qual> [other options]

Now nobody but $bindir/pdpca has to know the exact location of the
specific drivers.  If necessary, $bindir/pdpca can even be made to
look in a number of places.

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

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

[Petrie, Glen]

Thanks for your suggestions.

<...snip...>

> Normally you would have you PATH
> set to something reasonable you you would just run it as:
> 
>   pdpca --dev <dev> --qual <qual> [other options]
> 

[gwp] I considered this (and still like it) but I thought it would be
more/too complicated for user (of any kind) to figure out or know the <dev>
and the possible list of <qual's> since <qual's> could change with <dev>.
For code that will be used very seldom (once the printer is working, there
is little reason to test again), I thought having <dev> and <qual> right in
the file name would/could help the user (of any kind) select which pdpca to
try.  Example (which may not be correct but are shown for illustration)

Directory					command line
pdpca_guten_hp_laser_bw    or pdpca --dev guten --qual hp_laser_bw
				   or pdpca --dev guten --qual hp --qual
laser_bw
				   or pdpca --dev guten --qual hp,laser_bw
pdpca_guten_hp_laser_color
pdpca_guten_hp_laser_mfd
pdpca_guten_hp_inkjet_4color
pdpca_guten_hp_inkjet_6color
pdpca_guten_hp_inkjet_mfd
<... repeated for Epson, Canon, Lexmark, Xerox, and so forth under guten...>

pdpca_hp_laser_bw		   or     pdpca --dev hp --qual laser_bw
pdpca_hp_laser_color
pdpca_hp_laser_mfd
pdpca_hp_inkjet_4color
pdpca_hp_inkjet_6color
pdpca_hp_inkjet_mfd
<... repeated for Epson, Canon, Lexmark, Xerox, and so forth...>

Since I can not, at this time, begin to determine the number of
instantiations of pdpca there will be for every <dev> and every <qual>, I
thought the file name approach would be the best.  Maybe a pattern will
emerge; we will have to wait and see.

Scenario:  Help Desk (HD) help user (U) on the phone.

U:  My printer will not print my picture.
HD: What printer do you have?
U: A SuperX model 300 which is an inkjet printer.
HD: What application are you trying to print with.
U:  Guten
HD: Go to the /usr/bin/print/pdpca directory.
U: OK, got there
HD: Locate the file pdpca_guten_superx_inkjet
U: Ok located
HD: execute the file........

Or does the HD tell the user 

HD: type in pdpca --dev guten -qual superx,inkjet 300

Once someone knows the list of possible and then the specific <dev's> and
<qual's> it is pretty easy either way but if the HD did not know that info
he could have

HD: Go to the /usr/bin/print/pdpca directory.
HD: look for a file called pdpca_guten
U: found a bunch of them
HD: Is there file or files with superx in the name
U: yes
HD: Is there a file with inkjet in the name
U: No
HD: is there a file with generic in the name
U: yes
HD: execute the following pdpca_guten_superx_generic -s 300
U: It says the superX Model 300 is supported
HD: now execute pdpca_guten_superx_generic 300

So, my reasoning was .....

Is it easier for an end user (which is one of the target users) to navigate
a directory list with files containing the <dev> and <qual's> or read
instructions on what possible <dev> and <qual> to use.  Overall, would
suspect that the navigating will be easier.

Anyway, that was my reasoning I used to create the specification.   My next
goal was to find a directory that would be easy to locate by the HD and/or
user.

p.s.  dev looks like developer and device (we could pick a better word if
the decision is to go with a scheme as you suggest).  Which did you mean?

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

[Petrie, Glen]

A thought I did not complete in the last email is the directory structure
for pdpca.  With in the $bindir/pdpca directory, do we ...

1.)  Have no sub directories for the pdpca files
2.)  Have subdirectories based on <dev>

I actually like number '1.)'.  The first reason is that I believe that <dev>
will start having sub-dir, with more sub-dir, with more sub-dir etc..  I
find this to be a pain-in-neck when I am trying to locate something of the
nature of the pdpca.  It is ok for the <dev> but not typically anyone else.
Another advantage of '1.)' is there can never be two files with the same
filename.  This will prevent bad naming or improper naming by various
independent developing parties.



> -----Original Message-----
> From: Petrie, Glen
> Sent: Friday, November 09, 2007 8:11 AM
> To: Olaf Meeuwissen; Petrie, Glen
> Cc: printing-architecture@lists.freestandards.org; printing-
> summit@lists.linux-foundation.org
> Subject: RE: [Printing-architecture] RE: [Printing-summit] RE: where is th
> e info on driver directories
> 
> Thanks for your suggestions.
> 
> <...snip...>
> 
> > Normally you would have you PATH
> > set to something reasonable you you would just run it as:
> >
> >   pdpca --dev <dev> --qual <qual> [other options]
> >
> 
> [gwp] I considered this (and still like it) but I thought it would be
> more/too complicated for user (of any kind) to figure out or know the
> <dev> and the possible list of <qual's> since <qual's> could change with
> <dev>.    For code that will be used very seldom (once the printer is
> working, there is little reason to test again), I thought having <dev> and
> <qual> right in the file name would/could help the user (of any kind)
> select which pdpca to try.  Example (which may not be correct but are
> shown for illustration)
> 
> Directory					command line
> pdpca_guten_hp_laser_bw    or pdpca --dev guten --qual hp_laser_bw
> 				   or pdpca --dev guten --qual hp --qual
laser_bw
> 				   or pdpca --dev guten --qual hp,laser_bw
> pdpca_guten_hp_laser_color
> pdpca_guten_hp_laser_mfd
> pdpca_guten_hp_inkjet_4color
> pdpca_guten_hp_inkjet_6color
> pdpca_guten_hp_inkjet_mfd
> <... repeated for Epson, Canon, Lexmark, Xerox, and so forth under
> guten...>
> 
> pdpca_hp_laser_bw		   or     pdpca --dev hp --qual laser_bw
> pdpca_hp_laser_color
> pdpca_hp_laser_mfd
> pdpca_hp_inkjet_4color
> pdpca_hp_inkjet_6color
> pdpca_hp_inkjet_mfd
> <... repeated for Epson, Canon, Lexmark, Xerox, and so forth...>
> 
> Since I can not, at this time, begin to determine the number of
> instantiations of pdpca there will be for every <dev> and every <qual>, I
> thought the file name approach would be the best.  Maybe a pattern will
> emerge; we will have to wait and see.
> 
> Scenario:  Help Desk (HD) help user (U) on the phone.
> 
> U:  My printer will not print my picture.
> HD: What printer do you have?
> U: A SuperX model 300 which is an inkjet printer.
> HD: What application are you trying to print with.
> U:  Guten
> HD: Go to the /usr/bin/print/pdpca directory.
> U: OK, got there
> HD: Locate the file pdpca_guten_superx_inkjet
> U: Ok located
> HD: execute the file........
> 
> Or does the HD tell the user
> 
> HD: type in pdpca --dev guten -qual superx,inkjet 300
> 
> Once someone knows the list of possible and then the specific <dev's> and
> <qual's> it is pretty easy either way but if the HD did not know that info
> he could have
> 
> HD: Go to the /usr/bin/print/pdpca directory.
> HD: look for a file called pdpca_guten
> U: found a bunch of them
> HD: Is there file or files with superx in the name
> U: yes
> HD: Is there a file with inkjet in the name
> U: No
> HD: is there a file with generic in the name
> U: yes
> HD: execute the following pdpca_guten_superx_generic -s 300
> U: It says the superX Model 300 is supported
> HD: now execute pdpca_guten_superx_generic 300
> 
> So, my reasoning was .....
> 
> Is it easier for an end user (which is one of the target users) to
> navigate a directory list with files containing the <dev> and <qual's> or
> read instructions on what possible <dev> and <qual> to use.  Overall,
> would suspect that the navigating will be easier.
> 
> Anyway, that was my reasoning I used to create the specification.   My
> next goal was to find a directory that would be easy to locate by the HD
> and/or user.
> 
> p.s.  dev looks like developer and device (we could pick a better word if
> the decision is to go with a scheme as you suggest).  Which did you mean?

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

[Olaf Meeuwissen]

"Petrie, Glen" <glen.petrie@eitc.epson.com> writes:

> Thanks for your suggestions.
>
> <...snip...>
>
>> Normally you would have you PATH
>> set to something reasonable you you would just run it as:
>> 
>>   pdpca --dev <dev> --qual <qual> [other options]
>> 
>
> [gwp] I considered this (and still like it) but I thought it would be
> more/too complicated for user (of any kind) to figure out or know the <dev>
> and the possible list of <qual's> since <qual's> could change with <dev>.
> [snip]
>
> Scenario:  Help Desk (HD) help user (U) on the phone.
>
> U:  My printer will not print my picture.
> HD: What printer do you have?
> U: A SuperX model 300 which is an inkjet printer.
> HD: What application are you trying to print with.
> U:  Guten
> HD: Go to the /usr/bin/print/pdpca directory.
> U: OK, got there
> HD: Locate the file pdpca_guten_superx_inkjet
> U: Ok located
> HD: execute the file........
>
> Or does the HD tell the user 
>
> HD: type in pdpca --dev guten -qual superx,inkjet 300
>
> Once someone knows the list of possible and then the specific <dev's> and
> <qual's> it is pretty easy either way but if the HD did not know that info
> he could have
>
> HD: Go to the /usr/bin/print/pdpca directory.
> HD: look for a file called pdpca_guten
> U: found a bunch of them
> HD: Is there file or files with superx in the name
> U: yes
> HD: Is there a file with inkjet in the name
> U: No
> HD: is there a file with generic in the name
> U: yes
> HD: execute the following pdpca_guten_superx_generic -s 300
> U: It says the superX Model 300 is supported
> HD: now execute pdpca_guten_superx_generic 300
>
> So, my reasoning was .....
>
> Is it easier for an end user (which is one of the target users) to navigate
> a directory list with files containing the <dev> and <qual's> or read
> instructions on what possible <dev> and <qual> to use.  Overall, would
> suspect that the navigating will be easier.

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?

> Anyway, that was my reasoning I used to create the specification.   My next
> goal was to find a directory that would be easy to locate by the HD and/or
> user.

With a single program in an established place for user programs, all
you have to do is run the command with the right option(s).  Neither
user nor HD has to know any locations in the file system.  Locations
could even change transparently without the need to retrain HD staff
provided the pdpca utility is updated accordingly.

> p.s.  dev looks like developer and device (we could pick a better word if
> the decision is to go with a scheme as you suggest).  Which did you mean?

Actually, I'd vote for --supplier.
FWIW, manufacturer, developer and supplier are three different hats.
It just so happens that there's usually only one or two heads wearing
them.

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

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

[Olaf Meeuwissen]

"Petrie, Glen" <glen.petrie@eitc.epson.com> writes:

> A thought I did not complete in the last email is the directory structure
> for pdpca.  With in the $bindir/pdpca directory, do we ...
>
> 1.)  Have no sub directories for the pdpca files
> 2.)  Have subdirectories based on <dev>
>
> I actually like number '1.)'.  The first reason is that I believe that <dev>
> will start having sub-dir, with more sub-dir, with more sub-dir etc..  I
> find this to be a pain-in-neck when I am trying to locate something of the
> nature of the pdpca.  It is ok for the <dev> but not typically anyone else.

Then have a tool locate it for you, as per my previous mail.

> Another advantage of '1.)' is there can never be two files with the same
> filename.  This will prevent bad naming or improper naming by various
> independent developing parties.

Just put the driver specific tool with the rest of the driver, that is
somewhere below /opt/<supplier>, and have the LSB DDK add the links to
the right place.  As it does now already for everything else.

It's up to the <supplier> to make sure there are no conflicts in their
little piece of the file system.  Personally, I'd suggest following
the conventions of the GNU people modulo --prefix=/opt/<supplier>, so
your driver specific tools will probably live in /opt/<supplier>/bin/
or /opt/<supplier>/lib/.

Hope this helps,

>> -----Original Message-----
>> [snip]
-- 
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

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

[Till Kamppeter]

Olaf Meeuwissen wrote:
> "Petrie, Glen" <glen.petrie@eitc.epson.com> writes:
> 
>> A thought I did not complete in the last email is the directory structure
>> for pdpca.  With in the $bindir/pdpca directory, do we ...
>>
>> 1.)  Have no sub directories for the pdpca files
>> 2.)  Have subdirectories based on <dev>
>>
>> I actually like number '1.)'.  The first reason is that I believe that <dev>
>> will start having sub-dir, with more sub-dir, with more sub-dir etc..  I
>> find this to be a pain-in-neck when I am trying to locate something of the
>> nature of the pdpca.  It is ok for the <dev> but not typically anyone else.
> 
> Then have a tool locate it for you, as per my previous mail.
> 
>> Another advantage of '1.)' is there can never be two files with the same
>> filename.  This will prevent bad naming or improper naming by various
>> independent developing parties.
> 
> Just put the driver specific tool with the rest of the driver, that is
> somewhere below /opt/<supplier>, and have the LSB DDK add the links to
> the right place.  As it does now already for everything else.
> 
> It's up to the <supplier> to make sure there are no conflicts in their
> little piece of the file system.  Personally, I'd suggest following
> the conventions of the GNU people modulo --prefix=/opt/<supplier>, so
> your driver specific tools will probably live in /opt/<supplier>/bin/
> or /opt/<supplier>/lib/.
> 

This is also how I would do it in the distro-independent packages. The 
LSB DDK already adds /opt/<supplier>/bin/ and /opt/<supplier>/sbin/ to 
the $PATH, so a test tool can started by the user like any auxiliary 
utility (as ink level checkers, etc.).

    Till

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

[Petrie, Glen]

< ... 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.  

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.   I can
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).

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).   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). 

< ... 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. 

----- 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.

----- 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.

----- 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

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

[Olaf Meeuwissen]

I've got only very little time ...

"Petrie, Glen" <glen.petrie@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

RE: [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@avasys.jp]
> Sent: Monday, November 12, 2007 4:11 PM
> To: Petrie, Glen
> Cc: Olaf Meeuwissen; printing-architecture@lists.freestandards.org;
> printing-summit@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@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