I am now inclined to handle docs using the webserver. This means inventing another document language the webserver can translate, but it can be tailored to our needs. The output can also be saved to make static pages, provided the issues with links are sorted out.
Now this leads to a nice idea. Interscript gained its power by containing executable code in a high level language (Python). Now we want to include a scripting language in our documents .. the obvious choice is Felix. Note: this is server side scripting. Conceptually, the webserver could call the felix compiler to generate executable code and run it to get some HTML output which it then sends to the client. We would then have the chain of executables: flx --> flx_arun -> webserver --> flx --> flx_arun -> user script assuming dynamic linkage: control is passed by system, ld, system, system, ld respectively.. which is a bit of a long chain .. so .. why not build flx_arun into the flx program so it can load shared objects it compiled directly? Come to think of it .. why not build the *webserver* into the flx program? Not a bad way to get help: flx --webserver=1234 runs the webserver with the install dir as document root on port 1234, so all you need is to point your browser at it. Now in fact, this also brings up another idea I have had for a long time: to monitor program execution using sockets. Basically traces, debugging info, etc gets sent from the program to the monitor which then sends the information on via the webserver to your browser. One BIG advantage of this idea is you can multiple browser windows open to monitor different aspects of the program. Another BIG advantage of having a built in webserver is it makes it easy for the client to write webserving scripts of any kind, such as, for example, a content manager or shopping cart. Why is this better than using PHP or Ruby? Well apart from the control inversion thing (using fthreads) and of course the high performance .. remember Felix is a *statically typed programming language*. There's a good chance your script will actually work if it compiles. Web site are notoriously hard to write because you have to run the scripts to find the bugs, and there's nowhere to send the debug information. Anyhow .. back to finding the finalisation bug :) -- john skaller skal...@users.sourceforge.net ------------------------------------------------------------------------------ Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
