>>I don't know why you would call this dissapointing -- we're delivering >>major performance gains. > >In my experience, for understanding the html framework, there is no >substitute for reading the code. Routines like buildPageTable, getPref, and >runDirective are critical in the particulars of how they work; what >overrides what; and so on and so forth. I don't believe even the best >documentation can substitute for the UserTalk in the situation where you >are developing something that depends on the fine details in the way these >scripts operate.

I have to agree with this wholeheartedly. I tried to raise this issue on Frontier-Central, but after Matt N. and I both voiced concerns over the kernalization about HTML Suite, Winer went on a tirade about how many hours he was wasting reading mailing lists, so I let the topic drop.

But, with all due respect, kernalization is a MAJOR, MAJOR issue for me. I NEVER would have become proficient at writing macros and fully controlling my Frontier websites if I had not been able to read all the code in the HTML suite, and I have read ALL of it (and taken notes along with the way). I've also published pages while one-stepping through the rendering process (using the debugger) many times; nothing has ever taught as much about Frontier (or programming in general, for that matter) as this exercise.

Secondly, I don't believe the HTML Suite is even close to reaching a point at which it can be it can be set in stone (kernalized). There are far too many areas where the code can be improved, and many detailed suggestions have been made by various people. It seems to me as if the HTML suite is still evolving, as it should be, and that kernalization will stunt its growth before it reaches maturity.

Personally, speed has never been an issue for me with the HTML suite, even when I was working with a Centris 650. The only speed issues that have concerned me is the general slowness of the GUI on slower machines. (Working on the Centris 650, it can take a few seconds just to open a long outline, and navigating through the ODB is a painfully slow process. But publishing page is not bad at all.)

Finally, the openness of the HTML suite is one of the major reasons I use Frontier for web publishing and, in fact, it's even a selling point for my clients. An open (unkernalized) HTML suite means that my web work is not dependent on Userland, and this is a VERY important point to me and my clients. Few want to publish 100s or 1000s of pages with a system which is fully dependent on the whims of the software author. That openness, the ablility to tweak, refine, and debug when and if it's necessary, is a fundamental strength of the HTML suite, and one I'm not willing to part with.

Unlike Jeb Bateman, who stated that he's still using Frontier 4.2.3 for most of his web production needs, I'm thoroughly into Frontier 5 and have published several sites with it. However, kernalization is such an important issue for me that I would gladly stick with 5.0 (unkernalized) as opposed to upgrading to a version which has hidden the inner workings of the HTML suite from my inspection. I depend on it too much.

>>To me, kernelizing the html suite, which was built collaboratively, something >>that the community has been constantly optimizing, extending, >>scrutinizing and >>learning from, looked like an attempt to get people out of the loop... to >>make >>the html framework a black box that was "none of our business to see or >>understand" anymore. > >Okay, thanks for explaining that point of view to me. I imagine you'd have >to think we're insane to spend the time on kernelization for that reason.

As a matter of fact, though I would have chosen different words, that's precisely how I felt.

>What else do you need? (I'm sure the list is longer than JavaScript and >CSS, because I know my personal wish list is longer than that.)

My number one feature request for the HTML suite: a more flexible glossary mechanism. There are problems with how the present glossary system works (which have been pointed out in detail by Matt Neuburg).

One change I'd love to the see to the glossary is the ability to store the automatic entries (added by the finalFilter script) in a separate glossary, one which I don't even have to see, allowing to keep my hand-entered glossary entries in the main (or local) #glossary tables, uncluttered but the glossary entries for each page. I have, in fact, implemented a system for doing so (which only depends on a pageFilter and doesn't change any of the HTML suite), but it is a hack, and is not fully compatible with built-in glossary mechanism.

-heath

Enclosures

None.  

Replies

None.