Tags:
create new tag
, view all tags
Refactored from UseHtmlEditorOfChoice: -- MartinCleaver - 16 May 2001

A naive question: should we switch to Java also for TWiki developement?

Pro

  • Dinamic loading of classes = easy plugin developement
  • HUGE xml, parsing, cgi, whatever set of libraries
  • a single language for server/client developement
Con
  • re-write all TWiki
  • security issues (see GetRidOfJavaScript) Main.JoachimDurchholz - 02 Jan 2001
  • Not present on default GNU/Linux installs, additional installation hassle
  • Doesn't run in Apache, need to configure/maintain a second appserver
  • Huge resource requirements, twiki/apache uses no additional resources until you use it, having an additional j2ee server uses lots of memory just sitting there
  • Glacial development cycle: edit, compile, build archive, undeploy old archive, deploy new one, test. Perl: edit, test.

-- AndreaSterbini - 11 Sep 2000


A rewrite in Java is certainly an option. Question of effort to rewrite TWiki. Also a question how much we gain. IMO it is important to keep the low RequiredEnvironmentForTWiki to ensure a broad field of deployment. I.e. better not to rely on RMI between server and browser client when HTTP can offer the same functionality. Also, it is possible to extend the current Perl code with a TWikiPluginAPI. That could be API based or XML-RPC based.

-- PeterThoeny - 11 Sep 2000


These security issues are a big point for me.
Allowing JavaScript is like giving everybody a key to my house. If I do that, sooner or later the key will be in the hands of somebody whom I shouldn't have given it.
Translating the analogy back to reality, I expect that somebody will have some script do things on my machine that I don't want to be done. I'm pretty sure that this will be a bug, not malicious intent, but this won't make things better.

-- JoachimDurchholz - 02 Jan 2001

I totally agree with Joachim - javascript is very bad for security - to force users to require javascript, or worse, java is destroying the simplicity which makes twiki work so well. Lotus Notes web interface is full of 'good idea' java applets, javascript and XML, and its a total disaster to secure, get working over ssl or use sensibly on a dial-up link.

Long live html...

Regarding the suggestion to re-write twiki in java - why bother? Perl is excellent at this stuff - any performance issues should be addressed with fastcgi or mod_perl, which would cover 95% of available web server platforms.

-- CrisBailiff - 08 Mar 2001

On quite a few server boxes, e.g. Linux, there is Perl support built in, while the Java support is fairly basic or even missing, often requiring a new version to be installed. As a Twiki admin, I can't quite see the benefit - Perl is quite easy to manage and is very compatible across different platforms.

But most importantly, I can't really see the advantage of switching languages in mid-stream, particularly since most TWiki developers probably prefer Perl (self-selection no doubt) - better, perhaps, to enhance a Java-based Wiki clone from the list at Wiki:WikiEngines . There are four Java-based Wiki clones listed there, and Wiki:DevWiki looks quite mature, it even includes a CVS backend.

-- RichardDonkin - 16 May 2001

According to http://www.perl.com, one of the objectives for PERL 6 is to target virtual machine environments such as the Java VM. This is needed in order to make/keep perl competitive with server side Java (esp. J2EE, etc). There are some interesting rumours that perl 6 will target the new MS dotnet Intermediate Language (IL).

-- SteveRoe - 18 May 2001

Re: ".net intermediate language" - a bytecode interpreter by any other name.


I would propose Python as the implementation language of choice. It's cross platform, clean to use and offers a variety of open source standard means of remote procedure calling, including XML-RPC and SOAP which have the advantage of being relatively broadbased defacto standards.

As for choosing Python as an implementation language, I belive it's far more approchable for far more people then Pearl or my favorite little language Tcl. There are python modules for Apache and IIS and it runs on many platforms, including Linux/Unix, Windows and even Macintosh, so there is little impediment to deployment across a variety of os's. Python also has what I consider to be the advantage of being far more OO-centric then Perl or Tcl since classes where adopted quite early in Python's development in contrast to the bolt-on approach of Perl and Tcl (please no perl flames - this isn't intended as flame bait).

The con of rewriting TWiki from scratch is offset by the availablity of a large selection of standard and 3rd party libraries, which I believe includes an rcs package.

Moving to Python opens the possibility of joining forces with the moinmoin people (http://sourceforge.net/projects/moin/) which I know at least some of the TWiki developers are aware of and who have borrowed ideas from in the past.

-- DavidLeBlanc - 19 May 2001

Personal I don't think switching languages and rewriting from scratch is a good idea. Would be better to join a WikiWikiClones development group in that particular target language and bring the TWiki interface ideas and spec to that group.

What might be worthwhile is developing perl TWiki along the lines of porting it to a POE environment so its more self-contained and completing its modularisation.

With regards to AndreaSterbini Pro's above, I wonder how perl doesn't already have all that. In the regards to the first point, I think its more a case that the structure of the code base as a whole its difficult for plugin type development. That's more a case of a design rewrite than a need for a language change.

-- NicholasLee - 19 May 2001

(For those who didn't know what POE is, like me, see http://www.perl.com/pub/2001/01/poe.html for an introduction - it's a Perl module providing an event driven Perl Object Environment, based on the concept of state machines.)

One thing I like about the current TWiki code, from what I've seen of it, is that it's very simple - it's quite easy to get into the code and trace through it when debugging. I'm not sure how POE would affect this, and also not sure that POE's state machine model is really applicable to TWiki, which is fundamentally a text and database driven application (RCS files are just a database of revisions). POE might be useful for the view/edit/preview/save state management, perhaps, but I've not looked into this.

Overall, I think any radical changes in the implementation language should be done in a new project - TWiki is quite stable, which would be a shame to lose, and evolving it to add more features (e.g. offline TWiki based on merging diffs, using a DB backend for scalability, optional Java plugins for rich text editing, etc.) is of much more interest to me than a re-write in some other language, where the benefit is quite unclear. For those people who really want to use Python, Java or whatever, why not join one of the many existing Wiki clone projects using those languages and work to add some of TWiki's features?

-- RichardDonkin - 20 May 2001

In regard to Andreas' PRO list, I seem to recall that perl already has pretty good support for:

  • Dynamic loading of classes (well pm's) - using the Stat::INC stuff
  • XML - plenty of support - check out a PM called Twig that seems to offer a good balance between performance and simplicity
  • OK - perl has no client side support - but the fraction of applications that use real Java in the client is very small - mostly javascript is the client side language of choice.

TWiki is not close to running out of road with perl - it only uses a small fraction of the existing libraries (for good reasons). I would like to see focus on building out the feature set - and not getting into another language...even if it were an open and shut case.

-- SteveRoe - 22 May 2001

Agreed - don't do it. Perl stinks as a team development language (personal opinion) but it's still the most approriate vehicle for TWiki.

  • TWiki is a server-side application, and the language used on the client side is irrelevant.
  • Client side applications can and have been successfully written in Java to interact with TWiki - e.g. TWikiDraw.

-- CrawfordCurrie - 01 Jun 2001

No! Java is good for what it's good for, but TWiki ain't in that category. I added the following Java cons above:

  • Not present on default GNU/Linux installs
  • Doesn't run in Apache
  • Huge resource requirements
  • Glacial development cycle

-- TobyCabot - 27 Jan 2004

Edit | Attach | Watch | Print version | History: r14 < r13 < r12 < r11 < r10 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r14 - 2004-01-27 - TobyCabot
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.