You could probably get a huge performance gain without changing any code—if it’s presently well behaved and scoped—just by going persistent with running it. This is mostly how everyone does it and why understanding prior art is so important and will save you much more time than it costs to learn. Template::Toolkit and Catalyst are both fairly slow for example. Catalyst is all but useless run as CGI and TT2 compiles and caches itself to improve performance and only resorts to recompiling from the original templates when they have changed. Even the check interval for changes is tunable.

Run any one of your CGIs like so and visit it at port 8080 on whatever host–

starman --listen :8080 -MPlack::App::WrapCGI \
  -e 'Plack::App::WrapCGI->new( script => "your.cgi" )'
[download]

• Plack
• Starman
• CGI::Compile
• Plack::App::WrapCGI
• Plack::Builder
• Plack::App::CGIBin

IMNSHO, one should not claim to be a genius even if he happens to be (and sorry I am pretty sure you are not) and if he/she does, he/she should expect his/her geniality to be put to a test. You came here preaching your uber-genial miracle without even being able to explain what the heck it is. What did you expect?

Thank you for your answer. My code is not yet to be shown to anyone (will it ever be?) but I'll work on it, I'll try to improve functions commonly expected in the field (data management) and one day, as soon as I feel confident enough, I'll ask for evaluation.

I may seem a little sleepy, but I did not understand yet the ins and outs of your work. Is your system comparable to CMS, as Drupal or Moodle? What is your intention? Are there new kinds of web interactions that you wouldn't like to disclose yet (making thus dialog difficult)? Sorry if I'm asking you to repeat (in few words) things already said but it's not always clear information that one digs out from old threads.

Ok the best description I have come up with yet is that it's a general purpose extensible declarative markup syntax. It has been called yet another templating system, and you can do templating with it, and I guess that is probably going to be it's most typical use if anyone uses it at all. What I'm hoping to do is make it so that you can deploy very fast PSGI etc code by building aXML declaration files and compiling them with the compiler I'm trying to build.

Some practical reasons for it to exist are :

• Seperation of concerns
• Simplicity with power
• Ease of deployment
• Portability
• Rapid development
• Simple debugging
• Easy Maintenance
• Loose Coupling
• Threaded Multi Processing

Taking these one at a time:

Seperation of concerns

Code, markup and style should be seperate. CSS is a declarative language for specifying style attributes, but not how to actually render them for example. aXML is a declaritive language for specifying server actions, and does not itself say anything about how they are to be computed. The actual logic goes in separate plugin files.

Simplicity with power

The deceptively simple syntax of aXML allows for reasonably complex and expressive declarations to be built up from optimised primitives. When the compiler is built a system declared in aXML could I believe result in an optimised PSGI application being produced.

Ease of deployment

Generally an aXML programmer would simply create declarations using the existing plugins. It's possible to create complex systems with currently only minimal need to write any custom Perl code.

Portability

The syntax strongly promotes modular code and code reuse, such that once the code for a given directive command has been designed, if it's placed in the main plugin folder, it's available to all the documents using the system, instantly and completely dynamically. You could completely change the engine under the declarations for another one and the application would be unaffected as long as the replacement was 100% compatible with the standard. Thus systems built out of aXML declarations are completely decoupled from their compiler and operating system environment.

Rapid Development

Given the ability of the syntax to perform templating functions new systems can be setup in very short lengths of time. Once a declaration is built it can be reused in new projects.

Simple Debugging

Since the declarations are built out of reused plugin code blocks, if a declaration doesn't work it's very likely to be the declaration that is wrong and the simple syntax style makes it easy to spot errors.

Easy Maintenance

Having been through a nightmare of repeatedly having to refactor code which was not designed with clear seperation of concerns in mind, I know that maintainability is vitally important and must be considered from the beginning of the project. By separating the markup and declarations from the code which runs the site right from the get go, your making life easier later. It's also possible to use aXML declarations as an ORM such that your application would be unaffected should management decide to go with NoSQL after all. (You just update the plugin code, or drop a different plugin into it's place.)

Loose Coupling

The aXML declarations provide only an abstract description of the server actions, and do so in a modular way. The individual components are completely oblivious to each other and thus can be swapped and changed as required.

Threaded multi-processing

Now this is where it gets controversial, but I'm happy to go out on a limb and suggest aXML declaration based systems have advantages on a multi-processor threading system.

According to the Declarative Programming Wiki, QUOTE: Declarative programming has become of particular interest recently, as it may greatly simplify writing parallel programs.3 END-QUOTE.

The citation given for that : http://www.cse.unsw.edu.au/~pls/damp09/

I personally believe that the stucture of aXML will lend it self to a multi threaded approach, however I am not yet well enough versed in either perl or threading/forking application design to utilise that potential.

All right, I think I understand better now.

If you already have a valid declarative language of your own, why wouldn't you try to make a (Cpan) module to control the correctness of any such code?

Then people could test your compiler on an experimental site, discuss various versions and bring their help or even propose their own compilers.

Anyway you are right not to let you depressed by bitter criticism.