an essay
Berylium is essentially at 1.0-- I want to re-gif the icons and clean up some of the docs, but with spellcheck finally in place, the last obstacle on the milestone has been cleared.
Where do we go from here? The plans for 2.0 are, unfortunately, no less ambitious.
Layered Rendering Engine for HTML
On the display side, two big concepts I've been flirting with are gridded layout (a la rooms, where objects are positioned on the page at will) and hiding non-essential bits of the editorial interface to cut down on clutter. If you wanted to find out the editorial details of an object, you could reveal the hidden details layer with a click. I can imagine how the whole edit form might come in alongside the rendered object, but that's yet another context to load.
What I'm thinking of is more along the lines of advanced publishing controls and a properties listing that can be revealed for any object on demand.
One way to go might be to make object rendering more object-oriented. Heh. So that getRuntimeVars() (which is called on just about every displayed object) gives you these:
$this->properties
$this->content
$this->ownercontrols
$this->publishercontrols
$this->clipboardcontrols
$this->children
$this->parent
$this->multiselect
That last bit about multiselect is a checkbox for lists that allows the user to perform actions on multiple objects. It's desperately needed for publishing actions, which you know if you've ever wanted to delete a bunch of documents. But it should also work so that you can use it to set up a playlist or pickup a bunch of images at once.
Actually, it sort of makes sense to build the multiselect form in the session as you go, and then render the whole form as an overlay-- a layer with a high z-index. The only way you could pull that off is for each object to know exactly where it will be rendered on the page. Possible. It makes me shake my head, but modern browsers are up to it.
The layered scenario goes something like this: instead of building the webpage with tables, we build it with divs:
Site is layer 0A layered interface would need to have its own format so that the five people out there who still use unmodern browsers will be able to fall back to more vanilla HTML. For now we'll call it .dhtml format.
Navigation is layer 1
Session is layer 2
Sitemember is layer 3
Object is layer 4, and contains:
Properties (4.1)Object Children are layers 5 to n-1
Content (4.2)
Owner Controls (4.3)
Publishing Controls (4.4)
Clipboard Control (4.5)
Parents (4.6)
Multiselect Form is layer n
Site Customization
It simply must become easier to create new sites that don't look the same as every other Berylium site. Part of this is simple pragmatic changes like putting CSS into a separate file so that it can be generated dynamically or maintained via FTP, completely separate from the logic. You should also be able to specify default icons for all the object types so that you aren't stuck with the Berylium icons.
Another thing that will help is dynamic flavors: on the create and edit forms, the default is to show a pulldown that lists all the known flavors in the site, plus an option to add a new one. Selecting that option should reveal a hidden layer that allows you to specify a new flavor, which will then be included in subsequent pulldowns.
Another thing that will help is better policy integration: if you want to let members add images in a folder, then all you should have to do is add or change an explicit policy for that folder.
Another thing that will help is additive construction of policies and contexts. If all you want to affect with a folder-based context is the template, then the processing, CSS, and header/footer should come from contexts that are less specific. There has to be a way of preempting the inheritance, of course: perhaps the context parser allows a context to consist of a "template" record only.
A/V Objects and Playlists
It's well past time we got some audio/video objects going. Now that you can run QuickTime on Linux (via Crossover) there is a standard player to develop for. Playlist operation goes something like this (unless the player is smart enough to preload clips on its own...):
Download and play first clip (as current-clip)
On current-clip-load, begin downloading next-clip
On current-clip-end, refresh page to next-clip
Since next-clip was already cached by the browser, it should play immediately... loop
New C/BML Tags
BML in particular needs to be site-dependent, and probably even format dependent. I've considered using contexts for BML, but it seems like such a slog. Perhaps there is an easier way.
There needs to be a tag that looks like [random:objtype;attributes;method], as well as a BML [list:objtype;attributes;number;method] tag. And the CBML list and index tags just plain need reform to make them enforce policy by default and to allow paged lists by default.
File Objects
All publishable objects need to have file capabilities, and Berylium needs to be tied in with FTP/Fiatlux so that image collections can be uploaded, video files can be transferred via FTP, etc.
A generic file object class needs to be created so that unsupported filetypes can still be served via Berylium (and hence, Berylium could swallow Fiatlux whole cloth).
Locks and Keys
In addition to the general access control provided by roles and policies, objects should be accessible via read- and write-keys that can be generated by the object owner and given to trusted users in order to allow types of access that would ordinarily be forbidden by policy.
Keys could also be generated by the site provided certain conditions are met, such as the presentation of an electronic signature on a license or proof of purchase (or both).
Role Reform
It's still a little difficult to get your head around roles because they don't yet work consistently, especially from site to site. There's something wrong with the model of anonymous, member, writer, editor, admin; or maybe these groups just aren't well-defined enough yet. What's needed is the flexibility of a ranking system with the categorization of named roles.
What I mean is, wouldn't it be nice if you could just say "Well, if your writerank is higher than an object's rank, you can edit it. And if the object's rank is higher than your readrank, you can see it. Thus creating a ceiling for editing and a floor for viewing.
By Chris Snyder on January 4, 2003 at 1:14am