Re: [xwiki-devs] [Proposal] Disable Message Stream by default in platform distribution + XE

2016-10-15 Thread Eduard Moraru 
+1

The feature needs reworking and it`s doing more harm than good at the
current state.

Thanks,
Eduard

On Sat, Oct 15, 2016 at 12:26 PM, Vincent Massol  wrote:

>
> > On 15 Oct 2016, at 11:10, Vincent Massol  wrote:
> >
> > Hi devs,
> >
> > I’m working on http://jira.xwiki.org/browse/XWIKI-10543 and it’s been
> reported by Nicolas that all the users he’s seen use XWiki don’t use the
> Message Stream feature and moreover they even ask him to remove it.
> >
> > One specific issue he’s raised is that the messages are sent to the AS
> (either the global one or the user’s one) and the messages are drowned with
> the page updates.
>
> FTR this already logged as http://jira.xwiki.org/browse/XWIKI-9104
>
> > Basically we’d need to polish this feature better to make it really
> useful.
>
> FTR here’s a list of open issues for the Message Stream feature:
>
> http://jira.xwiki.org/issues/?jql=component%20%3D%20%
> 22Message%20Stream%22%20AND%20project%20%3D%20XWIKI%20AND%
> 20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC
>
> Thanks
> -Vincent
>
> > I agree with this POV. I also agree that in order to make XWiki simpler
> and less cluttered, this feature could be disabled.
> >
> > Thus I’m proposing to still bundle it but to disable it, since we
> already have a Message Stream Admin UI config.
> >
> > WDYT?
> >
> > Thanks
> > -Vincent
> >
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Entry point for Extensions

2016-10-15 Thread Eduard Moraru 
On Sat, Oct 15, 2016 at 6:37 PM, Vincent Massol  wrote:

>
> > On 15 Oct 2016, at 13:30, Eduard Moraru  wrote:
> >
> > Hi,
> >
> > On Fri, Oct 14, 2016 at 8:18 PM, Vincent Massol 
> wrote:
> >
> >>
> >>> On 14 Oct 2016, at 19:03, Thomas Mortagne 
> >> wrote:
> >>>
> >>> This does not make any sense at general Extension level.
> >>>
> >>> Could be custom metadata that apply to XAR extensions. Since that only
> >>> make sense for XAR extensions I would prefer to have this be
> >>> implemented as a xobject as usual.
> >>
> >> Yes, it could be implemented as a UIXP/XObject of the Extension UI.
> >>
> >>> For me this is already the job of the uix we use for application panel
> >>> so I don't really see the point of adding something else.
> >>
> >> It’s not enough at all. That was my main point and explanation.
> Apparently
> >> I failed to explain the problem correctly.
> >>
> >> I’ll give more details:
> >> * You install a XAR extension that provides a ConfigurableClass (but you
> >> don’t know that as a user)
> >>
> >
> > I would say that an application would need both and Entry Point (i.e.
> > homepage)
>
> I’d say this is optional. It would a pain to always mandate this. For
> example the LDAP Application only provides an Admin UI (it only helps to
> configure LDAP).
>
> So for me the entry point is another concept: it’s a link to a place where
> the user should go to use the app. It can be pointing either to the app’s
> home page if there’s one, or the app’s Admin UI page.
>
> The goal of this thread is not to talk about home pages or Admin sections
> of extensions. It’s about discoverability and making it easy for users to
> start using any extension that is installed through the EM UI.
>

AFAIU, we both agree on this :)

What I wanted to point out was that an application/extension could also
provide its "settings", just like you have for Firefox addons, for example.
You should go to a list of installed extensions/apps (TBD) and see both a
way to access that extension/app, but also the way to configure it. IMO, we
should not reuse the entry point for configuration stuff (when there is no
UI, like the LDAP example). However, other apps/extensions could have both.

IMO, it would be make more sense to talk about extensions here (i.e. at an
EM level), and not particularly about applications (i.e. along the lines of
Vincent's original suggestion). AFAIR, we now have extension categories.
Why bother with app panel UIXs or Application Descriptors, when EM already
provides all we need? We have the list of pages from EM and a way to
identify extensions that are of type "application". We now add the entry
point and the settings and we`re all good to go. It is up to the extension
to juggle the category, entry point and/or settings, if any of this applies
to it.

Also, this would fit both EM's UI for an extension's details view, but also
the Application Index's listing of installed applications (which would just
be a listing only extensions of category "application", and maybe AWM apps
which are not extensions yet).

No need to complicate things.

-Eduard


>
> Thanks
> -Vincent
>
> > but also an optional Configuration section (i.e. administration
> > section defined by either a ConfigurableClass entry or even something
> > custom).
> >
> > Thanks,
> > Eduard
> >
> >
> >> * After you’ve installed that extension, as a user, you don’t know what
> to
> >> do. You need to go read the doc for the app to understand where you
> need to
> >> go to start using it.
> >>
> >> So I’m really convinced we need something better than what we have now.
> >>
> >> Now after we move the Applications UIXP to the
> xwiki-platform-applications
> >> module, we could add an “entrypoint’ property in the UIXP but that would
> >> mean that the Extension Manager UI module would depend on
> >> xwiki-platform-applications. We would need to decide if it’s ok. I
> think it
> >> is since it can be considered as an application descriptor and I don’t
> see
> >> a problem of having the EM UI module know about application descriptors.
> >>
> >> WDYT?
> >>
> >> Thanks
> >> Vincent
> >>
> >>> On Fri, Oct 14, 2016 at 4:10 PM, Vincent Massol 
> >> wrote:
>  Hi devs,
> 
>  Problem
>  ===
> 
>  We have 2 issues right now when installing an extension in XWiki:
> 
>  1) It’s not clear where is the entry point of that extension.
>  - Example1: an app that is only for admins and only has a
> >> ConfigurableClass
>  - Example2: an app that provides a macro and doesn’t have a UI
> 
>  2) Even when an extension registers itself in the Applications Panel,
> >> the user still need to refresh the page or navigate away to see it.
> 
>  Proposal
>  
> 
>  * Introduce the concept of Entry point (a.k.a home page) in Extension
> >> metadata
>  * Have the EM UI display the extension’s

Re: [xwiki-devs] Problem of certificate in latest XE build

2016-10-15 Thread Eduard Moraru 
On the e.x.o page it says "Let's encrypt is trusted by Oracle Java only
since 1.8.0_101".

Just to stay on the safe side, we should probably just bundle that
extension.

On Sat, Oct 15, 2016 at 6:40 PM, Vincent Massol  wrote:

>
> > On 15 Oct 2016, at 14:27, Eduard Moraru  wrote:
> >
> > Actually (reading the extension page), it should be supported by java
> 1.8.
> > Are you on Java 7?
>
> I’m using 1.8.0_73-b02 (btw, I don’t think XWiki 8.4-SNAPSHOT would even
> start if I was using Java 7).
>
> So indeed the problem is caused by the "https://store.xwiki.com/
> xwiki/rest/“ repository entry which is now hardcoded and that requires
> some certificate probably.
>
> Does it work for you?
>
> Thanks
> -Vincent
>
> > Thanks,
> > Eduard
> >
> > On Sat, Oct 15, 2016 at 3:26 PM, Eduard Moraru 
> wrote:
> >
> >> I guess we need http://extensions.xwiki.org/
> xwiki/bin/view/Extension/Let%
> >> 27s+Encrypt+support/ to be bundled in the default flavor/XE.
> >>
> >> Thanks,
> >> Eduard
> >>
> >> On Sat, Oct 15, 2016 at 12:48 PM, Vincent Massol 
> >> wrote:
> >>
> >>> Hi devs,
> >>>
> >>> I’ve rebuilt XE today from sources and I got the following certificate
> >>> errors in my console:
> >>> https://gist.githubusercontent.com/vmassol/ebea2da98f00771b3
> >>> af5cb3ce90c582b/raw/4122a7d4754565ccfce13db8b7a95c63cb8697fe
> >>> /gistfile1.txt
> >>>
> >>> As you can see there are a lot of errors displayed.
> >>>
> >>> We need to fix this ASAP.
> >>>
> >>> Thanks
> >>> -Vincent
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Problem of certificate in latest XE build

2016-10-15 Thread Vincent Massol 

> On 15 Oct 2016, at 14:27, Eduard Moraru  wrote:
> 
> Actually (reading the extension page), it should be supported by java 1.8.
> Are you on Java 7?

I’m using 1.8.0_73-b02 (btw, I don’t think XWiki 8.4-SNAPSHOT would even start 
if I was using Java 7).

So indeed the problem is caused by the "https://store.xwiki.com/xwiki/rest/“ 
repository entry which is now hardcoded and that requires some certificate 
probably.

Does it work for you?

Thanks
-Vincent

> Thanks,
> Eduard
> 
> On Sat, Oct 15, 2016 at 3:26 PM, Eduard Moraru  wrote:
> 
>> I guess we need http://extensions.xwiki.org/xwiki/bin/view/Extension/Let%
>> 27s+Encrypt+support/ to be bundled in the default flavor/XE.
>> 
>> Thanks,
>> Eduard
>> 
>> On Sat, Oct 15, 2016 at 12:48 PM, Vincent Massol 
>> wrote:
>> 
>>> Hi devs,
>>> 
>>> I’ve rebuilt XE today from sources and I got the following certificate
>>> errors in my console:
>>> https://gist.githubusercontent.com/vmassol/ebea2da98f00771b3
>>> af5cb3ce90c582b/raw/4122a7d4754565ccfce13db8b7a95c63cb8697fe
>>> /gistfile1.txt
>>> 
>>> As you can see there are a lot of errors displayed.
>>> 
>>> We need to fix this ASAP.
>>> 
>>> Thanks
>>> -Vincent

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

Re: [xwiki-devs] [Proposal] Entry point for Extensions

2016-10-15 Thread Vincent Massol 

> On 15 Oct 2016, at 13:30, Eduard Moraru  wrote:
> 
> Hi,
> 
> On Fri, Oct 14, 2016 at 8:18 PM, Vincent Massol  wrote:
> 
>> 
>>> On 14 Oct 2016, at 19:03, Thomas Mortagne 
>> wrote:
>>> 
>>> This does not make any sense at general Extension level.
>>> 
>>> Could be custom metadata that apply to XAR extensions. Since that only
>>> make sense for XAR extensions I would prefer to have this be
>>> implemented as a xobject as usual.
>> 
>> Yes, it could be implemented as a UIXP/XObject of the Extension UI.
>> 
>>> For me this is already the job of the uix we use for application panel
>>> so I don't really see the point of adding something else.
>> 
>> It’s not enough at all. That was my main point and explanation. Apparently
>> I failed to explain the problem correctly.
>> 
>> I’ll give more details:
>> * You install a XAR extension that provides a ConfigurableClass (but you
>> don’t know that as a user)
>> 
> 
> I would say that an application would need both and Entry Point (i.e.
> homepage)

I’d say this is optional. It would a pain to always mandate this. For example 
the LDAP Application only provides an Admin UI (it only helps to configure 
LDAP).

So for me the entry point is another concept: it’s a link to a place where the 
user should go to use the app. It can be pointing either to the app’s home page 
if there’s one, or the app’s Admin UI page.

The goal of this thread is not to talk about home pages or Admin sections of 
extensions. It’s about discoverability and making it easy for users to start 
using any extension that is installed through the EM UI.

Thanks
-Vincent

> but also an optional Configuration section (i.e. administration
> section defined by either a ConfigurableClass entry or even something
> custom).
> 
> Thanks,
> Eduard
> 
> 
>> * After you’ve installed that extension, as a user, you don’t know what to
>> do. You need to go read the doc for the app to understand where you need to
>> go to start using it.
>> 
>> So I’m really convinced we need something better than what we have now.
>> 
>> Now after we move the Applications UIXP to the xwiki-platform-applications
>> module, we could add an “entrypoint’ property in the UIXP but that would
>> mean that the Extension Manager UI module would depend on
>> xwiki-platform-applications. We would need to decide if it’s ok. I think it
>> is since it can be considered as an application descriptor and I don’t see
>> a problem of having the EM UI module know about application descriptors.
>> 
>> WDYT?
>> 
>> Thanks
>> Vincent
>> 
>>> On Fri, Oct 14, 2016 at 4:10 PM, Vincent Massol 
>> wrote:
 Hi devs,
 
 Problem
 ===
 
 We have 2 issues right now when installing an extension in XWiki:
 
 1) It’s not clear where is the entry point of that extension.
 - Example1: an app that is only for admins and only has a
>> ConfigurableClass
 - Example2: an app that provides a macro and doesn’t have a UI
 
 2) Even when an extension registers itself in the Applications Panel,
>> the user still need to refresh the page or navigate away to see it.
 
 Proposal
 
 
 * Introduce the concept of Entry point (a.k.a home page) in Extension
>> metadata
 * Have the EM UI display the extension’s entry point (when there’s one)
>> after having installed the extension so that the user can click on it and
>> be taken to the home page of the extension.
 
 This would make extensions more discoverable IMO.
 
 Implementation Details
 ==
 
 * Some maven extension metadata properties in pom.xml
 
 * A format to represent an entry point. It shouldn’t be a full URL
>> since that needs to be computed at runtime. Basically it should contain:
 ** The document reference
 ** The action to use (view, admin, etc) - optional, should default to
>> “view"
 ** The query string to use - optional, should default to an empty query
>> string
 
 This corresponds to the notion of ResourceReference
>> (EntityResourceReference to be precise). However we don’t have any textual
>> representation of it ATM.
 
 WDYT? Good idea? Bad idea?
 
 Thanks
 -Vincent

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

Re: [xwiki-devs] Problem of certificate in latest XE build

2016-10-15 Thread Eduard Moraru 
Actually (reading the extension page), it should be supported by java 1.8.
Are you on Java 7?

Thanks,
Eduard

On Sat, Oct 15, 2016 at 3:26 PM, Eduard Moraru  wrote:

> I guess we need http://extensions.xwiki.org/xwiki/bin/view/Extension/Let%
> 27s+Encrypt+support/ to be bundled in the default flavor/XE.
>
> Thanks,
> Eduard
>
> On Sat, Oct 15, 2016 at 12:48 PM, Vincent Massol 
> wrote:
>
>> Hi devs,
>>
>> I’ve rebuilt XE today from sources and I got the following certificate
>> errors in my console:
>> https://gist.githubusercontent.com/vmassol/ebea2da98f00771b3
>> af5cb3ce90c582b/raw/4122a7d4754565ccfce13db8b7a95c63cb8697fe
>> /gistfile1.txt
>>
>> As you can see there are a lot of errors displayed.
>>
>> We need to fix this ASAP.
>>
>> Thanks
>> -Vincent
>>
>> ___
>> devs mailing list
>> devs@xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Problem of certificate in latest XE build

2016-10-15 Thread Eduard Moraru 
I guess we need
http://extensions.xwiki.org/xwiki/bin/view/Extension/Let%27s+Encrypt+support/
to be bundled in the default flavor/XE.

Thanks,
Eduard

On Sat, Oct 15, 2016 at 12:48 PM, Vincent Massol  wrote:

> Hi devs,
>
> I’ve rebuilt XE today from sources and I got the following certificate
> errors in my console:
> https://gist.githubusercontent.com/vmassol/ebea2da98f00771b3af5cb3ce90c58
> 2b/raw/4122a7d4754565ccfce13db8b7a95c63cb8697fe/gistfile1.txt
>
> As you can see there are a lot of errors displayed.
>
> We need to fix this ASAP.
>
> Thanks
> -Vincent
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Entry point for Extensions

2016-10-15 Thread Eduard Moraru 
Hi,

On Fri, Oct 14, 2016 at 8:18 PM, Vincent Massol  wrote:

>
> > On 14 Oct 2016, at 19:03, Thomas Mortagne 
> wrote:
> >
> > This does not make any sense at general Extension level.
> >
> > Could be custom metadata that apply to XAR extensions. Since that only
> > make sense for XAR extensions I would prefer to have this be
> > implemented as a xobject as usual.
>
> Yes, it could be implemented as a UIXP/XObject of the Extension UI.
>
> > For me this is already the job of the uix we use for application panel
> > so I don't really see the point of adding something else.
>
> It’s not enough at all. That was my main point and explanation. Apparently
> I failed to explain the problem correctly.
>
> I’ll give more details:
> * You install a XAR extension that provides a ConfigurableClass (but you
> don’t know that as a user)
>

I would say that an application would need both and Entry Point (i.e.
homepage) but also an optional Configuration section (i.e. administration
section defined by either a ConfigurableClass entry or even something
custom).

Thanks,
Eduard


> * After you’ve installed that extension, as a user, you don’t know what to
> do. You need to go read the doc for the app to understand where you need to
> go to start using it.
>
> So I’m really convinced we need something better than what we have now.
>
> Now after we move the Applications UIXP to the xwiki-platform-applications
> module, we could add an “entrypoint’ property in the UIXP but that would
> mean that the Extension Manager UI module would depend on
> xwiki-platform-applications. We would need to decide if it’s ok. I think it
> is since it can be considered as an application descriptor and I don’t see
> a problem of having the EM UI module know about application descriptors.
>
> WDYT?
>
> Thanks
> Vincent
>
> > On Fri, Oct 14, 2016 at 4:10 PM, Vincent Massol 
> wrote:
> >> Hi devs,
> >>
> >> Problem
> >> ===
> >>
> >> We have 2 issues right now when installing an extension in XWiki:
> >>
> >> 1) It’s not clear where is the entry point of that extension.
> >> - Example1: an app that is only for admins and only has a
> ConfigurableClass
> >> - Example2: an app that provides a macro and doesn’t have a UI
> >>
> >> 2) Even when an extension registers itself in the Applications Panel,
> the user still need to refresh the page or navigate away to see it.
> >>
> >> Proposal
> >> 
> >>
> >> * Introduce the concept of Entry point (a.k.a home page) in Extension
> metadata
> >> * Have the EM UI display the extension’s entry point (when there’s one)
> after having installed the extension so that the user can click on it and
> be taken to the home page of the extension.
> >>
> >> This would make extensions more discoverable IMO.
> >>
> >> Implementation Details
> >> ==
> >>
> >> * Some maven extension metadata properties in pom.xml
> >>
> >> * A format to represent an entry point. It shouldn’t be a full URL
> since that needs to be computed at runtime. Basically it should contain:
> >> ** The document reference
> >> ** The action to use (view, admin, etc) - optional, should default to
> “view"
> >> ** The query string to use - optional, should default to an empty query
> string
> >>
> >> This corresponds to the notion of ResourceReference
> (EntityResourceReference to be precise). However we don’t have any textual
> representation of it ATM.
> >>
> >> WDYT? Good idea? Bad idea?
> >>
> >> Thanks
> >> -Vincent
> >>
> >> ___
> >> 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
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] Problem of certificate in latest XE build

2016-10-15 Thread Vincent Massol 
Hi devs,

I’ve rebuilt XE today from sources and I got the following certificate errors 
in my console:
https://gist.githubusercontent.com/vmassol/ebea2da98f00771b3af5cb3ce90c582b/raw/4122a7d4754565ccfce13db8b7a95c63cb8697fe/gistfile1.txt

As you can see there are a lot of errors displayed.

We need to fix this ASAP.

Thanks
-Vincent

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

Re: [xwiki-devs] [Proposal] Disable Message Stream by default in platform distribution + XE

2016-10-15 Thread Vincent Massol 

> On 15 Oct 2016, at 11:10, Vincent Massol  wrote:
> 
> Hi devs,
> 
> I’m working on http://jira.xwiki.org/browse/XWIKI-10543 and it’s been 
> reported by Nicolas that all the users he’s seen use XWiki don’t use the 
> Message Stream feature and moreover they even ask him to remove it.
> 
> One specific issue he’s raised is that the messages are sent to the AS 
> (either the global one or the user’s one) and the messages are drowned with 
> the page updates.

FTR this already logged as http://jira.xwiki.org/browse/XWIKI-9104

> Basically we’d need to polish this feature better to make it really useful.

FTR here’s a list of open issues for the Message Stream feature:

http://jira.xwiki.org/issues/?jql=component%20%3D%20%22Message%20Stream%22%20AND%20project%20%3D%20XWIKI%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC

Thanks
-Vincent

> I agree with this POV. I also agree that in order to make XWiki simpler and 
> less cluttered, this feature could be disabled.
> 
> Thus I’m proposing to still bundle it but to disable it, since we already 
> have a Message Stream Admin UI config.
> 
> WDYT?
> 
> Thanks
> -Vincent
> 

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

[xwiki-devs] [Proposal] Disable Message Stream by default in platform distribution + XE

2016-10-15 Thread Vincent Massol 
Hi devs,

I’m working on http://jira.xwiki.org/browse/XWIKI-10543 and it’s been reported 
by Nicolas that all the users he’s seen use XWiki don’t use the Message Stream 
feature and moreover they even ask him to remove it.

One specific issue he’s raised is that the messages are sent to the AS (either 
the global one or the user’s one) and the messages are drowned with the page 
updates.

Basically we’d need to polish this feature better to make it really useful.

I agree with this POV. I also agree that in order to make XWiki simpler and 
less cluttered, this feature could be disabled.

Thus I’m proposing to still bundle it but to disable it, since we already have 
a Message Stream Admin UI config.

WDYT?

Thanks
-Vincent

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