Re: [Printing-architecture] Required prefixes for symbols in new OP specs

Re: [Printing-architecture] Required prefixes for symbols in new OP specs

[McDonald, Ira]

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

-----Original Message-----
From: printing-architecture-bounces@lists.freestandards.org
[mailto:printing-architecture-bounces@lists.freestandards.org]On Behalf
Of TORATANI Yasumasa
Sent: Wednesday, February 07, 2007 12:19 AM
To: McDonald, Ira
Cc: printing-architecture@lists.freestandards.org
Subject: Re: [Printing-architecture] Required prefixes for symbols in
new OP specs


Hi,

I think we should clarify a new naming rule for functions,
enums, typedefs, etc... but we can just convert the former
FSG OpenPrinting naming rule we usually used to use "op"
or "OP" in stead of "fsg" or "FSG".

According to the JTAPI spec, we can re-define the rule as;

Functions:
  "op" + "[mod]" + "[Name]"
  * All "mod" character must be lowercase.
  * "Name" characters can be uppercase or lowercase, but first
     "Name" character must be uppercase.
  example)  opmodOpen( ... );

Enums:
  "OP" + "[MOD]" + "_" + "[NAME]"
  * All alphabetic characters must be uppercase.
  example)  OPMOD_OK

Types:
  "op" + "[mod]" + "_" + "[Name]"
  example)  opmod_return_code_t

Comment?

TORATANI.

On Tue, 6 Feb 2007 09:04:32 -0800 
"McDonald, Ira" <imcdonald@sharplabs.com> wrote:

> Hi,
> 
> Per our discussion at yesterday's Linux Foundation
> Open Printing Steering Committee teleconference.
> 
> Effective immediately, future Open Printing module 
> specs will use prefixes for external identifiers of
> the form:
> 
>   "op" + "[mod]" + "_"
> 
> where:
> 
>   mod == module abbreviation (e.g., "pcm")
> 
> instead of the previous "fsg" + "[mod]" + "_" (e.g.,
> "fsgjt_" in OP Job Ticket API).  But, we will NEVER
> change the "fsgxx_" prefix in adopted and published
> OP specs (for stability and backwards compatibility).
> 
> This change in standard OP prefixes will hopefully
> future-proof our APIs against future organizational
> changes and renames (e.g., FSG --> Linux Foundation).
> 
> Cheers,
> - Ira
> 
> 
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Blue Roof Music / High North Inc
> PO Box 221  Grand Marais, MI  49839
> phone: +1-906-494-2434
> email: imcdonald@sharplabs.com
> 
> -- 
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.17.28/672 - Release Date: 2/6/2007
> 10:22 AM
>  
> 
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.freestandards.org
> http://lists.freestandards.org/mailman/listinfo/printing-architecture

-----------------------------------------
TORATANI Yasumasa
Software Engineering Dept.23
Platform Technology Development Headquarters, CANON INC.

_______________________________________________
Printing-architecture mailing list
Printing-architecture@lists.freestandards.org
http://lists.freestandards.org/mailman/listinfo/printing-architecture

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.30/674 - Release Date: 2/7/2007
3:33 PM
 

Re: [Printing-architecture] Required prefixes for symbols in new OP specs

[Michael Sweet]

Norm Jacobs wrote:
 > ...
 > FWIW, this will work for applications linking with libraries 
exporting the old interface, but will not solve the problem for loadable 
modules that are dlopen()'d and dlsym()'d.  In those cases, the shim 
method you
 > ...

Do we even need to worry about this?  Assuming a developer uses this
method, they can still use the old names (which are documented in the
specs) without relying on platform-specific weak linking support.

Regardless, the only time I can see using dlopen() or dlsym() is for
testing for newer versions of libraries at run-time, which will be
using the new naming conventions anyway, right?

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Publishing Software        http://www.easysw.com

Re: [Printing-architecture] Required prefixes for symbols in new OP specs

[Norm Jacobs]

Michael Sweet wrote:
> McDonald, Ira wrote:
>   
>> Hi Olaf,
>>
>> What prefix (if any) are you currently using for PCM
>> functions, variables, and constants?
>>
>> There was a strong concensus at the OP Steering Committee
>> meeting this Monday that we should NOT use 'fsg' as the
>> beginning of the prefix for any specs that are not yet 
>> formally approved.
>>
>> Relative to Michael Sweet's comment about #define to 
>> make consistent prefix (e.g., in existing JTAPI C headers),
>> that may or may not fix problems of linkers - dynamic
>> linking in Linux appears rather limited relative to some
>> other platforms - my impression.
>>     
>
> This isn't an issue - you define the new prefix to point to
> the old name, e.g.:
>
>      #define opjt_foo fsgjt_foo
>
> The compiler and linker use the old names, as before.  The
> developer can use the new names and be none the wiser.
>   
FWIW, this will work for applications linking with libraries exporting 
the old interface, but will not solve the problem for loadable modules 
that are dlopen()'d and dlsym()'d.  In those cases, the shim method you 
mention below will work or using weak symbol associations in the 
loadable module will work.  the weak symbols have the advantage of not 
introducing any additional calling overhead.

This can be done with

#pragma weak   new_symbol_name = old_symbol_name

Of course if we don't migrate to new names, none of this matters.

          -Norm

> Another method is to provide shim functions for all of the
> old names, calling the new names.  That has a performance
> impact, however, so I recommend using #define instead.
>
> Enumerations and other constants can be done the same way...
>   

Re: [Printing-architecture] Required prefixes for symbols in new OP specs

[TORATANI Yasumasa]

Hi, 

On Thu, 08 Feb 2007 08:43:26 +0900
Olaf Meeuwissen <olaf.meeuwissen@avasys.jp> wrote:

(snip)

> A naming standard should cover (at least) everything that is part of
> all the public OpenPrinting APIs.  That's is, everything that goes
> into the header file(s) that our API users include.
> 
> Hmm, come to think of it, I think it should also cover the file names
> themselves.  Do they get an "op" prefix, so you get oppcm.h an opjt.h
> for example, or do they go into an op, openprinting or even an
> OpenPrinting directory?
> # What about case insensitive file systems?

On page 13 of the JTAPI document, it already defines the header file
name, such as, "fsgjt.h", "fsgjt_attribute.h", etc. I believe we can use
the similar naming rule, for instance, "opmod.h", opmod_attribute.h", etc
which can keep consistency with the case insensitive file systems.

-----------------------------------------
TORATANI Yasumasa
Software Engineering Dept.23
Platform Technology Development Headquarters, CANON INC.

Re: [Printing-architecture] Required prefixes for symbols in new OP specs

[Olaf Meeuwissen]

"McDonald, Ira" <imcdonald@sharplabs.com> writes:

> Hi,
>
> Oops - I hit SEND accidentally a minute ago.
>
> Yes - I like your proposed usage (consistent with
> JTAPI C headers).

For the publicly visible parts of the PCM API this proposed usage is
exactly what we are using at the moment, modulo a `sed 's/op/fsg/g'`.
If we decide to switch to "op" instead of "fsg", it's not a big issue
now because we haven't released anything yet.

For functions we additionally use CamelCase for the "Name" part (much
as I don't like this :-).  For all types we also consistently attach a
"_t" at the end although I believe this treads in the POSIX reserved
name space.  Sorry, don't have a ref handy.

For non-public API that is used by various parts of our implementation
(let's call it the protected API), we informally stick to a convention
where we drop the "fsg" prefix, so you get pcmCamelCase for functions
etc.

> I agree that a naming standard should go deeper
> than just the external function names.

A naming standard should cover (at least) everything that is part of
all the public OpenPrinting APIs.  That's is, everything that goes
into the header file(s) that our API users include.

Hmm, come to think of it, I think it should also cover the file names
themselves.  Do they get an "op" prefix, so you get oppcm.h an opjt.h
for example, or do they go into an op, openprinting or even an
OpenPrinting directory?
# What about case insensitive file systems?

Just my two yen.

> Cheers,
> - Ira
>
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Blue Roof Music / High North Inc
> PO Box 221  Grand Marais, MI  49839
> phone: +1-906-494-2434
> email: imcdonald@sharplabs.com
>
> -----Original Message-----
> From: printing-architecture-bounces@lists.freestandards.org
> [mailto:printing-architecture-bounces@lists.freestandards.org]On Behalf
> Of TORATANI Yasumasa
> Sent: Wednesday, February 07, 2007 12:19 AM
> To: McDonald, Ira
> Cc: printing-architecture@lists.freestandards.org
> Subject: Re: [Printing-architecture] Required prefixes for symbols in
> new OP specs
>
>
> Hi,
>
> I think we should clarify a new naming rule for functions,
> enums, typedefs, etc... but we can just convert the former
> FSG OpenPrinting naming rule we usually used to use "op"
> or "OP" in stead of "fsg" or "FSG".
>
> According to the JTAPI spec, we can re-define the rule as;
>
> Functions:
>   "op" + "[mod]" + "[Name]"
>   * All "mod" character must be lowercase.
>   * "Name" characters can be uppercase or lowercase, but first
>      "Name" character must be uppercase.
>   example)  opmodOpen( ... );
>
> Enums:
>   "OP" + "[MOD]" + "_" + "[NAME]"
>   * All alphabetic characters must be uppercase.
>   example)  OPMOD_OK
>
> Types:
>   "op" + "[mod]" + "_" + "[Name]"
>   example)  opmod_return_code_t
>
> Comment?
>
> TORATANI.
>
> On Tue, 6 Feb 2007 09:04:32 -0800 
> "McDonald, Ira" <imcdonald@sharplabs.com> wrote:
>
>> Hi,
>> 
>> Per our discussion at yesterday's Linux Foundation
>> Open Printing Steering Committee teleconference.
>> 
>> Effective immediately, future Open Printing module 
>> specs will use prefixes for external identifiers of
>> the form:
>> 
>>   "op" + "[mod]" + "_"
>> 
>> where:
>> 
>>   mod == module abbreviation (e.g., "pcm")
>> 
>> instead of the previous "fsg" + "[mod]" + "_" (e.g.,
>> "fsgjt_" in OP Job Ticket API).  But, we will NEVER
>> change the "fsgxx_" prefix in adopted and published
>> OP specs (for stability and backwards compatibility).
>> 
>> This change in standard OP prefixes will hopefully
>> future-proof our APIs against future organizational
>> changes and renames (e.g., FSG --> Linux Foundation).
>> 
>> Cheers,
>> - Ira
>> 
>> 
>> Ira McDonald (Musician / Software Architect)
>> Chair - Linux Foundation Open Printing WG
>> Blue Roof Music / High North Inc
>> PO Box 221  Grand Marais, MI  49839
>> phone: +1-906-494-2434
>> email: imcdonald@sharplabs.com
>> 
>> -- 
>> No virus found in this outgoing message.
>> Checked by AVG Free Edition.
>> Version: 7.5.432 / Virus Database: 268.17.28/672 - Release Date: 2/6/2007
>> 10:22 AM
>>  
>> 
>> _______________________________________________
>> Printing-architecture mailing list
>> Printing-architecture@lists.freestandards.org
>> http://lists.freestandards.org/mailman/listinfo/printing-architecture
>
> -----------------------------------------
> TORATANI Yasumasa
> Software Engineering Dept.23
> Platform Technology Development Headquarters, CANON INC.
>
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.freestandards.org
> http://lists.freestandards.org/mailman/listinfo/printing-architecture
>
> -- 
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.17.30/674 - Release Date: 2/7/2007
> 3:33 PM
>  
>
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.freestandards.org
> http://lists.freestandards.org/mailman/listinfo/printing-architecture
>

-- 
Olaf Meeuwissen                          EPSON AVASYS Corporation, SE1
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] Required prefixes for symbols in new OP specs

[Olaf Meeuwissen]

"McDonald, Ira" <imcdonald@sharplabs.com> writes:

> Hi Olaf,
>
> What prefix (if any) are you currently using for PCM
> functions, variables, and constants?

We use "fsgpcm" following the examples that JTAPI set.  I'll be
getting back on this in your reply to Yasumasu Toratani.

> There was a strong concensus at the OP Steering Committee
> meeting this Monday that we should NOT use 'fsg' as the
> beginning of the prefix for any specs that are not yet 
> formally approved.

I don't mind changing it.  It's mostly just pulling everthing through
sed 's/fsg/op/g' as we haven't publicly released any code yet ;-)

> [snip]

-- 
Olaf Meeuwissen                          EPSON AVASYS Corporation, SE1
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] Required prefixes for symbols in new OP specs

[Michael Sweet]

McDonald, Ira wrote:
> Hi Olaf,
> 
> What prefix (if any) are you currently using for PCM
> functions, variables, and constants?
> 
> There was a strong concensus at the OP Steering Committee
> meeting this Monday that we should NOT use 'fsg' as the
> beginning of the prefix for any specs that are not yet 
> formally approved.
> 
> Relative to Michael Sweet's comment about #define to 
> make consistent prefix (e.g., in existing JTAPI C headers),
> that may or may not fix problems of linkers - dynamic
> linking in Linux appears rather limited relative to some
> other platforms - my impression.

This isn't an issue - you define the new prefix to point to
the old name, e.g.:

     #define opjt_foo fsgjt_foo

The compiler and linker use the old names, as before.  The
developer can use the new names and be none the wiser.

Another method is to provide shim functions for all of the
old names, calling the new names.  That has a performance
impact, however, so I recommend using #define instead.

Enumerations and other constants can be done the same way...

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com

Re: [Printing-architecture] Required prefixes for symbols in new OP specs

[McDonald, Ira]

Hi,

Oops - I hit SEND accidentally a minute ago.

Yes - I like your proposed usage (consistent with
JTAPI C headers).

I agree that a naming standard should go deeper
than just the external function names.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

-----Original Message-----
From: printing-architecture-bounces@lists.freestandards.org
[mailto:printing-architecture-bounces@lists.freestandards.org]On Behalf
Of TORATANI Yasumasa
Sent: Wednesday, February 07, 2007 12:19 AM
To: McDonald, Ira
Cc: printing-architecture@lists.freestandards.org
Subject: Re: [Printing-architecture] Required prefixes for symbols in
new OP specs


Hi,

I think we should clarify a new naming rule for functions,
enums, typedefs, etc... but we can just convert the former
FSG OpenPrinting naming rule we usually used to use "op"
or "OP" in stead of "fsg" or "FSG".

According to the JTAPI spec, we can re-define the rule as;

Functions:
  "op" + "[mod]" + "[Name]"
  * All "mod" character must be lowercase.
  * "Name" characters can be uppercase or lowercase, but first
     "Name" character must be uppercase.
  example)  opmodOpen( ... );

Enums:
  "OP" + "[MOD]" + "_" + "[NAME]"
  * All alphabetic characters must be uppercase.
  example)  OPMOD_OK

Types:
  "op" + "[mod]" + "_" + "[Name]"
  example)  opmod_return_code_t

Comment?

TORATANI.

On Tue, 6 Feb 2007 09:04:32 -0800 
"McDonald, Ira" <imcdonald@sharplabs.com> wrote:

> Hi,
> 
> Per our discussion at yesterday's Linux Foundation
> Open Printing Steering Committee teleconference.
> 
> Effective immediately, future Open Printing module 
> specs will use prefixes for external identifiers of
> the form:
> 
>   "op" + "[mod]" + "_"
> 
> where:
> 
>   mod == module abbreviation (e.g., "pcm")
> 
> instead of the previous "fsg" + "[mod]" + "_" (e.g.,
> "fsgjt_" in OP Job Ticket API).  But, we will NEVER
> change the "fsgxx_" prefix in adopted and published
> OP specs (for stability and backwards compatibility).
> 
> This change in standard OP prefixes will hopefully
> future-proof our APIs against future organizational
> changes and renames (e.g., FSG --> Linux Foundation).
> 
> Cheers,
> - Ira
> 
> 
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Blue Roof Music / High North Inc
> PO Box 221  Grand Marais, MI  49839
> phone: +1-906-494-2434
> email: imcdonald@sharplabs.com
> 
> -- 
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.17.28/672 - Release Date: 2/6/2007
> 10:22 AM
>  
> 
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.freestandards.org
> http://lists.freestandards.org/mailman/listinfo/printing-architecture

-----------------------------------------
TORATANI Yasumasa
Software Engineering Dept.23
Platform Technology Development Headquarters, CANON INC.

_______________________________________________
Printing-architecture mailing list
Printing-architecture@lists.freestandards.org
http://lists.freestandards.org/mailman/listinfo/printing-architecture

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.30/674 - Release Date: 2/7/2007
3:33 PM
 

Re: [Printing-architecture] Required prefixes for symbols in new OP specs

[McDonald, Ira]

Hi Olaf,

What prefix (if any) are you currently using for PCM
functions, variables, and constants?

There was a strong concensus at the OP Steering Committee
meeting this Monday that we should NOT use 'fsg' as the
beginning of the prefix for any specs that are not yet 
formally approved.

Relative to Michael Sweet's comment about #define to 
make consistent prefix (e.g., in existing JTAPI C headers),
that may or may not fix problems of linkers - dynamic
linking in Linux appears rather limited relative to some
other platforms - my impression.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

-----Original Message-----
From: Olaf Meeuwissen [mailto:olaf.meeuwissen@avasys.jp]
Sent: Tuesday, February 06, 2007 7:59 PM
To: McDonald, Ira
Cc: printing-architecture@lists.freestandards.org
Subject: Re: [Printing-architecture] Required prefixes for symbols in
new OP specs


Hi Ira,

"McDonald, Ira" <imcdonald@sharplabs.com> writes:

> Effective immediately, future Open Printing module 
> specs will use prefixes for external identifiers of
> the form:
>
>   "op" + "[mod]" + "_"
>
> where:
>
>   mod == module abbreviation (e.g., "pcm")

I just want to make sure that for PCM we _have_ to use the "oppcm_"
prefix before I convert all the code and docs we are hacking on.

Thanks,
-- 
Olaf Meeuwissen                          EPSON AVASYS Corporation, SE1
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

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.30/674 - Release Date: 2/7/2007
3:33 PM
 

Re: [Printing-architecture] Required prefixes for symbols in new OP specs

[TORATANI Yasumasa]

Hi,

I think we should clarify a new naming rule for functions,
enums, typedefs, etc... but we can just convert the former
FSG OpenPrinting naming rule we usually used to use "op"
or "OP" in stead of "fsg" or "FSG".

According to the JTAPI spec, we can re-define the rule as;

Functions:
  "op" + "[mod]" + "[Name]"
  * All "mod" character must be lowercase.
  * "Name" characters can be uppercase or lowercase, but first
     "Name" character must be uppercase.
  example)  opmodOpen( ... );

Enums:
  "OP" + "[MOD]" + "_" + "[NAME]"
  * All alphabetic characters must be uppercase.
  example)  OPMOD_OK

Types:
  "op" + "[mod]" + "_" + "[Name]"
  example)  opmod_return_code_t

Comment?

TORATANI.

On Tue, 6 Feb 2007 09:04:32 -0800 
"McDonald, Ira" <imcdonald@sharplabs.com> wrote:

> Hi,
> 
> Per our discussion at yesterday's Linux Foundation
> Open Printing Steering Committee teleconference.
> 
> Effective immediately, future Open Printing module 
> specs will use prefixes for external identifiers of
> the form:
> 
>   "op" + "[mod]" + "_"
> 
> where:
> 
>   mod == module abbreviation (e.g., "pcm")
> 
> instead of the previous "fsg" + "[mod]" + "_" (e.g.,
> "fsgjt_" in OP Job Ticket API).  But, we will NEVER
> change the "fsgxx_" prefix in adopted and published
> OP specs (for stability and backwards compatibility).
> 
> This change in standard OP prefixes will hopefully
> future-proof our APIs against future organizational
> changes and renames (e.g., FSG --> Linux Foundation).
> 
> Cheers,
> - Ira
> 
> 
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Blue Roof Music / High North Inc
> PO Box 221  Grand Marais, MI  49839
> phone: +1-906-494-2434
> email: imcdonald@sharplabs.com
> 
> -- 
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.17.28/672 - Release Date: 2/6/2007
> 10:22 AM
>  
> 
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.freestandards.org
> http://lists.freestandards.org/mailman/listinfo/printing-architecture

-----------------------------------------
TORATANI Yasumasa
Software Engineering Dept.23
Platform Technology Development Headquarters, CANON INC.

Re: [Printing-architecture] Required prefixes for symbols in new OP specs

[Olaf Meeuwissen]

Hi Ira,

"McDonald, Ira" <imcdonald@sharplabs.com> writes:

> Effective immediately, future Open Printing module 
> specs will use prefixes for external identifiers of
> the form:
>
>   "op" + "[mod]" + "_"
>
> where:
>
>   mod == module abbreviation (e.g., "pcm")

I just want to make sure that for PCM we _have_ to use the "oppcm_"
prefix before I convert all the code and docs we are hacking on.

Thanks,
-- 
Olaf Meeuwissen                          EPSON AVASYS Corporation, SE1
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

[Printing-architecture] Required prefixes for symbols in new OP specs

[McDonald, Ira]

Hi,

Per our discussion at yesterday's Linux Foundation
Open Printing Steering Committee teleconference.

Effective immediately, future Open Printing module 
specs will use prefixes for external identifiers of
the form:

  "op" + "[mod]" + "_"

where:

  mod == module abbreviation (e.g., "pcm")

instead of the previous "fsg" + "[mod]" + "_" (e.g.,
"fsgjt_" in OP Job Ticket API).  But, we will NEVER
change the "fsgxx_" prefix in adopted and published
OP specs (for stability and backwards compatibility).

This change in standard OP prefixes will hopefully
future-proof our APIs against future organizational
changes and renames (e.g., FSG --> Linux Foundation).

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.28/672 - Release Date: 2/6/2007
10:22 AM