Other Sites
Current development on JAMWiki is primarily focused on maintenance rather than new features due to a lack of developer availability. If you are interested in working on JAMWiki please join the jamwiki-devel mailing list.

Comments:Roadmap

Contents

Email support[edit]

Can we please get email support a place in the roadmap please? -- Antony Stubbs 25-Jun-2008 19:48 PDT

Done. Sorry for the delay - I'm on vacation and out of the country until mid-July. -- Ryan 26-Jun-2008 12:52 PDT

Revert to version[edit]

Under 0.1.0, the roadmap discusses reverting to prior version from the history tab. Was that feature released with 0.1.0? -- scroco 08-Aug-2006 13:20 PDT

I'll clarify that on the 0.1.0 description. The functionality is better described on Comments:JAMWiki 0.1.0 and on http://en.wikipedia.org/wiki/Help:Reverting. Basically the functionality that was added was the ability to edit an old version of a page, thus allowing someone to revert a change by clicking on an older version, clicking "edit", and then saving the older version. At present the "rollback" capability that is available to admins using Mediawiki has not yet been implemented. -- Ryan 08-Aug-2006 13:22 PDT

DB transactions[edit]

Thought I'd move this discussion to the comments section ...

Since the topic came up, I took a closer look DB persistency, and in PersistencyHandler.writeTopic(...), lies this code (0.3.4 beta6):

        if (topic.getTopicId() <= 0) {
            addTopic(topic, params);
        } else {
            updateTopic(topic, params);
        }
        if (userVisible) {
            if (topicVersion.getPreviousTopicVersionId() == null) {
                TopicVersion tmp = lookupLastTopicVersion(topic.getVirtualWiki(), topic.getName(), params);
                if (tmp != null) topicVersion.setPreviousTopicVersionId(new Integer(tmp.getTopicVersionId()));
            }
            topicVersion.setTopicId(topic.getTopicId());
            if (Environment.getBooleanValue(Environment.PROP_TOPIC_VERSIONING_ON)) {
                // write version
                addTopicVersion(topic.getVirtualWiki(), topic.getName(), topicVersion, params);
            }
            String authorName = topicVersion.getAuthorIpAddress();
            Integer authorId = topicVersion.getAuthorId();
            if (authorId != null) {
                WikiUser user = lookupWikiUser(topicVersion.getAuthorId().intValue(), params);
                authorName = user.getDisplayName();
            }
            RecentChange change = new RecentChange(topic, topicVersion, authorName);
            addRecentChange(change, params);
        }

A successful addition of a new topic would call addTopic(), addTopicVersion(), and addRecentChange(). But those activities are not contained in a single transaction. If addTopic is successful but addTopicVersion fails, the work done in addTopic will not be rolled back. -- scroco 29-Sep-2006 10:26 PDT

Actually that entire sequence is contained in a single transaction, but the fact that we need to support file persistency makes it a bit hard to follow exactly what's going on. In database persistency mode, initParams() gets a database connection and returns it in an object array; in file persistency mode initParams() does nothing. See DatabaseHandler.initParams() for the database-specific implementation. That database connection is then passed to each method - addTopic(..., params), addTopicVersion(..., params) - and the connection is not committed until releaseParams(params) is called. If any failure occurs then handleErrors(params) is called, which rolls back the transaction.
The code is a bit obfuscated, but hopefully by dropping the FileHandler class it should be possible to clean things up a bit to be more clear. -- Ryan 29-Sep-2006 10:35 PDT

Right. Now I see it. I missed the fact that writeTopic is overloaded. The writeTopic(...) I was looking at is always called by writeTopic(Topic topic, TopicVersion topicVersion, ParserOutput parserOutput) which handles the transaction properly. Thanks for the clarification. -- scroco 29-Sep-2006 11:09 PDT

Latest setup.jsp from SVN[edit]

Instead of getProperty() the method must be renamed to getValue(); otherwise setup.jsp won't compile.

...
 <option value="<%= DatabaseHandler.DB_TYPE_MSSQL %>"<%= Environment.getValue(Environment.PROP_DB_TYPE).
...
Thanks, I'll get that fixed shortly. -- Ryan 30-Sep-2006 10:54 PDT
I didn't realize that this bug was included in JAMWiki 0.3.5. I've released JAMWiki 0.3.6 which fixes the problem. -- Ryan 04-Oct-2006 16:05 PDT

Alternate Setup[edit]

Archived from the Feedback page:

Due to my database needs, I want to set up the database and JAMwiki settings by hand, as opposed to running through the automated setup. Can you make the SQL schema available for download? Or even better, make the source available for download other than through subversion (I don't run subversion and have no desire to do so). -- scroco 27-Jul-2006 12:50 PDT

I've uploaded the JAMWiki 0.1.0 source to http://jamwiki.org/jamwiki-0.1.0-src.zip. Out of curiosity, what is your use case for wanting a script-based setup? If it's something that might have general use then I'd be glad to look at implementing it. I'm not sure exactly how it would work best, but it should be possible to provide a script-based install where JAMWiki could either be automatically installed via a web interface, or else a script could be run to install things and then the web interface install could be bypassed. In any case, if you're willing I'd be interested in hearing what exactly you want to achieve and then see if support could be built into JAMWiki. -- Ryan 27-Jul-2006 13:00 PDT

Thanks for posting the source. My situation involves the way we have set up our database security, we have an admin user that owns tables (e.g. "admin_user"), and various other users which access the tables, each with different access rights. So I don't want to create tables using the same user that will be accessing them. And further, when querying them, I'll be prefacing the table names with the owner name (e.g. admin_user.wiki_table). I'll probably need to modify the source to accomplish that. Do you have any plans to externalize all the SQL into a properties perhaps? Or do you plan to support EJB architectures? -- scroco 27-Jul-2006 14:10 PDT

It shouldn't be too difficult to move SQL into properties files, although the caveat for anyone who changes those properties is that you would need to update those properties to match your schema after JAMWiki updates. The case for a "database owner" vs. "database user" is a good one, and I'll add that to the Roadmap, including the possibility of a script-based install. As to plans to "support an EJB architecture", I'll admit to not really looking at EJB's in several years - when they first came out my thought was that it was a lot of extra code for not much benefit, but things may have changed. If you have ideas or suggestions regarding EJB usage please share them, and if there are advantages I'd definitely be interested in exploring them. Thanks for the feedback! -- Ryan 27-Jul-2006 14:27 PDT

Cleanup[edit]

This page looks much better after the cleanup, and the removal of the Changelog items. Thanks! -- Ryan 25-Jul-2007 21:46 PDT

Keeping an eye on jsr170?[edit]

Archived from the Feedback page:

In the road map it is mentioned that you keep an eye on jsr170.

The first time I saw this specification I thought it would be ideal for a wiki. It has import/export, versioning, access control, xpath queries etc... All you need for the data-side of a wiki. Any change of being the first wiki to have this jsr as a base? -- [Kees]

It would be great if JAMWiki added support for that specification, but at the moment it's fairly far down on my list of priorities - not because it isn't a priority, but because there are so many important things to do. It's always possible that someone else may start working on it, but otherwise I suspect it will be a while before JSR-170 is supported by JAMWiki. -- Ryan 20-Dec-2006 23:50 PST

captcha[edit]

Not sure whether this should be in the list for 0.6.x since it wasn't approved, but it seems urgent: captcha needs to be an option in the permissions system since "require captcha to edit" is a permission level

credits[edit]

Credits for authoring also need not to be hardwired but instead to be part of BottomArea and easily removable or customizable (more or fewer names, etc.); You don't want silly pseudonyms to have to be displayed, or lots of IP numbers; It's also not correct to call all non-real-names "anonymous" since often someone responsible knows who they are and this might be legally thorny. If one associates all bald IPs with the tag "anonymous", fine, but it is just as important to be able to put another tag on specific ranges or lists of IPs.

Also, block IP and ban user should not be confused. One implication of this is that users should be able to claim specific IP numbers as themselves post-facto, and that a much softer, easy to challenge and undo, way of associating IP numbers with an identity or "user" might be required (though it's probably better to associate them with a faction that might only have one person in it).

many saving errors[edit]

For some reason edits to this page are especially likely to result in this error:

"An unknown system error has occurred. The error message is: java.lang.Exception: Failure while executing insert into jam_topic_version ( topic_version_id, topic_id, edit_comment, version_content, wiki_user_id, edit_type, wiki_user_ip_address, edit_date, previous_topic_version_id ) values ( ?, ?, ?, ?, ?, ?, ?, ?, ? )."

It's been seen at least a dozen times on this page alone.

Preferred solution among commercial users?[edit]

Not just yet! You write that you want to make jamwiki a preferred solution among commercial users. The most important features to reach this goal are, based on my experience, LDAP-integration, user-rights based on LDAP-groups and a wysiwyg editor. I would like to see theses three points in your roadmap for upcoming releases. I work for a large german car manufacturer and we are searching for a new wiki-solution.

The major development planned for the 0.7.0 release is an upgrade to the next version of Acegi, which should vastly improve LDAP integration. As to a WYSIWG editor, that's been requested by a number of people, and I suspect that someone will eventually contribute patches to integrate one of the many Javascript editors out there into JAMWiki. The software will continue to improve, so given time it will eventually meet the need of large companies as well as that of small companies and individuals. -- Ryan 08-May-2008 08:07 PDT
Hi Ryan, thanks for yout answer and for your work on JAMWiki as well! I'm looking forward for the 0.7.0 release to test LDAP integration. The WYSIWYG editor is not my favorite feature, but my boss likes this. The only things i really need is a way for editing tables and integrating images in an article in a more simple way. The wiki syntax for tables and images is the biggest problem for new users. For Mediawiki there is an FCKeditor extension that works for me, and i hope that someone will migrate this to JAMWiki. Is there an extension mechanism in JAMWiki?
The current release does include basic LDAP support, and there have been success reports, but I don't use LDAP personally so I can't verify how well it works; the new Acegi version should make it more flexible and robust. As to extension mechanisms, that's something that's been implemented slowly, but a full implementation is most definitely in the long-term plans. Since the first release the syntax parser has been a plugin, it's fairly easy to switch out the search engine, etc, but there isn't yet an "official" plugin mechanism. We're getting close, and each release makes it a bit easier, but I'm hesitant to implement anything until either someone comes along with a really good implementation or else the code reaches a point where the best solution is obvious. The problem with plugins is that once you support them you can't change the API, so I'd prefer to move slowly before getting stuck with a sub-par implementation. -- Ryan 13-May-2008 09:15 PDT

When will the production release happen?[edit]

Archived from the Feedback page:

Hi Ryan,

We are using JAMWiki for a quite a long time. Apart from the bugs i have posted we don't face much problems in it. We are expecting the production release of JAMWiki soon. Can you tell when is the production release planned for JAMWiki? Also some of the bugs remain unfixed. Particularly the DB2 issues and the setup issue. Really had good experience working with JAMWiki. Thank you.

--yesesnono 12-Nov-2007 02:53 PST

Thanks for the positive feedback! The DB2 issues are actually problematic - I tried downloading an evaluation version from IBM, but it requires XP Professional, which I don't have on my laptop. We use XP Professional at work, so one weekend where I'm feeling particularly motivated I'll set up DB2 and try to resolve the remaining problems.
In terms of a "production release", I assume you mean a 1.0 release? The current code should be solid enough for day-to-day use in a production environment. Initially I figured 1.0 would happen when JAMWiki implemented all major Mediawiki functionality, including the ability to import and export topics from one system to another, send email notifications, use , etc. Lately, however, work is keeping me busy enough that I can't put in the time necessary to focus on a roadmap of major features, so I've just been bumping the sub-major version number whenever a significant update is made to the software (example: 0.6.0 included significant changes to user authentication and authorization). As a result, 1.0 may actually mean "four more major updates to the code base", and wherever we're at when that happens will be 1.0. Aside from the psychological value of a "1.0" it's not something I worry about too much, but if others have opinions please add them, and if changes to versioning are needed then they can definitely be considered. -- Ryan 12-Nov-2007 08:20 PST

JDK6-Migration[edit]

The scheduled end-of-life of JDK5 was at October 30, 2009. Is there any plan of Migrating to JDK6? -- 80.156.24.165 25-Aug-2010 08:25 PDT

One of the major reasons for upgrading to Java 5 was that it introduced several useful features - generics, autoboxing, enums, etc - that added significant benefit to the project. In addition, many supporting libraries that JAMWiki uses were upgrading to Java 5, so in order to use those libraries an upgrade was needed. That said, since JAMWiki will work with newer JDKs, and since the most interesting changes in Java 6 seem to be speedups in the JRE (which people can use without breaking Java 5 compatibility in JAMWiki code) there doesn't seem to be as compelling a reason to upgrade. Is there a specific feature you wanted to use? I'd like to see JDBC 4.0 support, but that doesn't seem to be a compelling enough feature to warrant dropping support for Java 5. -- Ryan • (comments) • 25-Aug-2010 09:03 PDT

WYSIWYG / 0.8.0[edit]

Archived from the Feedback page:

When do you expect Ronins WYSIWYG editor to be integrated?? aka when is 0.8.x being released?

Ronin's FCKEditor code installs and runs without generating errors for me, but for some reason the Javascript doesn't seem to be initializing and thus no edit functionality is available, so until that gets resolved it won't be integrated. I'd definitely like for this functionality to be included in 0.8.0, so odds are good it will eventually get completed. As to when 0.8.0 is ready, I'm a bit hesitant to commit to a release schedule, although I was hoping it wouldn't take much longer than six months after the release of 0.7.0 until 0.8.0 was out. There's a lot of good stuff already committed on trunk, so it's conceivable that the goals for 0.8.0 will be scaled back and a release will go out around August with whatever is ready - take that with a HUGE grain of salt though as JAMWiki releases have always taken longer than expected. -- Ryan • (comments) • 11-May-2009 18:36 PDT