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). -- KenLiu

!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:
#Create a minimal skin that hardly shows anything else but the HTMLized Wiki-page
#use something like [wget|] to get this page on disk
#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|WikiRPCInterface] 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:

# We don't want to be dependent on a third party.
# 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.
# We can provide here, in our own server, practically all the services SourceForge has.  And be in control of those services as well.
# Those services that SourceForge has that we can't duplicate, are actually not that important to us.
# 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.
# 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.
# 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|ContributingChanges] without SourceForge.

--[JanneJalkanen], 10-Sep-2002.