Re: [Printing-architecture] Embedded Client Thin-Thread: Initial Information

Re: [Printing-architecture] Embedded Client Thin-Thread: Initial Information

[Petrie, Glen]

Ira,

I really don't want to beat-the-horse-to-death, but, since any activity we
take on requires a lot of time and effort, I would like to hash it out now.

Competition?  Or proving the LFOP architecture?  Don't get me wrong I think
a thin-thread embedded-client would be a great solution and something that I
believe is needed.  However, (there is that 'however' again) what is the
LFOP's ultimate goal?  Is our goal to provide solutions or provide a
standard print architecture (including API's and properties, etc.)
independent of environment?  If it is latter, then this means, independent
of environment, "we [need to] fix API function names and property names and
value names into one standard namespace".  So, the question becomes "what is
the path to the LFOP "standard print architecture".  Do we start with the
desktop or the embedded?  Embedded has a smaller overall scope compared to
desktop; that is, do we start with something "small" and migrate to larger;
remembering the goal is an environment independent architecture?  Then we
show or document how to migrate existing API standards to be coherent with
the LFOP "standard print architecture".  The alternative is to start with
the existing API standards in a desktop environment; then apply the same
approach of migration to achieve the same goal.

Another question to those who authored the existing API standards; "Would
you be willing to migrate your solution to a LFOP standard print
architecture?".  If individuals or groups answer no; then I would like to
have more discussion on "what are the LFOP goals and, thus, our activities".
As one of the authors of the JTAPI, I would be favor of a migration to a
"standard print architecture" simply because a standard architecture would
provide unification and coherence. (For JTAPI, the changes would be
"cosmetic name fixups" only be I believe it the most comprehensive base we
have at this time.)

If CUPS or another deployed solution has a functional, scalable and industry
accepted architecture; then, we should adopt their architecture; thus, I
would like to have more discussion on "what are the LFOP goals and, thus,
our activities."  For example, the activity could be "how to create an
embedded-client solution based on their architecture".   If CUPS does not an
industry accepted architecture; would CUPS be willing to migrate to a
standard print architecture?

glen  

-----Original Message-----
From: Ira McDonald [mailto:blueroofmusic@gmail.com] 
Sent: Friday, May 18, 2007 12:15 PM
To: Petrie, Glen; printing-architecture@lists.freestandards.org; Ira
McDonald
Subject: Re: [Printing-architecture] Embedded Client Thin-Thread: Initial
Information

Hi Glen,

I think Desktop Clients is fatal - no traction there to make changes
(too much competition from CUPS and other deployed solutions).

Let's stick to Embedded Client Thin Thread as a target.

On reflection, let's assume we fix API function names and property
names and value names into one standard namespace.  And then
we revise the component API standards (PAPI, JTAPI, OPVP, etc.)
accordingly subsequently (the following year)

Cheers,
- Ira

Re: [Printing-architecture] Embedded Client Thin-Thread: Initial Information

[Michael Sweet]

Petrie, Glen wrote:
> ...
> If CUPS or another deployed solution has a functional, scalable and industry
> accepted architecture; then, we should adopt their architecture; thus, I
> would like to have more discussion on "what are the LFOP goals and, thus,
> our activities."  For example, the activity could be "how to create an
> embedded-client solution based on their architecture".   If CUPS does not an
> industry accepted architecture; would CUPS be willing to migrate to a
> standard print architecture?

I don't think we'd have a problem adding another ("emulated") API to
CUPS, much like the planned PAPI on CUPS implementation.  However,
it is extremely unlikely that we would convert CUPS itself to another
API since a) we'd have a fair amount of code to convert (with the
corresponding opportunities for breaking things) and b) the current
API works quite well.

As for the question of whether the CUPS API would be suitable for
embedded/thin clients, I don't see why it wouldn't be, especially
if you stick with the (tiny) subset used for LSB 3.2 plus the CUPS
1.3 streaming print API.

In my experience, the bigger issue will be printer drivers and
generation of PDL data, which will need to be closely tied to the
toolkit being used (e.g. Qt or GTK+ on top of Cairo) so that the
printed files can be printer-ready bitmap/vector data, PDF, or
PostScript.  This print data will most likely need to be streamed,
which may require some further changes in those toolkits...

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

Re: [Printing-architecture] Embedded Client Thin-Thread: Initial Information

[Petrie, Glen]

Ira, 

Follow up on the last note.  Assume we go to a thin-thread for a
desktop-client, then it makes more sense to have the authors of the API's,
SDK's write the thin-client versions.  Then others can write
architecture/thin-client elements not currently defined.

glen 


p.s. "QT core" should have been "QNX core"

-----Original Message-----
From: printing-architecture-bounces@lists.freestandards.org
[mailto:printing-architecture-bounces@lists.freestandards.org] On Behalf Of
Petrie, Glen
Sent: Friday, May 18, 2007 10:40 AM
To: printing-architecture@lists.freestandards.org
Subject: Re: [Printing-architecture] Embedded Client Thin-Thread:
InitialInformation

Ira,

I believe it is bit more than "cosmetic name fixups"!  I also don't believe
that an embedded-client will be implemented using Solaris or a standard
Linux distributions; maybe a QT core or some other Posix core.  Anyway, I
understand your point; however, (there is always has to be a however) I am
worried that gluing together the existing stuff "as is" will simple result
in too large of a code base to be practical for any embedded-clients.
Therefore, I suggest we need to move the thin-thread from embedded-clients
to desktop-clients.  I remember all the discussions and reasons we went to
embedded-clients but there will be less practical risks/issues if we now
target desktop-clients.  After that, we can see how it will fit in the
embedded-clients.  We can still the scope of a desktop-client.

glen

-----Original Message-----
From: Ira McDonald [mailto:blueroofmusic@gmail.com] 
Sent: Friday, May 18, 2007 10:20 AM
To: Petrie, Glen
Cc: printing-architecture@lists.freestandards.org
Subject: Re: [Printing-architecture] Embedded Client Thin-Thread: Initial
Information

Hi Glen,

I'm strongly opposed to the cosmetic name fixups.  PAPI has been
shipping in Solaris for years.  OPVP is shipping on most Linux
distributions.  It's unfortunate, but that's life.

Cheers,
- Ira

On 5/18/07, Petrie, Glen <glen.petrie@eitc.epson.com> wrote:
> All,
>
> Since I did not receive any "Comments?  Opinions?", I am not sure what the
> reaction was to the my note below.  I'll bet is was surprise to some but
> others know how I feel about coherence.
>
> So again, do we want to try the coherence path?  Yes I know is heresy,
> non-conventional and again the grain.  I know that others, including
myself,
> have put a lot work in their creations (API's, SDK's, actual code).
But....
> I think one of the powers of open source is to use the best from each and,
> in that way, create, especially for this case, a larger AND coherent
> solution.
>
> or
>
> Do we want to try the integration path?  Although this preserves the work
of
> the individuals, it is a integration and gluing approach for the larger
> solution.
>
> glen
>
> -----Original Message-----
> From: printing-architecture-bounces@lists.freestandards.org
> [mailto:printing-architecture-bounces@lists.freestandards.org] On Behalf
Of
> Petrie, Glen
> Sent: Wednesday, May 16, 2007 3:32 PM
> To: printing-architecture@lists.freestandards.org
> Subject: [Printing-architecture] Embedded Client Thin-Thread:
> InitialInformation
>
> All,
>
> I started reviewing the work I did last year.  It appears I took some
> liberties with things!!!! Ops!!!!
>
> The overall reasons for the changes I made was that I saw all of the OP
> API's with differing naming conventions and duplicated (and sometimes
> differing) definitions; which to me was/would-be very confusing to a
> developer.  I wanted to solve this without being in conflict with existing
> work.  So I took the approach of creating a new naming convention and
would
> remove any duplicate definitions.  To do that I decided to start with the
> variables (meaning) used in JTAPI as the base and migrate everything else
to
> a common and new naming convention.  To do this I
>
> 1. I renamed the JTAPI stuff to EPP_; followed by a three char; then a
> descriptor.
>
> for example: binding type when from
>
> typedef enum
> {
>    FSGJT_BD_NOT_SET = 0,
>    FSGJT_BD_NONE,
>    FSGJT_BD_CHANNEL,
>    FSGJT_BD_EDGE_GLUE,
>    FSGJT_BD_PERFECT,
>    FSGJT_BD_PLASTIC_COMB,
>    FSGJT_BD_RING,
>    FSGJT_BD_SPIRAL,
>    FSGJT_BD_STRIP,
>    FSGJT_BD_TAPE,
>    FSGJT_BD_THREAD_SEAL,
>    FSGJT_BD_VELO,
>    FSGJT_BD_WIRE_COMB
> } fsgjt_binding_type_t;
>
>
> to
> typedef enum {
>     EPP_BDT_NOT_SET = 0 ,
>     EPP_BDT_NONE        ,
>     EPP_BDT_CHANNEL     ,
>     EPP_BDT_EDGE_GLUE   ,
>     EPP_BDT_PERFECT     ,
>     EPP_BDT_PLASTIC_COMB,
>     EPP_BDT_RING        ,
>     EPP_BDT_SPIRAL      ,
>     EPP_BDT_STRIP       ,
>     EPP_BDT_TAPE        ,
>     EPP_BDT_THREAD_SEAL ,
>     EPP_BDT_VELO        ,
>     EPP_BDT_WIRE_COMB   ,
>     EPP_BDT_EOL         ,
>     EPP_BDT_EXT = EPP_EXTEN
> } EPP_BINDING_TYPE;
> #define EPP_BDT     EPP_BINDING_TYPE
>
> So the numerical value of each enum is the same but not the name!!!
>
>
> Because I was initially (and could still) provide on a DOS-like interface
> for the thin-thread, I needed a way to have a simple input mechanism for a
> job ticket; so
>
> 2. I created a job-ticket file format that is parsed directly into a
> job-ticket struct(s) I am using.
>
> No telling what other liberties I took!!!
>
>
> Right now, I am at a conflict weather to just keep going or restart.  The
> issue, to me, is one of overall and long term coherence.  If I keep going
> then the intent is to use the best of any open source code and create a
> coherent solution (both in naming and definition).  The alternative is to
> try plugging existing but distinct pieces together.  I am worried about
that
> the latter, since it may result in an amount (small or large) of "glue
code"
> and perhaps some disconnects.  I guess I believe that in the end a
developer
> would have to get and understand distinct pieces of codes and disconnected
> API's versus coherent set of API's
>
> Comments?  Opinions?
>
> glen
>
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.freestandards.org
> http://lists.freestandards.org/mailman/listinfo/printing-architecture
>
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.freestandards.org
> http://lists.freestandards.org/mailman/listinfo/printing-architecture
>


-- 
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: blueroofmusic@gmail.com

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

Re: [Printing-architecture] Embedded Client Thin-Thread: Initial Information

[Ira McDonald]

Hi Glen,

I think Desktop Clients is fatal - no traction there to make changes
(too much competition from CUPS and other deployed solutions).

Let's stick to Embedded Client Thin Thread as a target.

On reflection, let's assume we fix API function names and property
names and value names into one standard namespace.  And then
we revise the component API standards (PAPI, JTAPI, OPVP, etc.)
accordingly subsequently (the following year)

Cheers,
- Ira

On 5/18/07, Petrie, Glen <glen.petrie@eitc.epson.com> wrote:
> Ira,
>
> Follow up on the last note.  Assume we go to a thin-thread for a
> desktop-client, then it makes more sense to have the authors of the API's,
> SDK's write the thin-client versions.  Then others can write
> architecture/thin-client elements not currently defined.
>
> glen
>
>
> p.s. "QT core" should have been "QNX core"
>
> -----Original Message-----
> From: printing-architecture-bounces@lists.freestandards.org
> [mailto:printing-architecture-bounces@lists.freestandards.org] On Behalf Of
> Petrie, Glen
> Sent: Friday, May 18, 2007 10:40 AM
> To: printing-architecture@lists.freestandards.org
> Subject: Re: [Printing-architecture] Embedded Client Thin-Thread:
> InitialInformation
>
> Ira,
>
> I believe it is bit more than "cosmetic name fixups"!  I also don't believe
> that an embedded-client will be implemented using Solaris or a standard
> Linux distributions; maybe a QT core or some other Posix core.  Anyway, I
> understand your point; however, (there is always has to be a however) I am
> worried that gluing together the existing stuff "as is" will simple result
> in too large of a code base to be practical for any embedded-clients.
> Therefore, I suggest we need to move the thin-thread from embedded-clients
> to desktop-clients.  I remember all the discussions and reasons we went to
> embedded-clients but there will be less practical risks/issues if we now
> target desktop-clients.  After that, we can see how it will fit in the
> embedded-clients.  We can still the scope of a desktop-client.
>
> glen
>
> -----Original Message-----
> From: Ira McDonald [mailto:blueroofmusic@gmail.com]
> Sent: Friday, May 18, 2007 10:20 AM
> To: Petrie, Glen
> Cc: printing-architecture@lists.freestandards.org
> Subject: Re: [Printing-architecture] Embedded Client Thin-Thread: Initial
> Information
>
> Hi Glen,
>
> I'm strongly opposed to the cosmetic name fixups.  PAPI has been
> shipping in Solaris for years.  OPVP is shipping on most Linux
> distributions.  It's unfortunate, but that's life.
>
> Cheers,
> - Ira
>
> On 5/18/07, Petrie, Glen <glen.petrie@eitc.epson.com> wrote:
> > All,
> >
> > Since I did not receive any "Comments?  Opinions?", I am not sure what the
> > reaction was to the my note below.  I'll bet is was surprise to some but
> > others know how I feel about coherence.
> >
> > So again, do we want to try the coherence path?  Yes I know is heresy,
> > non-conventional and again the grain.  I know that others, including
> myself,
> > have put a lot work in their creations (API's, SDK's, actual code).
> But....
> > I think one of the powers of open source is to use the best from each and,
> > in that way, create, especially for this case, a larger AND coherent
> > solution.
> >
> > or
> >
> > Do we want to try the integration path?  Although this preserves the work
> of
> > the individuals, it is a integration and gluing approach for the larger
> > solution.
> >
> > glen
> >
> > -----Original Message-----
> > From: printing-architecture-bounces@lists.freestandards.org
> > [mailto:printing-architecture-bounces@lists.freestandards.org] On Behalf
> Of
> > Petrie, Glen
> > Sent: Wednesday, May 16, 2007 3:32 PM
> > To: printing-architecture@lists.freestandards.org
> > Subject: [Printing-architecture] Embedded Client Thin-Thread:
> > InitialInformation
> >
> > All,
> >
> > I started reviewing the work I did last year.  It appears I took some
> > liberties with things!!!! Ops!!!!
> >
> > The overall reasons for the changes I made was that I saw all of the OP
> > API's with differing naming conventions and duplicated (and sometimes
> > differing) definitions; which to me was/would-be very confusing to a
> > developer.  I wanted to solve this without being in conflict with existing
> > work.  So I took the approach of creating a new naming convention and
> would
> > remove any duplicate definitions.  To do that I decided to start with the
> > variables (meaning) used in JTAPI as the base and migrate everything else
> to
> > a common and new naming convention.  To do this I
> >
> > 1. I renamed the JTAPI stuff to EPP_; followed by a three char; then a
> > descriptor.
> >
> > for example: binding type when from
> >
> > typedef enum
> > {
> >    FSGJT_BD_NOT_SET = 0,
> >    FSGJT_BD_NONE,
> >    FSGJT_BD_CHANNEL,
> >    FSGJT_BD_EDGE_GLUE,
> >    FSGJT_BD_PERFECT,
> >    FSGJT_BD_PLASTIC_COMB,
> >    FSGJT_BD_RING,
> >    FSGJT_BD_SPIRAL,
> >    FSGJT_BD_STRIP,
> >    FSGJT_BD_TAPE,
> >    FSGJT_BD_THREAD_SEAL,
> >    FSGJT_BD_VELO,
> >    FSGJT_BD_WIRE_COMB
> > } fsgjt_binding_type_t;
> >
> >
> > to
> > typedef enum {
> >     EPP_BDT_NOT_SET = 0 ,
> >     EPP_BDT_NONE        ,
> >     EPP_BDT_CHANNEL     ,
> >     EPP_BDT_EDGE_GLUE   ,
> >     EPP_BDT_PERFECT     ,
> >     EPP_BDT_PLASTIC_COMB,
> >     EPP_BDT_RING        ,
> >     EPP_BDT_SPIRAL      ,
> >     EPP_BDT_STRIP       ,
> >     EPP_BDT_TAPE        ,
> >     EPP_BDT_THREAD_SEAL ,
> >     EPP_BDT_VELO        ,
> >     EPP_BDT_WIRE_COMB   ,
> >     EPP_BDT_EOL         ,
> >     EPP_BDT_EXT = EPP_EXTEN
> > } EPP_BINDING_TYPE;
> > #define EPP_BDT     EPP_BINDING_TYPE
> >
> > So the numerical value of each enum is the same but not the name!!!
> >
> >
> > Because I was initially (and could still) provide on a DOS-like interface
> > for the thin-thread, I needed a way to have a simple input mechanism for a
> > job ticket; so
> >
> > 2. I created a job-ticket file format that is parsed directly into a
> > job-ticket struct(s) I am using.
> >
> > No telling what other liberties I took!!!
> >
> >
> > Right now, I am at a conflict weather to just keep going or restart.  The
> > issue, to me, is one of overall and long term coherence.  If I keep going
> > then the intent is to use the best of any open source code and create a
> > coherent solution (both in naming and definition).  The alternative is to
> > try plugging existing but distinct pieces together.  I am worried about
> that
> > the latter, since it may result in an amount (small or large) of "glue
> code"
> > and perhaps some disconnects.  I guess I believe that in the end a
> developer
> > would have to get and understand distinct pieces of codes and disconnected
> > API's versus coherent set of API's
> >
> > Comments?  Opinions?
> >
> > glen
> >
> > _______________________________________________
> > Printing-architecture mailing list
> > Printing-architecture@lists.freestandards.org
> > http://lists.freestandards.org/mailman/listinfo/printing-architecture
> >
> > _______________________________________________
> > Printing-architecture mailing list
> > Printing-architecture@lists.freestandards.org
> > http://lists.freestandards.org/mailman/listinfo/printing-architecture
> >
>
>
> --
> 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: blueroofmusic@gmail.com
>
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.freestandards.org
> http://lists.freestandards.org/mailman/listinfo/printing-architecture
>
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.freestandards.org
> http://lists.freestandards.org/mailman/listinfo/printing-architecture
>


-- 
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: blueroofmusic@gmail.com

Re: [Printing-architecture] Embedded Client Thin-Thread: Initial Information

[Petrie, Glen]

Ira,

I believe it is bit more than "cosmetic name fixups"!  I also don't believe
that an embedded-client will be implemented using Solaris or a standard
Linux distributions; maybe a QT core or some other Posix core.  Anyway, I
understand your point; however, (there is always has to be a however) I am
worried that gluing together the existing stuff "as is" will simple result
in too large of a code base to be practical for any embedded-clients.
Therefore, I suggest we need to move the thin-thread from embedded-clients
to desktop-clients.  I remember all the discussions and reasons we went to
embedded-clients but there will be less practical risks/issues if we now
target desktop-clients.  After that, we can see how it will fit in the
embedded-clients.  We can still the scope of a desktop-client.

glen

-----Original Message-----
From: Ira McDonald [mailto:blueroofmusic@gmail.com] 
Sent: Friday, May 18, 2007 10:20 AM
To: Petrie, Glen
Cc: printing-architecture@lists.freestandards.org
Subject: Re: [Printing-architecture] Embedded Client Thin-Thread: Initial
Information

Hi Glen,

I'm strongly opposed to the cosmetic name fixups.  PAPI has been
shipping in Solaris for years.  OPVP is shipping on most Linux
distributions.  It's unfortunate, but that's life.

Cheers,
- Ira

On 5/18/07, Petrie, Glen <glen.petrie@eitc.epson.com> wrote:
> All,
>
> Since I did not receive any "Comments?  Opinions?", I am not sure what the
> reaction was to the my note below.  I'll bet is was surprise to some but
> others know how I feel about coherence.
>
> So again, do we want to try the coherence path?  Yes I know is heresy,
> non-conventional and again the grain.  I know that others, including
myself,
> have put a lot work in their creations (API's, SDK's, actual code).
But....
> I think one of the powers of open source is to use the best from each and,
> in that way, create, especially for this case, a larger AND coherent
> solution.
>
> or
>
> Do we want to try the integration path?  Although this preserves the work
of
> the individuals, it is a integration and gluing approach for the larger
> solution.
>
> glen
>
> -----Original Message-----
> From: printing-architecture-bounces@lists.freestandards.org
> [mailto:printing-architecture-bounces@lists.freestandards.org] On Behalf
Of
> Petrie, Glen
> Sent: Wednesday, May 16, 2007 3:32 PM
> To: printing-architecture@lists.freestandards.org
> Subject: [Printing-architecture] Embedded Client Thin-Thread:
> InitialInformation
>
> All,
>
> I started reviewing the work I did last year.  It appears I took some
> liberties with things!!!! Ops!!!!
>
> The overall reasons for the changes I made was that I saw all of the OP
> API's with differing naming conventions and duplicated (and sometimes
> differing) definitions; which to me was/would-be very confusing to a
> developer.  I wanted to solve this without being in conflict with existing
> work.  So I took the approach of creating a new naming convention and
would
> remove any duplicate definitions.  To do that I decided to start with the
> variables (meaning) used in JTAPI as the base and migrate everything else
to
> a common and new naming convention.  To do this I
>
> 1. I renamed the JTAPI stuff to EPP_; followed by a three char; then a
> descriptor.
>
> for example: binding type when from
>
> typedef enum
> {
>    FSGJT_BD_NOT_SET = 0,
>    FSGJT_BD_NONE,
>    FSGJT_BD_CHANNEL,
>    FSGJT_BD_EDGE_GLUE,
>    FSGJT_BD_PERFECT,
>    FSGJT_BD_PLASTIC_COMB,
>    FSGJT_BD_RING,
>    FSGJT_BD_SPIRAL,
>    FSGJT_BD_STRIP,
>    FSGJT_BD_TAPE,
>    FSGJT_BD_THREAD_SEAL,
>    FSGJT_BD_VELO,
>    FSGJT_BD_WIRE_COMB
> } fsgjt_binding_type_t;
>
>
> to
> typedef enum {
>     EPP_BDT_NOT_SET = 0 ,
>     EPP_BDT_NONE        ,
>     EPP_BDT_CHANNEL     ,
>     EPP_BDT_EDGE_GLUE   ,
>     EPP_BDT_PERFECT     ,
>     EPP_BDT_PLASTIC_COMB,
>     EPP_BDT_RING        ,
>     EPP_BDT_SPIRAL      ,
>     EPP_BDT_STRIP       ,
>     EPP_BDT_TAPE        ,
>     EPP_BDT_THREAD_SEAL ,
>     EPP_BDT_VELO        ,
>     EPP_BDT_WIRE_COMB   ,
>     EPP_BDT_EOL         ,
>     EPP_BDT_EXT = EPP_EXTEN
> } EPP_BINDING_TYPE;
> #define EPP_BDT     EPP_BINDING_TYPE
>
> So the numerical value of each enum is the same but not the name!!!
>
>
> Because I was initially (and could still) provide on a DOS-like interface
> for the thin-thread, I needed a way to have a simple input mechanism for a
> job ticket; so
>
> 2. I created a job-ticket file format that is parsed directly into a
> job-ticket struct(s) I am using.
>
> No telling what other liberties I took!!!
>
>
> Right now, I am at a conflict weather to just keep going or restart.  The
> issue, to me, is one of overall and long term coherence.  If I keep going
> then the intent is to use the best of any open source code and create a
> coherent solution (both in naming and definition).  The alternative is to
> try plugging existing but distinct pieces together.  I am worried about
that
> the latter, since it may result in an amount (small or large) of "glue
code"
> and perhaps some disconnects.  I guess I believe that in the end a
developer
> would have to get and understand distinct pieces of codes and disconnected
> API's versus coherent set of API's
>
> Comments?  Opinions?
>
> glen
>
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.freestandards.org
> http://lists.freestandards.org/mailman/listinfo/printing-architecture
>
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.freestandards.org
> http://lists.freestandards.org/mailman/listinfo/printing-architecture
>


-- 
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: blueroofmusic@gmail.com

Re: [Printing-architecture] Embedded Client Thin-Thread: Initial Information

[Petrie, Glen]

All,

Since I did not receive any "Comments?  Opinions?", I am not sure what the
reaction was to the my note below.  I'll bet is was surprise to some but
others know how I feel about coherence.

So again, do we want to try the coherence path?  Yes I know is heresy,
non-conventional and again the grain.  I know that others, including myself,
have put a lot work in their creations (API's, SDK's, actual code).  But....
I think one of the powers of open source is to use the best from each and,
in that way, create, especially for this case, a larger AND coherent
solution.  

or

Do we want to try the integration path?  Although this preserves the work of
the individuals, it is a integration and gluing approach for the larger
solution.  

glen

-----Original Message-----
From: printing-architecture-bounces@lists.freestandards.org
[mailto:printing-architecture-bounces@lists.freestandards.org] On Behalf Of
Petrie, Glen
Sent: Wednesday, May 16, 2007 3:32 PM
To: printing-architecture@lists.freestandards.org
Subject: [Printing-architecture] Embedded Client Thin-Thread:
InitialInformation

All,

I started reviewing the work I did last year.  It appears I took some
liberties with things!!!! Ops!!!! 

The overall reasons for the changes I made was that I saw all of the OP
API's with differing naming conventions and duplicated (and sometimes
differing) definitions; which to me was/would-be very confusing to a
developer.  I wanted to solve this without being in conflict with existing
work.  So I took the approach of creating a new naming convention and would
remove any duplicate definitions.  To do that I decided to start with the
variables (meaning) used in JTAPI as the base and migrate everything else to
a common and new naming convention.  To do this I 

1. I renamed the JTAPI stuff to EPP_; followed by a three char; then a
descriptor.

for example: binding type when from

typedef enum
{
   FSGJT_BD_NOT_SET = 0,
   FSGJT_BD_NONE,
   FSGJT_BD_CHANNEL,
   FSGJT_BD_EDGE_GLUE,
   FSGJT_BD_PERFECT,
   FSGJT_BD_PLASTIC_COMB,
   FSGJT_BD_RING,
   FSGJT_BD_SPIRAL,
   FSGJT_BD_STRIP,
   FSGJT_BD_TAPE,
   FSGJT_BD_THREAD_SEAL,
   FSGJT_BD_VELO,
   FSGJT_BD_WIRE_COMB
} fsgjt_binding_type_t;


to 
typedef enum {
    EPP_BDT_NOT_SET = 0 ,
    EPP_BDT_NONE        ,
    EPP_BDT_CHANNEL     ,
    EPP_BDT_EDGE_GLUE   ,
    EPP_BDT_PERFECT     ,
    EPP_BDT_PLASTIC_COMB,
    EPP_BDT_RING        ,
    EPP_BDT_SPIRAL      ,
    EPP_BDT_STRIP       ,
    EPP_BDT_TAPE        ,
    EPP_BDT_THREAD_SEAL ,
    EPP_BDT_VELO        ,
    EPP_BDT_WIRE_COMB   ,
    EPP_BDT_EOL         ,
    EPP_BDT_EXT = EPP_EXTEN
} EPP_BINDING_TYPE;
#define EPP_BDT     EPP_BINDING_TYPE

So the numerical value of each enum is the same but not the name!!!


Because I was initially (and could still) provide on a DOS-like interface
for the thin-thread, I needed a way to have a simple input mechanism for a
job ticket; so

2. I created a job-ticket file format that is parsed directly into a
job-ticket struct(s) I am using.

No telling what other liberties I took!!!


Right now, I am at a conflict weather to just keep going or restart.  The
issue, to me, is one of overall and long term coherence.  If I keep going
then the intent is to use the best of any open source code and create a
coherent solution (both in naming and definition).  The alternative is to
try plugging existing but distinct pieces together.  I am worried about that
the latter, since it may result in an amount (small or large) of "glue code"
and perhaps some disconnects.  I guess I believe that in the end a developer
would have to get and understand distinct pieces of codes and disconnected
API's versus coherent set of API's

Comments?  Opinions? 

glen 

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

Re: [Printing-architecture] Embedded Client Thin-Thread: Initial Information

[Ira McDonald]

Hi Glen,

I'm strongly opposed to the cosmetic name fixups.  PAPI has been
shipping in Solaris for years.  OPVP is shipping on most Linux
distributions.  It's unfortunate, but that's life.

Cheers,
- Ira

On 5/18/07, Petrie, Glen <glen.petrie@eitc.epson.com> wrote:
> All,
>
> Since I did not receive any "Comments?  Opinions?", I am not sure what the
> reaction was to the my note below.  I'll bet is was surprise to some but
> others know how I feel about coherence.
>
> So again, do we want to try the coherence path?  Yes I know is heresy,
> non-conventional and again the grain.  I know that others, including myself,
> have put a lot work in their creations (API's, SDK's, actual code).  But....
> I think one of the powers of open source is to use the best from each and,
> in that way, create, especially for this case, a larger AND coherent
> solution.
>
> or
>
> Do we want to try the integration path?  Although this preserves the work of
> the individuals, it is a integration and gluing approach for the larger
> solution.
>
> glen
>
> -----Original Message-----
> From: printing-architecture-bounces@lists.freestandards.org
> [mailto:printing-architecture-bounces@lists.freestandards.org] On Behalf Of
> Petrie, Glen
> Sent: Wednesday, May 16, 2007 3:32 PM
> To: printing-architecture@lists.freestandards.org
> Subject: [Printing-architecture] Embedded Client Thin-Thread:
> InitialInformation
>
> All,
>
> I started reviewing the work I did last year.  It appears I took some
> liberties with things!!!! Ops!!!!
>
> The overall reasons for the changes I made was that I saw all of the OP
> API's with differing naming conventions and duplicated (and sometimes
> differing) definitions; which to me was/would-be very confusing to a
> developer.  I wanted to solve this without being in conflict with existing
> work.  So I took the approach of creating a new naming convention and would
> remove any duplicate definitions.  To do that I decided to start with the
> variables (meaning) used in JTAPI as the base and migrate everything else to
> a common and new naming convention.  To do this I
>
> 1. I renamed the JTAPI stuff to EPP_; followed by a three char; then a
> descriptor.
>
> for example: binding type when from
>
> typedef enum
> {
>    FSGJT_BD_NOT_SET = 0,
>    FSGJT_BD_NONE,
>    FSGJT_BD_CHANNEL,
>    FSGJT_BD_EDGE_GLUE,
>    FSGJT_BD_PERFECT,
>    FSGJT_BD_PLASTIC_COMB,
>    FSGJT_BD_RING,
>    FSGJT_BD_SPIRAL,
>    FSGJT_BD_STRIP,
>    FSGJT_BD_TAPE,
>    FSGJT_BD_THREAD_SEAL,
>    FSGJT_BD_VELO,
>    FSGJT_BD_WIRE_COMB
> } fsgjt_binding_type_t;
>
>
> to
> typedef enum {
>     EPP_BDT_NOT_SET = 0 ,
>     EPP_BDT_NONE        ,
>     EPP_BDT_CHANNEL     ,
>     EPP_BDT_EDGE_GLUE   ,
>     EPP_BDT_PERFECT     ,
>     EPP_BDT_PLASTIC_COMB,
>     EPP_BDT_RING        ,
>     EPP_BDT_SPIRAL      ,
>     EPP_BDT_STRIP       ,
>     EPP_BDT_TAPE        ,
>     EPP_BDT_THREAD_SEAL ,
>     EPP_BDT_VELO        ,
>     EPP_BDT_WIRE_COMB   ,
>     EPP_BDT_EOL         ,
>     EPP_BDT_EXT = EPP_EXTEN
> } EPP_BINDING_TYPE;
> #define EPP_BDT     EPP_BINDING_TYPE
>
> So the numerical value of each enum is the same but not the name!!!
>
>
> Because I was initially (and could still) provide on a DOS-like interface
> for the thin-thread, I needed a way to have a simple input mechanism for a
> job ticket; so
>
> 2. I created a job-ticket file format that is parsed directly into a
> job-ticket struct(s) I am using.
>
> No telling what other liberties I took!!!
>
>
> Right now, I am at a conflict weather to just keep going or restart.  The
> issue, to me, is one of overall and long term coherence.  If I keep going
> then the intent is to use the best of any open source code and create a
> coherent solution (both in naming and definition).  The alternative is to
> try plugging existing but distinct pieces together.  I am worried about that
> the latter, since it may result in an amount (small or large) of "glue code"
> and perhaps some disconnects.  I guess I believe that in the end a developer
> would have to get and understand distinct pieces of codes and disconnected
> API's versus coherent set of API's
>
> Comments?  Opinions?
>
> glen
>
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.freestandards.org
> http://lists.freestandards.org/mailman/listinfo/printing-architecture
>
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.freestandards.org
> http://lists.freestandards.org/mailman/listinfo/printing-architecture
>


-- 
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: blueroofmusic@gmail.com

[Printing-architecture] Embedded Client Thin-Thread: Initial Information

[Petrie, Glen]

All,

I started reviewing the work I did last year.  It appears I took some
liberties with things!!!! Ops!!!! 

The overall reasons for the changes I made was that I saw all of the OP
API's with differing naming conventions and duplicated (and sometimes
differing) definitions; which to me was/would-be very confusing to a
developer.  I wanted to solve this without being in conflict with existing
work.  So I took the approach of creating a new naming convention and would
remove any duplicate definitions.  To do that I decided to start with the
variables (meaning) used in JTAPI as the base and migrate everything else to
a common and new naming convention.  To do this I 

1. I renamed the JTAPI stuff to EPP_; followed by a three char; then a
descriptor.

for example: binding type when from

typedef enum
{
   FSGJT_BD_NOT_SET = 0,
   FSGJT_BD_NONE,
   FSGJT_BD_CHANNEL,
   FSGJT_BD_EDGE_GLUE,
   FSGJT_BD_PERFECT,
   FSGJT_BD_PLASTIC_COMB,
   FSGJT_BD_RING,
   FSGJT_BD_SPIRAL,
   FSGJT_BD_STRIP,
   FSGJT_BD_TAPE,
   FSGJT_BD_THREAD_SEAL,
   FSGJT_BD_VELO,
   FSGJT_BD_WIRE_COMB
} fsgjt_binding_type_t;


to 
typedef enum {
    EPP_BDT_NOT_SET = 0 ,
    EPP_BDT_NONE        ,
    EPP_BDT_CHANNEL     ,
    EPP_BDT_EDGE_GLUE   ,
    EPP_BDT_PERFECT     ,
    EPP_BDT_PLASTIC_COMB,
    EPP_BDT_RING        ,
    EPP_BDT_SPIRAL      ,
    EPP_BDT_STRIP       ,
    EPP_BDT_TAPE        ,
    EPP_BDT_THREAD_SEAL ,
    EPP_BDT_VELO        ,
    EPP_BDT_WIRE_COMB   ,
    EPP_BDT_EOL         ,
    EPP_BDT_EXT = EPP_EXTEN
} EPP_BINDING_TYPE;
#define EPP_BDT     EPP_BINDING_TYPE

So the numerical value of each enum is the same but not the name!!!


Because I was initially (and could still) provide on a DOS-like interface
for the thin-thread, I needed a way to have a simple input mechanism for a
job ticket; so

2. I created a job-ticket file format that is parsed directly into a
job-ticket struct(s) I am using.

No telling what other liberties I took!!!


Right now, I am at a conflict weather to just keep going or restart.  The
issue, to me, is one of overall and long term coherence.  If I keep going
then the intent is to use the best of any open source code and create a
coherent solution (both in naming and definition).  The alternative is to
try plugging existing but distinct pieces together.  I am worried about that
the latter, since it may result in an amount (small or large) of "glue code"
and perhaps some disconnects.  I guess I believe that in the end a developer
would have to get and understand distinct pieces of codes and disconnected
API's versus coherent set of API's

Comments?  Opinions? 

glen