This is version . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

In an effort to reduce the size of the Ideas page, I've moved the ideas for features that don't seem like they'll work here. There are probably good ideas to be found here (or at least good motivation).

Nov 29, 2002 -- Having (X)HTML in the store, instead of Wiki Markup Text#

I wonder if somebody tought about reversing the logic: keeping the displayable HTML in store, and convert to Wiki Markup only when it comes to editing. This would require no calculation at display time anymore (but quite some while saving edits, because of the relinking I guess). Then I can take the produced HTML away (e.g., reading it offline or embed that "document" somewhere).

Well, and having X(HT)ML in store, any further translation into PDF or similiar would be a piece of cake (using pluggable XSLT's)!

-- BobSchulze

I don't think this would be possible as the pages are not fully static (plugins). If you want to postprocess the pages and need the HTML-output you could do the following:

  1. Create a minimal skin that hardly shows anything else but the HTMLized Wiki-page
  2. use something like wget to get this page on disk
  3. do whatever processing you require

-- TorstenH

I agree with Torsten. Storing XML is a far more complex endeavour than storing wikitext. For example, consider changes: there is no guarantee that the XML library should always write the XML out in exactly the same way, even if there has been none or little changes. You would probably need a whole new kind of diff routine.

In addition, since there already is a valid way of retrieving the contents of the page in XML (the current TranslatorReader should output pretty much XHTML-conformant stuff now - let me know if it fails somewhere), so what Torsten suggests above is quite valid.

In fact, you can even use the XML-RPC to fetch a (X)HTML-version of the page. You just need to add the XML preamble yourself.

-- JanneJalkanen, 04-Dec-2002

Move JSP Wiki to SourceForge#

Sept 10, 2002 RobertOtt

It could be an advantage if the source would be moved to SourceForge. It could attract more developers to contribute. I would be happy to contribute to JSPWiki.


This I actually considered, but rejected. There are some reasons why this current system works better for us:

  1. We don't want to be dependent on a third party.
  2. SourceForge has commercial interests, which means that there might be a conflict at some point. I've already had conflicts with Yahoo (with the EGroups merge), and I don't want to get into that again.
  3. We can provide here, in our own server, practically all the services SourceForge has. And be in control of those services as well.
  4. Those services that SourceForge has that we can't duplicate, are actually not that important to us.
  5. This server is Finnish. SourceForge lives over the pond. That alone gives us 300 ms of delay in everything we do. The way I work - I need it to be faster.
  6. SourceForge is quite unlikely to give us r00t access so that we can poke around the server and do what we want. If you're not happy with their services - well - you can only complain, not do something about it.
  7. We really don't need more developers. We are happy to accept contributions, of course, but it's not like we're dying out here :-).

You can contribute to JSPWiki without SourceForge.

--JanneJalkanen, 10-Sep-2002.

Add new attachment

Only authorized users are allowed to upload new attachments.
« This particular version was published on 13-Jan-2003 20:45 by KenLiu.