Re: Future WML Directions

Hi!

Just a few short comments...

On Sun, Oct 16, 2005 at 09:14:25AM +0200, Shlomi Fish wrote:
> 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.

I once had the idea of publishing some of my wml libs as awl (Axel's
WML libraries), but I never found the time to do it becauses I wanted
to do it right. :)

But I wouldn't call them API. They're more useful macros or tools.
Macros like "make that big number human readable" or "check the URLs
of all external links" or "set the class attribute on all external
links to X". Somehow I think, such tools should be distributed
independent of WML but there should be a kind of easy to use package
manager. Not as complex like CPAN or dpkg/apt :-), but some tool which
just installs a "package" so that it's in WML's search path and can be
used with #use. In think of something like "wml-package-install
awl.wmp" or so...

But regarding the API, someone already asked me recently, if there are
"plugins" for e.g. some Wiki syntax for WML. (Although I wouldn't use
WML together with some Wiki syntax, the idea is not that bad IMHO.)

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

Oh yeah, and not only wml but also wmk. :)

> WML is slow. On my P4-2.4GHz machine it runs tolerably,

Hmmm, on my P1-133MHz it runs tolerable — for single pages. ;-)

(BTW: The box made me to use slices more often than several small
pages with one common big include file. :-)

> but still takes a few minutes to compile my homepage, which is my
> largest site.

Yepp. This was also always a problem with the web front end for WML I
once wrote to be able to start the generation of WML based web pages
of my former employer by colleagues who hadn't a unix account. IIRC
the server was an Ultra 10 with half a gig of RAM.

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

Just a feeling, but a very old and still present feeling: WML seems to
be slow in a kind which feels independent of MHz or GHz. Faster
computers don't make WML faster the way they make gcc faster. There
seems to be another thing which slows WML down. Memory? Forking? I
don't know, but WML's speed just doesn't seem to follow the processor
speed in a linear way.

> * Win32 Compatibility
> ---------------------
> 
> At the moment, WML cannot even compile on cygwin.

Really?!? Cool! (SCNR ;-)

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

Full Ack.

P.S.: Your mail suggested to me, that I should update my talks a
      little bit regrading developement activity and future plans. :-)

		Regards, Axel
-- 
Axel Beckert - [email protected] - http://abe.home.pages.de/
_____________________________________________________________________
Website META Language (WML)                         http://thewml.org
User Support Mailing List                        [email protected]
Automated List Manager                            [email protected]