[Atomos-discuss] Half a pound of tuppenny rice, half a pound of treacle

[Bryan E. <for...@gm...>]

Weirdbro:
> Bryan, thats some nice JS code. I can't do anything nearly that useful. I
> did do some metaprogramming to get the Process system working, and thats
> probably the best JS code you can find for me.

Ooh, can I see?  Processes, locks and mutexing are something I'm only
peripherally familiar with, and they seem like interesting work, espeically
in a lax environment like JS.  Link me?

Scott:
> I'm familiar with the quirksmode site.  Lol.  'Been visiting it
> on-and-off for years.  Definately good to have a x-browser developer
> on board who's familar with some (of the seemingly zillions of)
> browser quirks.

There's really not that many; it really just comes from knowing how
different implementations of a given object/function/element/style will
behave, and you only really notice them when a page acts all wonky on a
given piece of work.  By and large, things work well together; the trip-ups
are few and far between, but just common enough to be irritating.

Scott:
> How do you see the seperation of the project components?  I'd like to
> delve into this topic deeper - it could have a serious impact on the
> way the project is developed.  I've had some difficulty organizing and
> documenting; suggestions would be more than welcome.

Well, there's the standard application model for development, except for one
thing: there's also a client-server comms model that should be handling a
bunch of stuff.  Essentially, there should be a base API with a number of
sectioned-off functions, like windowing, file control and the like.  There
should also be an asynchronous communication (AC) library for talking to the
server.  The API should probably also have an IPC method for communicating
with other applications the user has permission to talk to (not, mind you,
necessarily in the same context; it should be able to use the AC lib to have
the server talk by proxy to clients running in different contexts).

Additionally, there should be a simple metaphor to handle things like
finding out what devices are connected to the remote system.  Determining
how to play sound or video, as another example, should be transparent to the
application writer (ie: locally if the terminal is the local computer, via
Quicktime and streaming if it isn't and the client is firefox, via an embed
if it's IEx, etc.).  I'm thinking on how to make the event model operate
uniformly as well, but give me time and experimentation, I'll get it done.

Essentially, if we want anyone other than ourselves building applications
for this system, we have to make the programming process both easy and
painless.

Also, we need to have certain 'base' widgets, such as:
Your normal window widgetry, like labels, text inputs, timers, etc.  HTML
handles most of these by itself, so little work there.
Things like an HTML frame (with callbacks), a rich editor, etc.  An OS is
less than a shell without some standard interfaces.

I'm thinking most of the API could be built into a single object
(Application, or something similarly innocuous).  Because of the nature of
Objects in Javascript, it can be built over the course of several different
files, each covering a different object, and thus, a different aspect of the
API.

Documentation shouldn't be hard, just tedious; implement each method and
document what it does and where it could be used.

Application GUIs should be built in HTML as groupings of DIV elements, and
such, with CSS for positioning and stylization, but not directly included
(ie: include the Window as a div style='display: none', and copy its
contents out via DOM to create an instance).  Well, that would be the best
way, but it doesn't always work, so normally we'll just toss it into an
innerHTML, link in the behaviors, and pray for workingness ^_^.

An unfortunate thing about IE is that it doesn't play well with 'custom'
tags.  For example, <window>Some innerHTML</window> confuses IE to the point
that the tag gets registered with the DOM, but not it's innerHTML - and the
ending tag throws an error.  As a result, our predefined UI tags should be
of the form <div class='window'></div>