Vendor extensions

[James M Snell <ja...@gmail.com>]

At the Atom publishing interop event this week I spoke with the folks at
Google about Abdera.  They expressed an interest in helping to get
additional support for GData extensions implemented and into the
project.  I would like to do the same for the extensions that Lotus
Connections is introducing.  These extensions rightfully do not belong
in the core jars.  What I would like to do is create a new Vendor module
that would contain extension code specific to individual vendor
implementations.  The build process would produce individual jars for
each vendor extension (e.g. abdera.vendor.google.0.3.0-incubating.jar,
abdera.vendor.lotus.0.3.0-incubating.jar, etc).  The vendor module would
 be completely optional for end users. We could even make it a separate
download from the core distribution zip.

Thoughts? Concerns?

- James

Re: Vendor extensions

[James M Snell <ja...@gmail.com>]

Sanjiva Weerawarana wrote:
> [snip]
> Wouldn't it make more sense to have the framework for extensions and
> then allow vendors to publish their compatible extensions elsewhere?
> Maybe Abdera can have some automatic way of loading extensions. (This is
> similar to what BSF does for example.)
> 

It already does.  Using the ExtensionFactory mechanism, jars with static
extensions need only be dropped into the classpath to be picked up by
Abdera.

> I assume what Google asked for was to support the GData client API out
> of the box for Abdera. What about the other direction? Would they be ok
> with a GData server side impl also going with Abdera?
> 

Very good question.  I know that for the extensions we're introducing in
Lotus Connections, we are definitely OK with folks implementing their
own servers that use them.  I believe there are some google guys who
monitor this list perhaps they could weigh in on that question.

I'm working on getting the license for the LC extensions clarified and
documented.

- James

Re: Vendor extensions

[Sanjiva Weerawarana <sa...@opensource.lk>]

Garrett Rooney wrote:
>> Yes, that is a concern.  Is there an alternative naming approach that
>> would work better? I honestly do not know.
> 
> Sure, you don't have abdera-google.jar, you have abdera-ext-gdata.jar
> (the name of the spec, which theoretically anyone could use, not just
> google), you don't have abdera-ibm.jar or abdera-lotus.jar, you have
> abdera-ext-name-of-lotus-extensions.jar, etc.

Wouldn't it make more sense to have the framework for extensions and then 
allow vendors to publish their compatible extensions elsewhere? Maybe 
Abdera can have some automatic way of loading extensions. (This is similar 
to what BSF does for example.)

I assume what Google asked for was to support the GData client API out of 
the box for Abdera. What about the other direction? Would they be ok with 
a GData server side impl also going with Abdera?

> Note, that it's certainly a requirement, but it's not sufficient.  If
> the spec was licensed under icky terms (like keeping other people from
> implementing servers that use that protocol, for example), that would
> be a show stopper.  I suspect this will need to be a case by case sort
> of thing.

This is exactly what the OSI's trying to define as open source 
requirements for open source [1]. That effort is not done yet but that's 
the critical requirement if we're doing the above- it must not preclude an 
open source implementation. If you have comments please send them to 
standards-discuss@opensource.org.

Sanjiva.
[1] http://www.opensource.org/osr
-- 
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/

Re: Vendor extensions

[Garrett Rooney <ro...@electricjellyfish.net>]

On 4/19/07, James M Snell <ja...@gmail.com> wrote:
>
>
> Paul Querna wrote:
> > [snip]
> > I have mixed feelings about embedding vendor names in our filenames, or
> >  API names. (gdata vs google vs some-generic-standard-paths-name)
> >
>
> Yes, that is a concern.  Is there an alternative naming approach that
> would work better? I honestly do not know.

Sure, you don't have abdera-google.jar, you have abdera-ext-gdata.jar
(the name of the spec, which theoretically anyone could use, not just
google), you don't have abdera-ibm.jar or abdera-lotus.jar, you have
abdera-ext-name-of-lotus-extensions.jar, etc.

> > But, otherwise, I think it generally makes sense, as long as the vendor
> > is good about publishing how their extension works in a publicly
> > accessible document.
> >
>
> We can make a stable, publicly accessible document a minimum requirement
> for allowing any vendor-specific extension code into the project.

+1

Note, that it's certainly a requirement, but it's not sufficient.  If
the spec was licensed under icky terms (like keeping other people from
implementing servers that use that protocol, for example), that would
be a show stopper.  I suspect this will need to be a case by case sort
of thing.

-garrett

Re: Vendor extensions

[James M Snell <ja...@gmail.com>]

Paul Querna wrote:
> [snip]
> I have mixed feelings about embedding vendor names in our filenames, or
>  API names. (gdata vs google vs some-generic-standard-paths-name)
> 

Yes, that is a concern.  Is there an alternative naming approach that
would work better? I honestly do not know.

> But, otherwise, I think it generally makes sense, as long as the vendor
> is good about publishing how their extension works in a publicly
> accessible document.
> 

We can make a stable, publicly accessible document a minimum requirement
for allowing any vendor-specific extension code into the project.

- James

Re: Vendor extensions

[Paul Querna <pq...@apache.org>]

James M Snell wrote:
> At the Atom publishing interop event this week I spoke with the folks at
> Google about Abdera.  They expressed an interest in helping to get
> additional support for GData extensions implemented and into the
> project.  I would like to do the same for the extensions that Lotus
> Connections is introducing.  These extensions rightfully do not belong
> in the core jars.  What I would like to do is create a new Vendor module
> that would contain extension code specific to individual vendor
> implementations.  The build process would produce individual jars for
> each vendor extension (e.g. abdera.vendor.google.0.3.0-incubating.jar,
> abdera.vendor.lotus.0.3.0-incubating.jar, etc).  The vendor module would
>  be completely optional for end users. We could even make it a separate
> download from the core distribution zip.
> 
> Thoughts? Concerns?

I have mixed feelings about embedding vendor names in our filenames, or
 API names. (gdata vs google vs some-generic-standard-paths-name)

But, otherwise, I think it generally makes sense, as long as the vendor
is good about publishing how their extension works in a publicly
accessible document.

-Paul