Hi, On Tue, Oct 23, 2012 at 9:29 AM, Vincent Massol <[email protected]> wrote:

Hi Edy,

On Oct 23, 2012, at 12:46 AM, Eduard Moraru <[email protected]> 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 ( http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterprise...) 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… :)

It`s not so much a matter of time, as it is a matter of features. Since a big segment of our users wait for stable versions, it has not yet benefited from user attention and testing, but lately it is getting some more attention and more and more features are being asked. I know we have the other thread for "young api", but this is what I mean in my previous mail. It was developed one year ago but it is far from being complete and, since it did not make it into the Roadmap, it did not get the chance to mature, so again, I see it as being young and subject to change.

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

Sure.

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)

Not really an alternative here. We already have a Workspace interface and, most important, even if we do something like what you suggest, we will still need a method to create these instances, method which will be exposed in the API, thus breaking CLIRR.

* 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 ;)

Something like this could be done at some point, but, as I`ve already mentioned, this API is bound to get more changes. Most likely it should get a bigger refactoring the first time it makes it into the Roadmap. However, for the moment, for the additional 2 methods, I consider this overkill.

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 ;)

From the feature's point of view, I have considered and tried to handle backwards compatibility, at least regarding upgrades [1]. The API change part of the backwards compatibility issue is only addressed with a CLIRR exclude.

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 extensions.xwiki.org that would be broken.

Thanks, Eduard ---------- [1] https://github.com/xwiki/xwiki-platform/commit/b8c00d91928718fd7e54ebb6bed46...

Thanks -Vincent

...

Thanks, Eduard

-------- [1] https://github.com/xwiki/xwiki-platform/pull/70

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs