Future WML Directions

Hi all!

OK, so I've done a lot of work on the site to make it more standards 
compliant. In the process I switched it from a recursive building system that 
I couldn't quite understand to a more centralized GNU make-based system, and 
also placed somethings in Subversion.

However, one things I'm unhappy with is that the design of the site itself 
feels very old. The current stylesheet is at the moment bloated with many CSS 
styles, and the various arrangement of things on the page may have looked 
well in the late 90's but not now. So I think it would be a good idea to 
revamp it in this regard, making it less old. The old navigation menu, that 
was based on buttons, and recently converted to CSS-buttons, will probably be 
replaced by a more modern nav-menu; the various coloured frames on the page 
will be replaced by something better. The images as titles will be replaced 
by <h1>, <h2>, etc. headers with CSS styles. Etc.

Other things I'd like to do:

* Converting to SCons instead of Autoconf
------------------------------------------

I really came to loath Autoconf. It is absolute brain-damage. I recall the 
time when I tried to use libtool, and realized that a support for it was 
dropped from Autoconf 2.1x and I had to upgrade everthing for Autoconf 2.5x. 
This is just one of the problems I encountered with Autoconf/Automake/Libtool 
countless of times, and they seem to break more often than not.

I implemented the Latemp build and install system using SCons. It took me some 
time to get right, but probably less than the time it would have taken me to 
write it in Autoconf/Automake/Libtool in the first place. I was also 
impressed by the elegance of SCons and how easy and non-idiosyncratic it was.

So that's what I'd like to do.

* Modernising the APIs.
-----------------------

The WML APIs, while sometimes useful, tend to generate extremely old and 
non-standards-compliant code. I usually tend to work around them. I already 
wrote HTML::Widgets::NavMenu which is a very nice replacement for the navbar 
API. But there are many other APIs which we should go over. (the 
Table-of-Contents API especially gave me some trouble). Possibly some of them 
should be depracated.

We may like to write some new APIs instead, and I could use any suggestions. 
If you have any self-written logic that you'd like to contribute please do. 
Just make sure you contribute it under a GPL-compatible license.

* Optimising WML
----------------

WML is slow. On my P4-2.4GHz machine it runs tolerably, but still takes a few 
minutes to compile my homepage, which is my largest site. I recall that on a 
P3-600MHz it was much slower. I believe we can easily improve its speed in 
several ways, by bechmarking, optimising and benchmarking again. There is a 
lot of room for improvement, and there's no reason it should be that slow.

* Win32 Compatibility
---------------------

At the moment, WML cannot even compile on cygwin. I'd like to make sure it can 
compile on cygwin and later on even port it to a pure Win32 system (Mingw, 
MSVC, etc.) Some people still have to work on Win32, and ignoring it is not 
such a good idea. Besides, it's probably a bug in the code. There's nothing 
in WML that warrants Win32 incompatiblity, and so we should fix it.

----------------------------

Any other suggestions? Any comments on these ones?

Regards,

	Shlomi Fish

---------------------------------------------------------------------
Shlomi Fish      [email protected]
Homepage:        http://www.shlomifish.org/

95% of the programmers consider 95% of the code they did not write, in the
bottom 5%.
_____________________________________________________________________
Website META Language (WML)                         http://thewml.org
User Support Mailing List                        [email protected]
Automated List Manager                            [email protected]