[Squeakzilla subtitle: The dinosaurs did die out you know]
> be interested to know how your progress goes with your project. If
> you go the "plugin" route, or if that doesn't satisfy your needs, where
> you go next.
>
> thanks for keeping us informed,
>
> brad
This is a muse...a dream... or a rant... take it as you will. (p.s. I am 
now a carer as my day job so I don't really know what I am talking about 
since I have been out of touch with coding and particularly squeak for a 
while so do feel free for correct me or update me if you want to)

Since everyone is doing scary specs these days. ( 
http://www.whatwg.org/  this site is what motivated me to thingk this 
way!) I think the first step is to informally spec out the desired 
solution a bit.

If we do this spec and it looks worthwhile then perhaps Todd could get 
some VCs (see his blog) to pay for it to be coded by September when I 
need this website to go live ;-) 

Plug-in looks like the only way:

We could do a thin client (like the Avi demo mentioned earlier) in which 
case there are plug-ins for the likes of VNC available. This would not 
handle multi-media at all well so given that I want to piggy back this 
into the browser world the plug in route looks like the only viable way. 
The aim could eventually be to be able to dump the browser container 
using some native widgets (thus saving several hundred Mb of memory/disk 
useage, and lots of CPU cycles), but I guess thats a way off. Instead 
the browser (mozilla etc) is sufficiently "extensible/hackable" that we 
can probably wangle whatever we need through their hooks.

Ubiquity:

The lazslo people have targeted the flash plugin as a runtime in order 
to get ubiquity, and now they are targeting DHTML, impressive I have to 
say, but IMHO its still hard work, and in the last three days of getting 
my head around the tutorials I seem to spend half my time hunting 
through the bug reporter and filing bug reports. I think that the 
firefox missing plugin search should help us a lot with the ubiquity 
issue, and since we all have broadband these days we don't mind the odd 
30 Mb download. Now if we can get a few vm carrying Apps released into 
Application space (sophie?), ubiquity might not be so difficult after 
all, Acrobat managed it with a basic file viewer app after all, and 
Seaside could be distibuted as a webserver, CMS platform, to get the vm 
onto servers. Is the vm in any linux distros as standard? Half the stuff 
I load when I install linux I never even look at, so it shouldn't be 
hard to get distributed if we really try hard enough. (does the linux 
kernal need a vm?) Of course the whole idea of spoon is that at some 
point the size of the distribution could be quite small, and easier to 
sneak in to places.

Goals:
1. Antidote to the feature bloat hotch potch technology collage that the 
web web2 is threatening us with and the plethora of learning curves.
[The web has a several models, and several versions of models and 
standards, and versions of standards, with their formats markup, 
editors, validators, etc for storing data statically on filesystems, 
data transport to load it into a browser, a second model of the static 
data, now dynamic, in the browser, the DOM, and a vm with scripting 
environment to manipulate the DOM, and dare I say it a third model in 
the internal rendering engine. Instead of all of these different bits, 
lets have one model and one (or 2) vm(s) with one scripting engine and 
renderer all working together in a seamless homogeneous manner.]

2. Say no to static text files, say no markup languages, say no to XML, 
just use binary data wherever possible and direct manipulation wherever 
possible. If data models are hierarchical and nodes have attributes then 
its the same as xml anyway.

3. The result should look like the users familiar web world. Flash 
worlds are usually based upon a fixed sized display area. Documents can 
be long vertically and scroll down. Support both. (Laslo and flex are 
both Flash bound and so they dont feel quite right for this project) for 
this to work we need to escape the plug-in box, or at least look as 
though we do.

Implementation Ideas:

Serverside: Expect to have Seaside/Kom on the serverside, Seaside is 
looking to play in an AJAX world and our client will just be the 
ultimate AJAX client (the same as Laszlo is aiming to be). Seaside has 
or can do all of the authentication and session, keep alive connections 
and server push type stuff that we might need.  Of course if we know 
that our servers are going to be squeak we can optimize many things. 
Compressed data transport at a minimum. For example Lazslo uses their 
Tomcat serverlet to compile xml file that defines the app and serve the 
resulting swf flash file, they also use the server as a proxy for 
accessing many web services. I think the reason for this is that the 
plug in security model only allows contact with the originating server 
machine. We could use the server to pass messages to our plugin 
container if the direct pipe is not available (I haven't checked yet) We 
could similarly use the server to proxy other services (e.g MySql, 
SqueakMap etc). The server will be able to supply resources updates etc 
that the client might need, e.g. it could be a font server, or updated 
plugin server.

Clientside:

Say no to cookies. Have a file area for plugin use and an OODB for 
persistent client side data. It might seem a bit heavyweight but I am 
sure I can think of some useful uses for it.
Would it be possible to have a "no-save" policy like hypercard, in which 
disk based data "persisting" is transparent, and so abruptly leaving a 
web page and returning to it potentially allows us to return to the same 
state easily, just like when you are filling in a web form and you hit 
the back button the fields that you filled in are still there. The 
onunload browser event could help us persist relevant state automatically.

Clientside Display:

No markup just an object model and direct manipulation. Aim to recreate 
most of the browser display functionality and scriptability without the 
overhead of parsers etc. The first problem is the browser scroll bars, 
we could hide them and provide our own, or use theirs and handle their 
events to scroll our display region. The second option will allow us to 
be compatible with themed browsers, and looks to be the best bet (as 
long as we don't have to route the scroll events via the server)

(note: In the section below we are not trying to rewrite Mozilla here, 
just put together enough components to be able to look like Mozilla - 
remember no parsing of HTML just direct manipulation and assembly of 
components. You can do the parsing of HTML if you want to but I dont)

Panels can provide the equivalent of html divs, they can be manually 
positioned via handles in the (tweak) project builder or automatically 
positioned by your choice of AlignmentMorph type container. The standard 
paragraph flow of a typical web document would be provided by vertical 
alignment container. Within this container simple components can provide 
many of the paragraph based display elements, e.g. <ul> <ol>, paragraph 
border, paragraph background/pattern/pic/shading, before/after spacing, 
and I guess a table component goes without saying. We would need a 
richtext control, one which can provide a rectangular paragraph style 
presentation, and this may double as a styled editable text field (bye 
bye wiki syntaxes of the world). A second variant of the richtext 
control would be the equivalent of an html span element, a run of text 
over one or more lines within its container up to the next component, 
and/or the ability to insert a component inline as part of the text run.
Support mouse over, and onclick actions (drag n drop too?) on bits of 
text and components. Some links would need to be routed to the browser 
container in order to hit a normal "Mesozoic" web page. Some links would 
visually turn the page within our view in order to simulate visiting 
other web pages within a site which may or may not need to hit the 
server to retrieve more content. If the progress path though a site is 
predicable then the client may prefetch the next page in anticipation.

The idea that web pages and markup should be content as opposed to 
presentation is foundational to the way the web has evolved and what 
markup languages are all about. In a web app, our display component 
collection is likely to be a view on some form of abstract data model 
anyway, so if we need a different view on our data then we just build an 
alternative presentation. If our presentation has been authored in the 
project builder then we might want to use this content on its own 
outside of its presentation. We could ask the component tree to 
serialise itself into Xml if we wanted to and manipulate it from there, 
but we dont want to. In MVC, MVP style why not just treat this 
"document" as a Model and whatever use we have for this data, we build 
Views and Presenters that pull the data they need out of our model, 
through various queries. We can annotate the original model with node 
ids etc to make this easier, we could even emulate XPath functionality 
on our model since we are expecting our display components to be 
hierarchical. Now doing it this way we get something that XML cant do 
out of the box, not only can we pull data out of our model, but we can 
put it directly back in as well.

I remember one of the web frameworks out there sucked in its designers 
html template into an object model, then the coders  write code to 
manipulate that model into a form that included the hooks the coders 
needed. Then a code gen tool, generated code that would stream out the 
completed final html file (fast!). The important bit that made all of 
this work was to have the data in a live usable tweakable model. So I 
figure if we only have our data in this live tweakable useable form, 
then we win.

The other thing about XML and the markup languages is that we loose the 
idea of data elements having behaviour, ie. none of the elements are 
objects. Our "squeak-dom" components may potentially be objects too, or 
might be given aspects that allow them to function as objects in other 
contexts.

Stylesheets: All of the components that are used in the model should be 
skinnable, through setting attributes and thus configurable via a 
programmatic interface. A stylesheet is a script that trawls through the 
model and applies non-default styling to the elements it finds. E.g. If 
you find a list component with attribute flashy defined then change its 
bullet graphic to this one. Thus to support this stylesheet method each 
component attribute (including extents and positioning) will need a 
default value, a user supplied value, and a stylesheet applied value. 
Thus it should be possible to easily revert a stylesheet and apply 
another one.

I better get some sleep, I have 11 hours washing up to do tommorow!

Feedback welcomed, am I crazy or should we try it?

Keith
















	
	
		
___________________________________________________________ 
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine 
http://uk.docs.yahoo.com/nowyoucan.html