[Hypercontent-developer] HyperContent 2 build script and info

[Alex V. <av...@co...>]

Hello all,
	Though I have been somewhat preoccupied with our imminent portal 
rollout at Columbia, the HyperContent bits continue to trickle out . . 
. I have committed a simple ant script and a bare-bones content 
repository to the CVS, so if you checkout the hypercontent2 module you 
can now perform an "ant startup" and visit a simple hello world page at 
"http://localhost:8080/index.html".  While there is no content of 
interest in this project as yet, it provide a sufficient structural 
example for you to take an existing HyperContent 1.x project and port 
it into the HyperContent 2 server.  The porting steps are:

--------------------------

1. Register your project with the bootstrap project.  This is done by 
creating a directory under /repositories/bootstrap/projects, and 
creating a file called "filesystem.xml" within that directory.  This 
file should contain ONLY the repository element from your project 
definition, with one new attribute called "mount".  This indicates the 
mount path of this project on the server.  By default, the HyperContent 
servlet is mapped to the root context, so if you mount your project at 
"/my-project/"  the base url for your project would be 
"http://localhost:8080/my-project/".

2. Create a directory "config" in your project repository.  Put a copy 
of your project definition file at the location 
"/config/project-definition.xml".  The project definition resides 
within the project repository in HyperContent 2, so that the repository 
is self-describing, which will enable easier copying and moving of 
projects.

3. Create a file "/config/permissions.xml" in your project repository.  
For world read access, this will work:

<?xml version="1.0" encoding="UTF-8"?>
<permissions>
	<permission principal="group:anybody" activity="read" target="/"/>
</permissions>

You can also assign permissions to users, who are defined in the 
bootstrap project.  The pattern for adding users is to put them in a 
path like "/repositories/bootstrap/users/u/us/username.xml", where the 
last two directories correspond to the first and first two characters 
of the username.  See the demo user file for an example.  
Authentication is done via JAAS, so you can plug in another 
authentication mechanism.  The user files in the future will be 
primarily intended for storing user preferences.

4.  Run "ant startup", and visit your web site.  Note that directory 
listings and/or automatic index page mapping are not yet implemented, 
so you will have to enter the full  URL of a file.  Your web site 
should behave just as it would if you performed a build under 1.x, but 
now it is served dynamically.  The only catch is that options 
configured in the Build options editor are not currently supported - 
I'd like to get a feel for whether people use these options, as I am 
considering deprecating them.

--------------------------

What is going on under the hood?
	HyperContent 2 is acting as an HTTP 1.1 server; it is able to map 
incoming requests to rendering pipelines based on  your project 
definition; if the pipeline is not a simple pass-through, the rendering 
is cached to disk.  The dates of both the disk cache and the user's 
browser cache are compared with every request against a recursive 
dependency analyzer, so that content is immediately flagged out of date 
when any dependency is modified.  The maximum latency of last mod date 
changes is configureable in the hypercontent.properties file. 
HyperContent 2 also GZIPs content if the browser supports it, and 
caches the GZIP version to disk.  Disk caching is handled by Berkeley 
DB Java edition, which is based on the fast Java NIO in JDK 1.4, and 
which has a configureable memory cache for frequently accessed content. 
  Templates for not-found, not-authorized, auth-required and error 
screens are also provided in the bootstrap project, and can be 
overridden by any other project.
	Pipelines are matched on five components: base-directory (used to 
create virtual directories for presenting alternative forms of output, 
such as text-only), base path (repository path without file extension), 
file extension (used to define the content type of the pipeline 
output), permissions, and "mode", which is a special parameter.  Modes 
are used to define non-cacheable views of data, and are primarily 
intended for interactive components such as authoring tools.  These 
modal views will also NOT be able to be built and published in batch 
processes; they are intended only to come from the HyperContent server 
itself in real-time.
	Authoring tools are going to be developed as component modes.  For 
example, you might have a directory browser mode and a WYSIWYG mode, 
and you'll be able to present a page with both tools by creating a 
composite mode.  A simple way to do this is using a Velocity template 
which uses the include directive to load the URl of the page with 
different mode parameters.  These include requests are handled 
internally, without going back out over the network.
	A new form handling framework is also in development which will allow 
for the mapping of form inputs to unique keys which are bound to 
objects, so that multiple form-based tools can be composed into a 
single page and submitted via one form, without losing track of where 
each input goes.  This will also allow the determination of idempotency 
to the level of individual inputs, as a key->input mapping is invalid 
as soon as all references to the input backing object are let go by the 
authoring tool to which they belong.  A Mersenne-Twister based unique 
ID generator is used to guarantee uniqueness of these keys within a 
JVM; they are represented as 10 character strings built from a 62 
character set ([0-9][a-z][A-Z]), with up to 2^ 59 possible values.


What's next?
	The form handling framework will be developed in conjunction with the 
porting of one or more authoring tools from HyperContent 1.4 to 
establish proof of concept.      This should be done in the next few 
weeks. The biggest remaining challenge after that will be a new 
workflow-based publication engine which will allow more control over 
how batch-processing is done that was possible in v1, from automatic 
build and publish to a remote server on save, to several stages of 
approval or automated content validation components.  Once that code is 
built, a new project-definition grammar will be built from the ground 
up to make it easy to leverage more of the advanced features of 
HyperContent 2; backwards compatibility for 1.x project definition 
files will be maintained indefinitely, as that logic is cleanly broken 
out into a separate SAX ContentHandler.


Regards,
	Alex