Fwd: Re: questions, questions

[Ate Douma <at...@douma.nu>]

Forwarding from rave-private@ as this is of general interest.

-------- Original Message --------
Subject: Re: questions, questions
Date: Wed, 09 Mar 2011 12:58:22 +0100
From: Ate Douma <at...@douma.nu>
To: rave-private@incubator.apache.org

On 07/03/11 15:50, Niels van Dijk wrote:
> Hi,
>
> some other questions:
>
> * What to do with the Shindig extensions (or bugfixes) we have?

Just providing some additional comments, in general I agree with other
feedback already given.

I myself always try to following rules with regards to bugfixes or needed
enhancements within another project:
a) First provide a patch to the external project *and* initiate discussion about
incorporating it. The discussion/interaction part is absolutely critical. In my
experience just "dumping" patches on a project usually doesn't work very well,
unless you accidentally scratched an itch within that project.
b) If the project isn't interested in the issue you're trying to fix and won't
apply the patch either, try to convince them then to at least provide
appropriate hooks to allow working around the issue on your own as an extension
instead.
c) If the time frame when your patch (or extension hooks) will be applied and
become available through a release will take too long to wait upon, *then* I
consider temporarily "hacking" or "patching" the issue within your own project
OK, as long as its clearly marked (separated/isolated) and with the intend to
remove this again at the earliest possible moment when the required other
project changes become available.
d) If neither the issue will be fixed nor needed extensions provided by the
other project, after ample discussion, reconsider if the issue really needs
"fixing". Forking (parts of) another project really should be considered bad
practice and undesirable.

Extensions are a bit different matter IMO.
Some extensions could be interesting for the other project to incorporate
themselves and best always try that first!
However, not all extensions might be in their scope just not receive enough
interest to make it worth while to donate.

For Shindig for instance I suspect they are not interested in more concrete
implementation of their SPIs. Those extensions we should integrate and provide
from Rave ourselves.

Finally, I expect (hope) Rave will be a little more adventurous than merely
stick to the OpenSocial spec alone and will add enhancements of its own which
might eventually end up back in the OpenSocial spec. Or just try to leverage
newer OpenSocial spec. features not currently yet supportable by Shindig (e.g.
OpenSocial 2.x).
Eventually these enhancements might (should) flow back to Shindig but in the
mean time we shouldn't have to wait on Shindig to provide these own its own.

Working closely together with the Shindig team however is critical for these,
and hopefully lead to Rave committers to also become Shindig committers, and
visa versa.

>
> We actually have two kinds of changes for shindig:
> ->  fixes&  extensions, e.g. in regard to oAuth. https etc. These are in
> face generic Shindig things, and should be fixed in Shindig. We
> submitted most of these as patches, but most ar ot in Shindig yet... We
> will need some way of dealing with that..
If these are generic Shindig things, these indeed need to go into Shindig.
If there are specific reasons or arguments why that didn't work out lets discuss
those (on rave-dev@).

> ->  implementation stuff, implementing the SPI. We actually use a
> OpenSocial client in our SPI and have modelled most of our external
> datasources to deliver OpenSocial REST as their API.
> This is mostly only interesting for SURFnet, however it might serve as
> an implementation example?
Those IMO won't be of interest to Shindig, but definitely sounds interesting for
Rave. Why would this only be of interest for SURFnet?
If you can (may) include this in the code donation, why not just do that?
Once we all have/see this, we can discuss and decide how it might be of use or not.

>
> * We have generic gadgets we could add, where to put these?
I suggest just adding them to the SURFnet import.
Depending on their general use, we might provide them with Rave itself, or
possibly re-donate them further to an other/external Gadget/Widget repository
project, like on apache-extras.org or elsewhere.

Regards,

Ate

>
> Cheers,
> Niels
>
>