Keith Hodges wrote:
> [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
Keith,

I sure like your enthusiasm! I don't know how to respond to most of your
ideas because I don't understand your fundamental goal. Can you explain?

I'll tell you my basic idea: I want to be able to provide multimedia
content, as well as code to manipulate this content ,to individual
desktops where the content, and the code (I guess we could call it a
"project") is served on demand from an external server. For full
programmability, I was considering looking at the possibility of having
a squeak "plugin" that provided the basics of multimedia deployment to
the user. So, why couldn't an image be created that had the mechanisms
for multimedia/application deployment sitting on a PC, housed in a
browser, all the time conversing with an external server? Is this
something you were thinking about?

brad