All of lore.kernel.org
 help / color / mirror / Atom feed
From: Norm Jacobs <Norm.Jacobs@Sun.COM>
To: "McDonald, Ira" <imcdonald@sharplabs.com>
Cc: printing-architecture@lists.freestandards.org
Subject: Re: [Printing-architecture] Activity Plan for OP Architecture WG
Date: Thu, 08 Feb 2007 17:37:21 -0600	[thread overview]
Message-ID: <45CBB431.50609@Sun.COM> (raw)
In-Reply-To: <789E617C880666438EDEE30C2A3E8D100105A5DF@mailsrvnt05.enet.sharplabs.com>

McDonald, Ira wrote:
> Hi,
>
> Yesterday's Open Printing Architecture telecon was attended
> by Claudia Alimpich, Glen Petrie, Till Kamppeter, and me.
>   
Yeh, sorry I missed it.  For some reason it dropped out of my calendar.
> We discussed useful activities for the Architecture team.
> Glen suggested that we focus on architectural _validation_ 
> of the various OP modules.  We all agreed with this idea.
>
>
> Open Pringing Architecture WG Activity Plan:
>
> (1) Thin-thread (rapid prototype) implementation of entire
>     Open Printing Subsystem, with all existing or planned
>     modules (API, plus at least stub code for logging)
>     - must assume embedded environment (e.g., memory and
>       I/O operations must be in wrapper macros)
>   
So you are proposing a project (or series of projects) to implement 
these APIs in open source either by embedding in existing open source 
projects or otherwise?  If so, how are we looking at finding the 
resources to get the work done?  I don't have a problem with donating 
time or code to implement components, but I need to make it fit in with 
other projects that I need to get done.  That is how the PAPI 
implementation on SourceForge got done.
> (2) Establishing naming and documentation conventions for
>     new OP printing APIs
>     - possibly a small new OP specification
>   
It might be nice to have a guideline document that describes conventions 
to be used in OP specs.
> (3) Standardizing licenses (e.g., MIT like JTAPI) for use
>     in OP design, documentation, APIs, and modules
>     - Glen - what is effect of Linux Foundation merger?
>   
As far as the specifications go, we can impose a license in order for 
the spec to be adopted.  As far as the code goes, we can suggest one or 
more licenses, but it's likely that a project team will make that 
decision on their own when they implement or open up/donate an existing 
implementation.

       -Norm



  reply	other threads:[~2007-02-08 23:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-08 17:01 [Printing-architecture] Activity Plan for OP Architecture WG McDonald, Ira
2007-02-08 23:37 ` Norm Jacobs [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-02-08 23:47 Petrie, Glen
2007-02-09 20:09 McDonald, Ira
2007-02-10  1:49 ` Norm Jacobs

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45CBB431.50609@Sun.COM \
    --to=norm.jacobs@sun.com \
    --cc=imcdonald@sharplabs.com \
    --cc=printing-architecture@lists.freestandards.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.