fractalnavel

[sorry for the ej reference there ;-)]

ok, i think it's finally begun to sink in: remote scripting, scriptlets, behaviors, script components, windows scripting host, even the vsa interface, all seem to be dead and dying technologies.  of course, some of those have very clearly been dead for years, subsumed into other technologies, or at least renamed.  primarily, however, they fall into two categories: script components, and script hosting.  script components have been implemented in evolving ways over the years, pretty much ending up encapsulated in dhtml behaviors in their latest incarnation.  their wider use has been severely handicapped by the lack of any but the default handful of interface handlers, and the reason for that is that documentation was never released on how to write those.

as for hosting environments, wsh 5.6 was the latest release from microsoft, and only supported pre-.net technologies.  at the time people were gushing over what we would find in the next version: .net support, and all that that implies.  and there was also a lot of excitement in the scripting community over vsa, which was a much more robust way of exposing an applications innards for extension by end-users using scripting.  other common script “hosts” were ie, and asp, and sometimes ms office.

well, none of this came to pass.  in fact, the excitement continued until it just suddenly vanished from the windows landscape.  a few primitive .net script-like hosting applications have been produced by the open source community, and at least one proprietary one, but they don't really compare to the type of script hosts one might expect from the originator of the technology, microsoft.  i can imagine the faces of all these enthusiastic script people at ms, being told their baby was dead.

and this seems to have happened sometime in 2001 (the decision seems to have been made earlier; one can infer from the articles of the preceding year that support had already been yanked).  nothing has happened since then in the script world.

i've seen a few speculations here and there that it may have been for corporate marketing reasons.  who knows.  i just think it sucks.

i really like scripting: its portability, its speed of development cycle, it transparency.  i think that applies to the many folks who did asp too, even if they didn't explicitly think of it that way.  now, aspx code-behind-page/forms is fine - but that should be left at a script-level as well, with compilation optional.

perhaps this is all related to com disappearing from the landscape as well.  regardless of implementation, however, the functionality represented by com is still required.  and this is only peripherally related to scripting.

and so we will have avalon and indigo and winfs (winfx?) - whenever longhorn shows up.  what will be the scripting support analog at that point ?  because for now, all these system admins and other IT type folk have relied on scripts and batch files and other command line tools to take care of their jobs for - well, since the beginning.  and many of the administrative interfaces in the windows universe are not exposed through gui's.  so they are left with an adequate but aging utility technology, one that is being left in the dust.  leaving a good chunk of operations out of the .net world of benefits seems silly.  or is that one of the motivations ?

depends on microsoft's vision, i suppose.  the real vision, not the babble they sell us.

so perhaps it's time to let scripting go, for a while anyway, and open up the compilers and ide's once again.  talk about being chained.  talk about proprietary interfaces.  soon we'll be “compiling” xml, xslt, soap and so on.  and the cycle will begin again.

“mommy, what's that ?”

“why, that's script, honey.”

“what's script ?”

“well, once upon a time, anyone who wanted could program a computer.”

“ 'program' ?”

“yes, child.  they say that's what the wizards now do, in their towers with their expensive machines.”

“can i program, mommy ?”

“shh, you might be overheard.”

... i finished the majority of the categorization of prior posts.  go figure.  had an interesting time dredging up old memories of ms access programming.  just the old ins & outs that you get with experience that lets a person do a lot with the available interfaces with no programming at all.  anyway, i offloaded the blog data into an mdb, created all the categorization records here, the appended them back to the database.  no bumps, burps or sniffles, all went smooth.  just like old times ;-)

of course, the ten categories i ended up with have a lot of overlap and fuzzy edges, so almost all of them contain a large number of posts.  but when browsing the list in each category, it's clear that major threads of thought were captured.  kinda cool, in a way.  it looks like a few things may have been missed in some categories, but every post now shows up in at least one group.  this should make digging through archives much easier.

odd that categories don't show up when viewing individual posts, like they do on many (most?) other blog engines.  another shortcomings of the “skins” - because they really aren't.  also, the database is a bit screwy in places, improperly normalized, unused tables, that sort of thing.  but it's small and thus easy to figure out.

as a side note, i also found it's very easy to grab a copy of the blog database this way.  i was looking for a simple way to mirror it, and the sql import/export tool would do just fine.  i could even automate within the db itself, if appropriate firewall holes could be opened without exposing security flaws.  but that would probably best be done over a vpn connection or something else encrypted.