11 Feb
2013
11 Feb
'13
5:15 p.m.
On 02/08/2013 01:36 PM, Denis Gervalle wrote:
Because the status is about the interface as a whole. It is particularly
about adding new methods (or signatures of existing methods), while
existing methods are stable.
I do not want to add something new, but to state clearly what we think of
our interfaces. This is already the case, while we do not really state it.
Considering anything an SPI is not an option IMO, since it will create more
complexity over time, for a very low benefit, since the chances of a third
party to implement an interface like the DataMigrationManager is near zero.
And if any, this third party will surely agree to apply some minor changes
to its implementation when needed.
All that said, I wonder if it wouldn't be better to annotate SPI interface
in place of non-SPI one, with a @SPI annotation. Which will favor API only
and limit complexity. A user really interested in implementing a not
annotated interface could easily open an issue explaining his use case, so
we may open the interface as an SPI.
--
Sergiu Dumitriu
http://purl.org/net/sergiu
On Fri, Feb 8, 2013 at 7:15 PM, Vincent Massol
<vincent(a)massol.net> wrote:
How about when Hibernate isn't used? The current implementation is
marked with the "hibernate" hint, so it suggests that it is valid only
in a Hibernate environment. It is a SPI, but one that can't easily be
implemented, since it requires a new storage engine, a new query
manager, plus rewriting all the $xwiki.search* instances, and so on.
On Feb 8, 2013, at 7:09 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
rather
If you consider them stable enough, these could be. The distinction is
clearly based of what we think of it. Let me take an example:
interface DataMigrationManager (do not mixup with DataMigration which is an
SPI for sure). Currently, I consider this one as an API, but I do not
imagine any serious usage of it as an SPI for a third party. Marking it API
only, would clearly state this point of view. It means that adding a new
method to this interface is not considered a breakage. Anyone which would
implement it, knows it could have his code broken later.
On Fri, Feb 8, 2013 at 3:58 PM, Vincent Massol
<vincent(a)massol.net>
wrote:
On Feb 8, 2013, at 3:42 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
> By the way, if we agree on @unstable, I also think having another
> annotation for marking stable API that are not considered to be stable
SPI.
> Why not something like @onlyAPI or @unstableSPI on an interface ?
I think first we need to define what is an SPI and what is an API first.
ATM I don't think I understand clearly the difference in the context of
XWiki. Is it clear for you?
I do not really understand your question. The general definition is clear: "Service Provider Interface (SPI) is
an API intended to be
implemented or extended by a third party".
All our component interfaces are meant to be implemented by 3rd parties to
override default behaviors. Are they SPI?
What I would like to be
annotated is API that we do not consider stable SPI at the moment. It is
less restrictive than @unstable, but more than not saying anything.
Is that answering your question ?
That seems complex. Why not use @unstable on "SPI" classes/methods?