|
just thought i'd share some HTDB roadmap thoughts,
prompted in part by a small "ah-ha" raised while
watching ben write a DSO text filter this afternoon.
ben wrote a simple DSO (as they all are: string
in/string out). this particular DSO took lines from
a buffer and spit out those lines appropriately formatted
for javascript, thus:
input string:
${javascriptDocumentWrite(
random line of HTML
random line of HTML
random line of HTML
random line of HTML
)}
output:
document.write("random line of HTML\n");
document.write("random line of HTML\n");
document.write("random line of HTML\n");
document.write("random line of HTML\n");
|
in effect, this is a simple filter, just as my silly
"morse" code filter is.
ok, so that's where this monologue begins. now i'll
share some concrete plans for the future.
eventually, i'm going to change the language such that
it can support alternate methods of calling functions -
so as to make the language more "tag-based". the above
example would, in this future world, be used thus:
input string:
<javascriptDocumentWrite>
random line of HTML
random line of HTML
random line of HTML
random line of HTML
</javascriptDocumentWrite>
output:
document.write("random line of HTML\n");
document.write("random line of HTML\n");
document.write("random line of HTML\n");
document.write("random line of HTML\n");
|
know that "javascriptDocumentWrite", or whatever the
"function" name is, will always translate to a C DSO
function named "dso_javascriptDocumentWrite()", which
takes one argument (whatever is found up to the ending tag),
and returns a single string - the affected input string in
most cases.
what can we do here...
imagine the following scenario:
-
in the future, we might no longer store HTML
in *.htdb files, but instead XML would be stored.
-
in such a world, we need to *somehow* convert
XML into something usable by a browser. sounds
like a great use of another filter function, huh?
input string:
<xml2html>
random line of XML
random line of XML
random line of XML
</xml2html>
output:
HTML
HTML
HTML
|
or, suppose we have access to, say, a PERL intepreter
library, we'd just need to have a DSO wrapper to call
the PERL interpreter:
input string:
<perl>
perl logic
</perl>
output:
the final evaluated perl string
|
whoa. or even a java interpreter. or a SQL interpreter.
HTDB then simply becomes a method of raw content management
and a way to "glob" crap together. nothing's stopping
the "DSO functions" from actually being, say, wrappers
to tuxedo library calls and, presto - instant distributed
application.
then there's the planned language extensions - true
function scripting (done), tag definitions, and logic syntax
changes in *.htdb files:
#define fetchUsername(user_id)
<sql(usr:select username from user
where user_id=${user_id})/>
${usr->username}
usage: ${fetchUsername(1)}
output: "xing-at-htdb.org"
#define <docTitle>
<head>
<if (defined(author))>
<meta content="author"
description="${author}">
</if>
<if (defined(title))>
<title>
${title}
</title>
</if>
</head>
usage: <docTitle title="bubba's document!">
output: "<head>
<title>
bubba's document!
</title>
</title>"
usage: <docTitle author="bubba jones"
title="bubba's document!">
output: "<head>
<meta content="author"
description="bubba jones">
<title>
bubba's document!
</title>
</title>"
|
the following is then possible:
-
nothing will be (wastefully) evaluated except
when used == big-ass speed.
-
*all* resources can be considered "cachable" -
at startup, ALL resources may be sucked into
memory.
-
or, all resources can be stored in the database.
-
at that point, a true "resource server" may
be written - specialized resource editors
could be written to manipulate resources.
imagine web-based resource editing instead
of *.htdb textfiles.
-
at that point, we're damned close to a true
"realtime publishing system"
i'm real excited about the future of this stuff, obviously.
just hope it all comes to pass before i die.
del - 08:58 PM 9/8/00
|
![[home]](http://htdb.org/images/blank.gif){kind=small}
Ramblings