Re: [xwiki-devs] [Proposal] Get rid of Activity Stream and the Watchlist

2019-02-07 Thread Eduard Moraru
+1 in general, but please consider migration issues, specially calls to the
{{activity/}} macro that will be still found in wiki pages that will stop
working if the ActivityStream (which is a macro) is removed.

Also, for anyone using or extending the ActivityStream plugin's API
directly, their code will fail. I doubt there were many (if any) users of
the relatively obscure EventStream API, so the effect of the backwards
compatible "Event Stream Store" implementation will not compensate for
much, IMO.

What I am personally concerned about is that, ideally, the upgrade to the
new XWiki version (which no longer bundles these modules) require as less
(preferably none) manual operations as possible.

Thanks,
Eduard

On Wed, Feb 6, 2019 at 5:10 PM Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> +1
>
> Thanks,
> Marius
>
> On Mon, Feb 4, 2019 at 1:50 PM Guillaume Delhumeau <
> guillaume.delhum...@xwiki.com> wrote:
>
> > Dear developers,
> >
> > Now that we consider notifications as an achieved replacement for both
> > Activity Stream and the Watchlist, I propose to stop maintaining them and
> > to move them into the "attic" section.
> >
> > You need to know that we had a dependency on the Activity Stream API, as
> > the only implementation of the Event Stream, on which the Notifications
> are
> > based. So to get rid of this dependency (the code is not using our
> > component system and is not well tested), I have written a new
> > implementation of the Event Stream that I have called "Event Stream
> Store".
> > It's fully backward compatible with the old implementation, since it is
> > using the same Database schema. In practice, I re-used some pieces of
> > Activity Stream that I have modified to fit into components. For more
> > information, see: https://jira.xwiki.org/browse/XWIKI-16052
> >
> > So my proposal is this one:
> > - use the new store in 11.1
> > - stop bundle Watchlist and AS in 11.1
> > - move Watchlist and AS into "attic" in 11.2
> >
> > Thanks you,
> >
> > --
> > Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
> > Research & Development Engineer at XWiki SAS
> > Committer on the XWiki.org project
> >
>


Re: [xwiki-devs] Location for extensions ideas

2019-02-07 Thread Eduard Moraru
We also have the "Idea" issue type in Jira so I don't think we need a
dedicated project just for that. It would be best to find the existing
project that your idea could extend, otherwise the "XWIKI" (platform)
project is still a good fit, IMO, since we should then better determine if
the feature should be a core/platform feature or if it should best be
suited in its own separate extension.

It's easy to build a filter for all the ideas from all the projects we have
on Jira.

Thanks,
Eduard


On Thu, Jan 31, 2019 at 12:31 PM Ecaterina Moraru (Valica) <
vali...@gmail.com> wrote:

> We could install the Ideas app somewhere on design.xwiki.org and make it
> exclusive for listing Extensions ideas.
> Thanks,
> Caty
>
>
> On Thu, Jan 31, 2019 at 10:35 AM Thomas Mortagne <
> thomas.morta...@xwiki.com>
> wrote:
>
> > Hi xwikiers,
> >
> > I'm never sure where to put ideas of extensions I have so I often
> > forget them or details I had tough about or gathered back then.
> >
> > I don't think http://design.xwiki.org is the right place until you
> > really start designing the extension. Also it's too generic for this
> > need and not a very good entry point for searching something IMO, more
> > something to link to from somewhere else.
> >
> > I would prefer something really dedicated to this "that would be a
> > nice thingy but not sure about the details yet" state. Would be a good
> > source for hackathons and GSOC or for contributors who are searching
> > for something interesting to work on.
> >
> > I was thinking about the following alternatives:
> > * a new dedicated project on https://jira.xwiki.org
> > * reuse https://jira.xwiki.org/projects/XCONTRIB after some cleanup
> > (close everything left in it basically) but not super clean (it's just
> > that it's a good name)
> > * some new application on http://www.xwiki.org
> >
> > WDYT ?
> >
> > Right now my preference goes to a clean new jira project (just need to
> > think about a good project id) where you put description and close it
> > when the extension work really start on a dedicated location. Less
> > work and should do the job well.
> >
> > --
> > Thomas Mortagne
> >
>


Re: [xwiki-devs] [Proposal] Get rid of Activity Stream and the Watchlist

2019-02-07 Thread Guillaume Delhumeau
Le jeu. 7 févr. 2019 à 14:40, Eduard Moraru  a écrit :

> +1 in general, but please consider migration issues, specially calls to the
> {{activity/}} macro that will be still found in wiki pages that will stop
> working if the ActivityStream (which is a macro) is removed.
>

The UI of Activity Stream (which defines the macro you mentioned) is
already removed from XWiki Standard. But the retro-compatibility is handled
by
https://extensions.xwiki.org/xwiki/bin/view/Extension/Legacy%20Notification%20Activity%20Macro/
.

It's actually a good thing you that did not realized AS was not there
anymore :)


>
> Also, for anyone using or extending the ActivityStream plugin's API
> directly, their code will fail. I doubt there were many (if any) users of
> the relatively obscure EventStream API, so the effect of the backwards
> compatible "Event Stream Store" implementation will not compensate for
> much, IMO.
>
> What I am personally concerned about is that, ideally, the upgrade to the
> new XWiki version (which no longer bundles these modules) require as less
> (preferably none) manual operations as possible.
>
> Thanks,
> Eduard
>
> On Wed, Feb 6, 2019 at 5:10 PM Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
>
> > +1
> >
> > Thanks,
> > Marius
> >
> > On Mon, Feb 4, 2019 at 1:50 PM Guillaume Delhumeau <
> > guillaume.delhum...@xwiki.com> wrote:
> >
> > > Dear developers,
> > >
> > > Now that we consider notifications as an achieved replacement for both
> > > Activity Stream and the Watchlist, I propose to stop maintaining them
> and
> > > to move them into the "attic" section.
> > >
> > > You need to know that we had a dependency on the Activity Stream API,
> as
> > > the only implementation of the Event Stream, on which the Notifications
> > are
> > > based. So to get rid of this dependency (the code is not using our
> > > component system and is not well tested), I have written a new
> > > implementation of the Event Stream that I have called "Event Stream
> > Store".
> > > It's fully backward compatible with the old implementation, since it is
> > > using the same Database schema. In practice, I re-used some pieces of
> > > Activity Stream that I have modified to fit into components. For more
> > > information, see: https://jira.xwiki.org/browse/XWIKI-16052
> > >
> > > So my proposal is this one:
> > > - use the new store in 11.1
> > > - stop bundle Watchlist and AS in 11.1
> > > - move Watchlist and AS into "attic" in 11.2
> > >
> > > Thanks you,
> > >
> > > --
> > > Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
> > > Research & Development Engineer at XWiki SAS
> > > Committer on the XWiki.org project
> > >
> >
>


-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project


Re: [xwiki-devs] Update objects on class rename

2019-02-07 Thread Vincent Massol
Hi Marius/All,

See below

> On 31 Jan 2019, at 11:29, Vincent Massol  wrote:
> 
> Hi Marius/all,
> 
>> On 30 Jan 2019, at 15:45, Marius Dumitru Florea 
>>  wrote:
>> 
>> Hi devs,
>> 
>> I'm working on https://jira.xwiki.org/browse/XWIKI-1660 (I need it for
>> https://jira.xwiki.org/browse/XWIKI-13352) and I'd like to change the page
>> rename job (from refactoring module) to update the existing objects when a
>> class is renamed *if the "Update links" options is checked*.
>> 
>> Of course, we could add a new option (e.g. "Update objects") but:
>> 
>> * it complicates the rename UI (too many options)
>> * I think most of the users understand the current "Update links" option as
>> "update the places where this page is *used*". I don't think it makes sense
>> to have separate options (at least at the UI level) for things like "Update
>> macro calls" or "Update image includes".
>> * I don't see why you would want to update the back-links but not the
>> objects (or the other way around).
> 
> Sounds good to me in general.
> 
>> If we agree on using a single option ("Update links") then the next
>> questions are:
>> 
>> * Is there a better name? I think "Update links" is a good name for simple
>> users so I would keep it. Another option is "Update references" but it has
>> a special meaning for XWiki developers.
> 
> Maybe "Update other pages” with a hint saying “Ensure that other pages using 
> the renamed pages continue to work after the rename”.
> 
> ?
> 
>> 
>> * Should we update the hint for the "Update links" option? I think we
>> should, but only for advanced users, since they should be aware of the
>> implications of renaming a class. Simple users are not aware of the
>> existence of objects, most probably, so I wouldn't complicate their lives.
> 
> Would be nicer to find a single message that work for everyone but I agree 
> it’s not easy if we wish to provide details.
> 
> I feel a nicer option would be to NOT show “Update other pages” for simple 
> users since that should always be checked. Only offer the ability to uncheck 
> it for advanced users and this solves the hint issue too :)

Nobody replied to this proposal but I really find it the best by far and it 
solves your other questions too while making the UI simpler globally.

WDYT?

Thanks
-Vincent

[snip]