Openfire 4.0 (Draft for discussion)

General Discussion Community Planning
1

Unless you’ve not been following Openfire development, you’ll have noticed a huge volume of new patches and activity over the past few weeks, and you’ll know that the master branch on github has quite a few new features, including MAM - the new message archiving management specification, SCRAM authentication, and a simple implementation of XEP-0198’s stream management protocol. There’s @Guus der Kinderen’s new Certificate management UI in the administration console, and a bunch of code to tidy up how that operates behind the scenes, enhancing security. In addition, you’re probably aware that a huge number of code clean-up patches are going through, mostly by @CSH.

Most of our bugfixes have also ended up on the 3.10 branch, where @Daryl Herzmann made a new bugfix release just a few days ago, and we’ll be continuing those bugfix releases for a long while yet.

But it’s time to start moving toward stabilizing the master branch and releasing it.

Originally we’ve been talking in terms of this release being 3.11.0, but given the levels of work and new capabilities, and the desire to signal that Openfire is very much moving forward, we think that 4.0.0 is a better version number. In order to do that, we’re going to move to requiring two sign offs from committers other than the original author for any Pull Request to be merged as from now:

All PRs now require sign-off from two other committers.

So I’m going to propose some dates. I’d like to cut off new features - so we can stabilize what we have - in a week’s time:

Feature Freeze: Friday 27th November 2015.

Then I’m going to say that we have two weeks after that to stabilize the code. Pull Requests will still be accepted as long as they’re not adding new features, but over the following two weeks we’ll be expecting those changes to be reduced in scope as we become more risk-averse. After those two weeks we’ll create a new branch and issue a Beta release:

Beta Release: Friday 11th December 2015.

Then we allow the community to bed this in and test, allowing only bugfixes for which a workaround is not acceptable, until a final release in early January:

Final Release: Friday 8th January 2015.

Then we can breathe…

This is a draft for discussion, I can change the dates if needed, but I’d like to be quite aggressive in getting this out in a reasonably short timeframe. Once we’re happy I’ll repeat this post in the dev space.

1 Like
2

Thanks for putting this together, Guus’s connection rewrite is the only other big thing that I know somebody is working on. I am unsure if he’ll have that done in seven days.

3

I welcome the draft and will beta test

4

I’m all in favor of moving up a major version number.

In seven days (which amounts to about two days that I can actually spend on this) I can have something that will be “feature-complete” (-ish) but not “done / releasable”. Simply put: I expect to introduce quite some bugs that will need ironing out. I think that fits well with @Dave Cridland’s definition of what can be modified where in the timeline though.

From past experience, we known that a beta release doesn’t really get us a lot of feedback. I’d prefer to see the release dates moved forward and have the final release before the holidays. There’s a good chance that during those days some of us (me! me!) are more likely to find some free time to work on issues that will be reported.

5

Actually I don’t see that many new features, besides those you’ve mentioned. XEP-0198 is only half done, MAM is still in experimental status and people probably don’t care much about SCRAM.

My understanding of a major release like 4.0.0 is that there will (or can) also be major code refactorings, especially with respect to the API.

I mean, API is supposed to stay relatively stable within a major release number, according to Semantic Versioning 2.0.0, so once released we shouldn’t change the API.

With 4.0.0 we have the chance to rethink and redesign the API.

Some random ideas:

  • Rename package org.jivesoftware to org.igniterealtime?

  • Currently there is no plugin interface, i.e. a plugin can access every public class/method in Openfire core. It has pros and cons, but usually plugins communicate through an interface to the core application, so that the core can evolve without breaking plugins (too much). E.g. we could define a set of interfaces and publish it as a lightweight “openfire-api.jar”, which plugins would reference.

  • Also with regard to the API, we could rethink stuff like OF-149 (among others)

  • Cleanup the package layout: e.g. org.jivesoftware.admin vs. org.jivesoftware.openfire.admin.

  • Drop Clearspace support?

  • Refactor admin console to use JSF instead of JSP (but likely nobody will ever do this work)

  • Clean up the directory structure as its used by Maven and Gradle: Use src/main/java, src/main/resources, etc…

Here are more thoughts:

Thoughts on Openfire 4.0

That said, I think that roadmap is too damn fast for 4.0.0.

Personally I’d like to have the Maven migration happen asap. This can also be done in a 3.x release as it’s only the build. From there on, it’s probably much easier to do some other refactorings.

I suggest to first brainstorm ideas and determine TODOs, ask what developers want, discuss API, but don’t throw out a 4.0.0 just because there are three new features. These could go as well in 3.11.0.

6

People do care about SCRAM, but the interesting part of SCRAM is that it’s the missing feature from claiming RFC 612[01] compliance.

As for SemVer, we already had a breaking change on plugins in 3.10, in effect, so to claim we’re using SemVer is way too late. Version numbering is also a marketing tool, and it’s a useful one at that - for Openfire, it’s saying “we’re doing new work here, not just bugfixing”. I think in order to have much validity for SemVer, we’d need to handle the plugin interface you mentioned, and we probably would be better off starting SemVer at a clear boundary (like 4.0.0).

And of course, a 4.0.0 now doesn’t preclude a 4.1.0 or even a 5.0.0 next year.

I would indeed like to sort out Maven soon; there was a discussion this morning on whether we could manage it within this timeframe. What are your thoughts?

7

Idea about the point:

  • Refactor admin console to use JSF instead of JSP (but likely nobody will ever do this work)
    Would it be not better, to make more lightweight UI (e.g. Angular/Boostrap) which communicate over REST to an API?

I mean, sure it is a long way to go, and the REST API need to be much more extended but I guess that is a better approach then to merge it to JSF.

And yes, I would also prefer to move to Maven (++).

8

In order to do that, we’re going to move to requiring two sign offs from committers other than the original author for any Pull Request to be merged as from now:

All PRs now require sign-off from two other committers.

What about plugin PRs?

9

I would indeed like to sort out Maven soon; there was a discussion this morning on whether we could manage it within this timeframe. What are your thoughts?

Well, it compiles (as can be seen by the Travis build) :wink:

It can generate the JavaDoc and the sources archive for download.

It compiles JSP pages for the admin plugin.

Tests run, too.

It assembles the startup.jar and openfire.jar.

It assembles the plugin jars (most of them, JSP compilation is missing).

There are some plugins, especially the ofmeet, rayo and kraken plugin, which don’t compile currently, because they use some really weird homebrew jars or even snapshots.

There’s still much to do and I can’t manage it alone.

Especially the build of all the native distributables (install4j, *.dmg for Mac, Linux). The current Ant script references some native executables, which are located at ignite’s build servers.

For some reason when starting the startup.jar, the web admin is not loaded, need to investigate it.

There’s also the Tinder issue (only core jar which is not in Maven Central), but it can be worked around with .

I don’t think me or the community can resolve all these issue within a week.

10

Personally, I would prefer to leave the current openfire plugin API as it is. It is very flexible and it works. A few of us have commercial products that depend on it as our core message bus engine. Any radical changes will not be loved The openfire-api.jar file is however a great idea

However, a new Openfire JavaScript API with JSON based messaging based on Nashorn or even NodeJs would be most welcome and open up Openfire to a new generation of developers. Now, that would be most welcomed as it allows us to reduce our server-side development costs and take Openfire to places beyond XMPP.

1 Like
11

We don’t ship plugins as part of the main product, so I’m not considering them currently.

12

No, it sounds like Mavenizing isn’t achievable. So let’s aim to do that after branching. That’ll please @Guus der Kinderen anyway.

13

‘Jan 2016’

Are there any updated libs which might cause issues for plugins?

14

Yeah, I’d rather go that route for a next-generation admin UI as well.

15

We ship the search and admin plugins with the main product.

16

Sorry, I don’t understand. Why isn’t it achievable? Which branching?

17

Sorry, I’m being unclear. It’s not achievable within this timeframe. It is achievable longer-term, of course.

The branching is the git branch I mentioned in the draft; so post-beta.

18

Agree with Dele … I’d prefer to allow plugins to have full access to the Openfire core. We have a healthy variety of existing public plugins, and an unknown number of private plugins that would be adversely affected if we attempt to constrain the API too much. As an integrator myself, I have found that the real “secret sauce” of Openfire is its amazing extensibility. I’m happy to discuss specific refinements if there are issues (real or perceived) that need to be addressed. However, I’m not in favor of handcuffing the plugins to achieve a semi-arbitrary sense of isolation.

19

+1 to Bootstrap, which provides easier theming and a responsive UI.

Work is underway to convert Jitsi Meet to Bootstrap and this will make its way into Openfire Meetings

20

Hello. When we will have new options reporting of conversation? us-en

Quando teremos novas opções de relatório das conversas? br-pt