After reviewing all task related to "improving" web setup, I've come to the conclusion that we do not want the user to decide which plugin he wants - he should decide which features he wants (or in some cases he should not decide even on that, ie. MessageAmp is a "good fit" for most installations done with web setup).

Due to that, I would suggest to "remove"plugins selection and introduce "feature" selection - in a similar way we did with "connection managers". We ask user if he wants c2s, s2s, etc. We do not ask if he wants to enable "particular connector" and I suppose we should do that with "processors" and the rest of the setup.

@wojtek @kobit What do you think? Basically we wanted web setup to be simple and easy to use so that would be better, while would allow us to make "best choices" for most of the users (users using web installer will most likely not have "requirements" for our specific plugins specified) and later on they can (and will have to) manage configuration in etc/config.tdsl file.

Due to that, I would suggest to "remove"plugins selection and introduce "feature" selection - in a similar way we did with "connection managers". We ask user if he wants c2s, s2s, etc. We do not ask if he wants to enable "particular connector" and I suppose we should do that with "processors" and the rest of the setup.

IMHO a very good idea.

+1

@wojtek @kobit Actually we already do not have Plugin section only Features by default. There is Advanced configuration options toggle which when enabled, shows all available plugins.

I with that in mind, I wonder which plugins should be moved to "features" in "non-advanced" configuration mode?

I would suggest to move:

• jabber:iq:last-marker
• motd
• remote-roster-management?
• urn:xmpp:csi:0 It is enabled already by default and we should leave it this way

If we look at the setup from this point of view, would adding those "features" to basic setup and removing "advanced" plugins & components would be enough?

Or do we need this advanced section? I'm asking as it has non-commonly used components as well.

Below I've added screenshots of the current setup pages in advanced and simple mode. If that would be up to me, I would remove advanced mode at all and move some features (if any should be moved) to basic setup. (possibly I would guard those "more advanced" components behind Advanced configuration options setting and would get rid of manual component and processors selection (to make setup simpler and more bullet proof).

Advanced components: Simple components:

Advanced plugins:

Simple features:

I think that moving those to Features and removing "advanced" would be the best solution. Installer in itself was intended to be "easy" way to install.

Yes, I agree. For really low level plugin adjustments, it is still possible to just edit config file.

I've simplified the web setup in HTTP API component

OK, the simplification of the installer looks great but… there is still issue with LastActivity. When enabled it only enables the "marker" plugin:

'sess-man' () {
    'jabber:iq:last-marker' () {}
}

which yields exception:

=====================
Could not initialize bean jabber:iq:last-marker (class: class tigase.xmpp.impl.LastActivityMarker), skipping injection of this bean
RootCause:
   -> tigase.kernel.KernelException: Can't inject <null> to field tigase.xmpp.impl.LastActivityMarker.retrievers
      [tigase.kernel.core.Kernel.inject(Kernel.java:1190)]
=====================

But as stated originally, it requires also a "retriever":

'sess-man' {
    'jabber:iq:last-marker' (active: true) {
    	'jabber:iq:last' (active: true) {}
    }
}

@wojtek I think that retriever (which parent points to last-maker should just be active by default? would that be OK?

I'm not sure - wouldn't it mean that we would have 'jabber:iq:last' working without any marker, which would result in incorrect last activity times? (this is a bit convoluted as we wanted to support multiple markers due to custom requirement a while ago and have dependency on 'jabber:iq:last'). Maybe it could be simplified?

wouldn't it mean that we would have 'jabber:iq:last' working without any marker

No, if parent is set on last-marker then last will not be loaded if last-marker is not loaded.

I'm not sure how it could be simplified, but I also wonder if last and last-marker should be part of the web setup which should be simple..

No, if parent is set on last-marker then last will not be loaded if last-marker is not loaded.

In that case making 'jabber:iq:last' as active seems the most sensible.

I'm not sure how it could be simplified, but I also wonder if last and last-marker should be part of the web setup which should be simple..

Yes and no: at some point (web)installer was intended as a "marketing" tool, so having there listed the most available things (not necessary enabled by default) give impression that you get more. But maybe @kobit should chime in with the current intention behind installer.

Done, if the marker (supplier) is enabled then processor (consumer) will be automatically enabled.