Re: [xwiki-devs] [Proposal] Nested Spaces support for Contrib Applications

[Denis Gervalle]

Hi Alex,

On Fri, Apr 1, 2016 at 8:48 AM, Alexandru Cotiuga <
alexandru.coti...@xwiki.com> wrote:

> Hello devs,
>
> Since I already experimented the Nested Spaces behaviour on the Forum
> application and there are other applications that might need it also, I
> think it's time to start discussing this topic and to decide what strategy
> should be implemented on contrib applications.
>

This is indeed an important discussion, I would have even prefer that we
had it before the recent change you made into the Forum app.

First of all, as Anca and Marius precise, we need to know what we mean by
an NS version of the application. And like them, I consider that we should
only move an application to NS when it brings some value to the application
itself, but not only IMO, also when it could pave the road for further
improvement or improve the integration with the wiki. IMO, the key here, is
that it should not be just a code style operation !

For those applications, that will really change their storage model to
nested spaces, you will find my thought  to your questions below.


> What I have done in the Forum app was to handle both Pre NS and NS versions
> of XWiki, writing specific code for each case (wrapped in if-else
> statements), which proved to be the most complex and hard to maintain way,
> without much benefit. Sooner or later, everybody will have a NS Xwiki
> version and then all the support for Pre NS would become useless and then
> the code should be cleaned, which would be a lot of work again.
>

Not only that, there is also a very high risk that further change in the
application be only tested under NS, and that we believe it works on
non-NS, while it is no more the case. Maintaining an application that
should work with data using very different models is very dangerous, and
cost a lot if you want to ensure proper testing. There is also a lot of
weird cases when you migrate from one storage to another if you do not
proceed to a migration of the data. So, yes, if the data model change, the
migration is required, and supporting both models in the same application
seems to be very hard with no real benefit, and a lot of risks.


> Besides this already tried strategy, there are some others to be discused:
>
> 1: Support both Pre NS and NS versions but in different branches.
>

+0: The best, but probably requiring too much work in regards to our man
power.


> 2: Move to NS, but keep fixing bugs for Pre NS in a separate branch. (This
> is what I'm proposing)
>

+1: definitely, the most reasonable solution for me during the next major
release.


> 3: Move to NS without any maintance on Pre NS.
>

+0: this could works unless a major bug is discovered on the application


> 4: Others?
>

-1: for mixing two data model in the same code base
-0: for mixing support unless the improvement are trivial enough that my
fear described above could not arise.


>
> In all the cases, a data migration should be performed.
>
> What we decide to do?
>
> Thanks,
> Alex
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>

Thanks,

-- 
Denis Gervalle
SOFTEC sa - CEO
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Nested Spaces support for Contrib Applications

[Marius Dumitru Florea]

On Fri, Apr 8, 2016 at 12:03 PM, Anca Luca  wrote:

> Hello all,
>
> I think the best would be 2, but it could be discussed on an app by app
> basis and, in my opinion, the options need to be looked in the context of
> what does it mean that an "application needs to pass to Nested Spaces".
> This is my view on it:
>
>
>

>- Requirement of a nested spaces version should be done if the
>functionalities of the application demand it (there is a feature that is
>added to the functionality that needs nested spaces in order to work)
>

+1. IMO it's also very important to distinguish between:

* works with Nested Pages
* uses Nested Pages

At first we should just make sure the applications continue to work with
XWiki 7.2+, i.e. with Nested Pages enabled (without actually using the
Nested Pages feature). This is mostly a matter of using correctly the
entity reference APIs which have been supporting Nested Spaces from the
start (we just assumed so far that there is only one space). The APIs we
added after 7.2 are mostly helpers to ease the work with Nested Pages.

After we make the application work with XWiki 7.2+ we can discuss whether
it should use Nested Pages or not (i.e. whether it should create Nested
Pages or not). As Anca said, it needs to bring some value to the
application as perceived by its users. To give you an example, the reason I
would modify the File Manager to use Nested Pages is to have Access Rights
inheritance for folders and files.

Thanks,
Marius


>   - Note that application can *work* on nested spaces without
>   *requiring* nested spaces (because of the general backwards
>   compatibility of nested spaces feature), this bullet above is about
>   requiring nested spaces.
>- Even if previous versions can still be supported by an application
>migrated to nested spaces, if this adds a lot of bloat and "if"s in the
>code and extra complexity, the benefits are probably not worth it (it
>should still be discussed though) - this would be option 0
>- A particular case is when an application does not work on nested
>spaces in its current form and needs to be modified to support nested
>spaces. In this case, there needs to be an effort to find a reasonable
>approach that would allow the application to work, with the same code,
> on
>both nested spaces and non-nested spaces (which could be possible
> because
>of the generic backwards compat of nested spaces)
>
>
> Otherwise put, I am fine that there are applications on which we apply 2
> (and even 3) , but there needs to be a good reason  to pass to Nested
> Spaces for an application, potentially joined by a validation discussion
> with the community. If we decide we go to nested for an app, both 2 and 3
> are fine. In such a case I would be against option 0 that Vincent
> mentioned: adds complexity and bloats the code for an application, raises
> the learning curve and it will be removed in the future.
>
> Now please note that applying 2 means that if you're in the middle of the
> developpement for a version of an application, on which some issues were
> already fixed, and you want to move to a nested spaces version, it would be
> nice to release current work first as the "last version before nested
> spaces" and only then break compat. This is also valid for planning the
> versions of the application: bugfixes / features that don't require nested
> spaces should be planned in earlier, separate versions than features that
> would require nested spaces.
>
>
> On Fri, Apr 1, 2016 at 8:48 AM, Alexandru Cotiuga <
> alexandru.coti...@xwiki.com> wrote:
>
> > Hello devs,
> >
> > Since I already experimented the Nested Spaces behaviour on the Forum
> > application and there are other applications that might need it also, I
> > think it's time to start discussing this topic and to decide what
> strategy
> > should be implemented on contrib applications.
> >
> > What I have done in the Forum app was to handle both Pre NS and NS
> versions
> > of XWiki, writing specific code for each case (wrapped in if-else
> > statements), which proved to be the most complex and hard to maintain
> way,
> > without much benefit. Sooner or later, everybody will have a NS Xwiki
> > version and then all the support for Pre NS would become useless and then
> > the code should be cleaned, which would be a lot of work again.
> >
> > Besides this already tried strategy, there are some others to be
> discused:
> >
> > 1: Support both Pre NS and NS versions but in different branches.
> > 2: Move to NS, but keep fixing bugs for Pre NS in a separate branch.
> (This
> > is what I'm proposing)
> > 3: Move to NS without any maintance on Pre NS.
> > 4: Others?
> >
> > In all the cases, a data migration should be performed.
> >
>
> Depends on what we understand by data migration: if the data format changes
> (e.g. the data of the application needs to have a new hierarchical
> structure because a functionality 

Re: [xwiki-devs] [Proposal] Nested Spaces support for Contrib Applications

[Anca Luca]

Hello all,

I think the best would be 2, but it could be discussed on an app by app
basis and, in my opinion, the options need to be looked in the context of
what does it mean that an "application needs to pass to Nested Spaces".
This is my view on it:


   - Requirement of a nested spaces version should be done if the
   functionalities of the application demand it (there is a feature that is
   added to the functionality that needs nested spaces in order to work)
  - Note that application can *work* on nested spaces without
  *requiring* nested spaces (because of the general backwards
  compatibility of nested spaces feature), this bullet above is about
  requiring nested spaces.
   - Even if previous versions can still be supported by an application
   migrated to nested spaces, if this adds a lot of bloat and "if"s in the
   code and extra complexity, the benefits are probably not worth it (it
   should still be discussed though) - this would be option 0
   - A particular case is when an application does not work on nested
   spaces in its current form and needs to be modified to support nested
   spaces. In this case, there needs to be an effort to find a reasonable
   approach that would allow the application to work, with the same code, on
   both nested spaces and non-nested spaces (which could be possible because
   of the generic backwards compat of nested spaces)


Otherwise put, I am fine that there are applications on which we apply 2
(and even 3) , but there needs to be a good reason  to pass to Nested
Spaces for an application, potentially joined by a validation discussion
with the community. If we decide we go to nested for an app, both 2 and 3
are fine. In such a case I would be against option 0 that Vincent
mentioned: adds complexity and bloats the code for an application, raises
the learning curve and it will be removed in the future.

Now please note that applying 2 means that if you're in the middle of the
developpement for a version of an application, on which some issues were
already fixed, and you want to move to a nested spaces version, it would be
nice to release current work first as the "last version before nested
spaces" and only then break compat. This is also valid for planning the
versions of the application: bugfixes / features that don't require nested
spaces should be planned in earlier, separate versions than features that
would require nested spaces.


On Fri, Apr 1, 2016 at 8:48 AM, Alexandru Cotiuga <
alexandru.coti...@xwiki.com> wrote:

> Hello devs,
>
> Since I already experimented the Nested Spaces behaviour on the Forum
> application and there are other applications that might need it also, I
> think it's time to start discussing this topic and to decide what strategy
> should be implemented on contrib applications.
>
> What I have done in the Forum app was to handle both Pre NS and NS versions
> of XWiki, writing specific code for each case (wrapped in if-else
> statements), which proved to be the most complex and hard to maintain way,
> without much benefit. Sooner or later, everybody will have a NS Xwiki
> version and then all the support for Pre NS would become useless and then
> the code should be cleaned, which would be a lot of work again.
>
> Besides this already tried strategy, there are some others to be discused:
>
> 1: Support both Pre NS and NS versions but in different branches.
> 2: Move to NS, but keep fixing bugs for Pre NS in a separate branch. (This
> is what I'm proposing)
> 3: Move to NS without any maintance on Pre NS.
> 4: Others?
>
> In all the cases, a data migration should be performed.
>

Depends on what we understand by data migration: if the data format changes
(e.g. the data of the application needs to have a new hierarchical
structure because a functionality requires this hierarchy - e.g. inheriting
rights) then we need to have a data migration, as in take into account the
fact that there will be upgrades of the application, and that we should
have an unique format of data for the application in question (e.g. there
is no reason that the data structure is different between a user that has
installed the app on a fresh 7.4 and a user that has upgraded the
application from a previous version on a 7.4 xwiki).
If "data migration" is about just transforming all existing pages of
an/created by an application (which are terminal) into non-terminal pages,
then it should not be done unless there is a feature that requires it. I
think this data migration needs to be looked at as a change in the
application data structure (from a 2 levels hierarchy to an infinite
hierarchy) and should be done only if there is a functional benefit that
justifies it. In this context, breaking compat of the FAQ app by moving the
FAQ pages to a "Data" subspace of the FAQ space for the sole reason that
this is what AWM is doing now is not ok, because the reason is not good
enough. So, imo, since these reasons will really differ from app to app and

Re: [xwiki-devs] [Proposal] Nested Spaces support for Contrib Applications

[Vincent Massol]

Hi Alex,

Thanks for starting this discussion.

> On 01 Apr 2016, at 08:48, Alexandru Cotiuga  
> wrote:
> 
> Hello devs,
> 
> Since I already experimented the Nested Spaces behaviour on the Forum
> application and there are other applications that might need it also, I
> think it's time to start discussing this topic and to decide what strategy
> should be implemented on contrib applications.
> 
> What I have done in the Forum app was to handle both Pre NS and NS versions
> of XWiki, writing specific code for each case (wrapped in if-else
> statements), which proved to be the most complex and hard to maintain way,
> without much benefit. Sooner or later, everybody will have a NS Xwiki
> version and then all the support for Pre NS would become useless and then
> the code should be cleaned, which would be a lot of work again.
> 
> Besides this already tried strategy, there are some others to be discused:

0: Support both pre-nested and post-nested with “if”

I think this could be a good strategy and till the end of the 8.x cycle at 
least. When we start 9.x we would have to modify code to drop the “if” and 
simplify the code.

> 1: Support both Pre NS and NS versions but in different branches.

This one is probably the best from a theoretical POV but it’s a lot of work, 
probably too much work for the manpower we have.

> 2: Move to NS, but keep fixing bugs for Pre NS in a separate branch. (This
> is what I'm proposing)

This one makes sense to me. It’s the one that will work and with the least 
amount of work required. However there’s a drawback. It means that users of 
versions of XWiki older than 7.2 will not be able to get the new 
features/improvements which will happen on master. However since 7.4.x is now 
the official LTS and users are going to start moving to it (we currently have 
45% of active installs of XWiki on 7.2+), I think it could be acceptable.

> 3: Move to NS without any maintance on Pre NS.

I remind you that each extension on xwiki-contrib defines the minimum version 
of XWiki it should work with and we shouldn’t change that without a discussion 
and agreement. So this could on a per-extension basis with a vote.

> 4: Others?
> 
> In all the cases, a data migration should be performed.

I don’t fully agree with this. It’s a nice to have but I don’t think it’s 
mandatory for all extensions.

For example take the FAQ application. Currently it has wiki pages in 2 spaces:
- FAQCode
- FAQ

When a FAQ entry is created, it’s currently located in the FAQ space.

The target organization we would like is  (as discussed in the past on 
http://markmail.org/message/657vcm6ylkz4yytc but we need to close this 
discussion thread; note that it’s already implemented by AWM):

|_ FAQ
   |_ Code
   |_ Data

This raises 2 questions:
1) Do we want to move to this structure now and is it worth it?  Or should we 
wait for 8.x to be LTS before starting this type of refactoring?
2) Do we want to migrate existing FAQ pages to the FAQ.Data space? And if so, 
how? On another thread I proposed to introduce a new concept of migration with 
a DW-like UI.

Thanks
-Vincent

> What we decide to do?
> 
> Thanks,
> Alex
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Nested Spaces support for Contrib Applications

[Thomas Mortagne]

The current LTS is now 7.4.x and it support Nested Space so +1 for 3)

On Fri, Apr 1, 2016 at 8:48 AM, Alexandru Cotiuga
 wrote:
> Hello devs,
>
> Since I already experimented the Nested Spaces behaviour on the Forum
> application and there are other applications that might need it also, I
> think it's time to start discussing this topic and to decide what strategy
> should be implemented on contrib applications.
>
> What I have done in the Forum app was to handle both Pre NS and NS versions
> of XWiki, writing specific code for each case (wrapped in if-else
> statements), which proved to be the most complex and hard to maintain way,
> without much benefit. Sooner or later, everybody will have a NS Xwiki
> version and then all the support for Pre NS would become useless and then
> the code should be cleaned, which would be a lot of work again.
>
> Besides this already tried strategy, there are some others to be discused:
>
> 1: Support both Pre NS and NS versions but in different branches.
> 2: Move to NS, but keep fixing bugs for Pre NS in a separate branch. (This
> is what I'm proposing)
> 3: Move to NS without any maintance on Pre NS.
> 4: Others?
>
> In all the cases, a data migration should be performed.
>
> What we decide to do?
>
> Thanks,
> Alex
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs



-- 
Thomas Mortagne
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs