atom feed9 messages in org.xwiki.devsRe: [xwiki-devs] [VOTE] Add CLIRR exc...
FromSent OnAttachments
Eduard MoraruOct 22, 2012 3:46 pm 
Arvind GuptaOct 22, 2012 3:48 pm 
Vincent MassolOct 22, 2012 11:29 pm 
Marius Dumitru FloreaOct 22, 2012 11:50 pm 
Thomas MortagneOct 23, 2012 1:19 am 
Denis GervalleOct 23, 2012 2:39 am 
Eduard MoraruOct 23, 2012 3:06 am 
Andreas JonssonOct 26, 2012 5:14 am 
Eduard MoraruNov 14, 2012 2:45 am 
Subject:Re: [xwiki-devs] [VOTE] Add CLIRR exclude for 2 new methods in the workspace interface for 4.3M1
From:Vincent Massol (
Date:Oct 22, 2012 11:29:37 pm

Hi Edy,

On Oct 23, 2012, at 12:46 AM, Eduard Moraru <> wrote:

Hi devs,

Since the current policy is to ask before adding a CLIRR exclude and since I did not ask when I applied GuillaumeD's pull request [1], I hereby ask for your vote whether it is ok to exclude the 2 new methods: - that allows the creation of workspaces using a different template than the default one - that lists workspace templates

Since we are tight with time (Fabio needs to finish the 4.3M1 release), this issue should be settled ASAP.

Also, please note that the Workspace API is still young (and pretty basic), as far as I am concerned, and it is bound to get updated in the future.

Here's my +1

The workspace API was introduced in 3.2
when it was included in XEM (it was there even before in platform I think). 3.2
was released 11th of October 2011. So that means the API has been there for more
than 1 year. It's starting to be long to consider it a "young api"… ;)

We really need to finish the discussion thread about "young apis" to clearly
define it as otherwise all devs are going to say that their code is young apis
forever… :)

Also note that your code is missing @since tags (for ex WorkspaceManager,
Workspace, etc). Could you please add them?

What are your alternatives here? I can think of at least 2 that wouldn't break
backward compat:

* Extend XWikiServer (for ex: WorkspaceXWikiServer) to add a new class field
holding the name of the template to use. It could be interesting information to
keep the fact that a given workspace was created with a given template so it
could make sense to store it in the XWikiServer class. Then of course you'll
need to do an instanceof in your code to see whether the passed XWikiServer
instance is of type XWikiServer or WorkspaceXWikiServer)

* Deprecate WorkspaceManager and introduce a new interface: WorkspaceManager2
(of course a better name should be found, that's the hard part but it can be
found, like WorkspaceHandler, WorkspaceService, etc). Then move WorkspaceManager
to legacy. Note that WorkspaceManagerScriptService can be modified without
breaking backward compat ;)

Before deciding on breaking backward compat, we should always discuss the
alternatives IMO and then, based on that, decide if we break it or not. From
your email we can't really see if you've thought about not breaking the
compatibility ;)

I'm +1, not because it's a young api (1 year is pretty long for me) but because
it's not a major and widely implemented API IMO so we probably won't break a lot
developers and I can't recall any extension on that would
be broken.

Thanks -Vincent