Way to go ST/X![Also I dont know whether this is JIT, or compiled to m-c performance.]I think that it might be interesting to have a ST/X version, but I doubt
speed will be a good reason for this. What makes Swiki a lot slower than
Apache is not Comanche/Squeak. It's simply that it is fairly
sophisticated in how it renders data dynamically. That dynamic part takes
80-90% of the time. So, improving web serving speed by 100%, will only
have a negligible 10% increase in speed.Peace and Luck!
Je77
Indeed I understand where you are coming from, forgive me if I indulge myself with some blurb as to what I am hoping to acheive.
I have started a project for my company to auto-generate swiki pages from my source code which is littered with 'TODOs' and 'DDD' notes (Design Decision Documentation) etc etc. The idea is that source code comments can generate specialised swiki mark up which can then be posted to any swiki via a wiki client. [has anyone done this already?] The wiki can then do the clever linking stuff and provide the users and devlopers with an easy way of collating editing, and presenting the documents. The swiki can then be rendered generating the static version of the documentation which can be provided with the product (without a swiki server).
Although it isn't really required for this task, I have always wanted to write my own light weight document parsing and document generating framework.
I have never found any other web framework that lets me have the flexibility that I would like at this level. For example in Swiki, as we have discussed before, the rendering of protocols (http: etc)and different *something* tag types is/was fairly hard wired. Another feature that I have wanted for ages, is to be able to macro inline one page into another. Wikis used as a database of snippets of useful information can be quite bitty in their content. The macro facility would really help when trying to collate reports or longer documents.
So the upshot of this is that I have started working on a parser doc generator that could potentially be a generic pluggable replacement for the generation of a variety of data transitions.
originalSource -> swikiUserEdit -> swikiStorage -> htmlRendered
-> swikiUserEdit
One key thing about my design for the document generator is that it is stream/filter based. It should be able to process and send data on the fly. This should eleiminate as much as possible any buffering steps. To be honest I cant remember whether your later versions of Swiki try to do this.
One of the potential options for gaining further speed would be to have a source code generating version of the doc generator, allowing web pages to be compiled, even to down to the metal if one was feeling extreme about it.
Another idea that is ticking over in the back of my mind is that when this framework is in place. I would like to use it to write a Zope clone demonstrator. I think that the concepts and the architecture of Zope could be reimplemented in a couple of hours!!!!!! I feel like doing this to justify all those braincells that I killed while trying to get Zope to do what I wanted.
well I guess I better go and implement some of this stuff. I thought unit testing was cool, I am still realing in shock at how much more productivity the Refactoring Browser gives me.....
and ideas insights would be appreciated
best regards
Keith
