[Zope-Moz] some thoughts about zope-moz and some really blue sky stuff

[Martijn Pieters]

From: "Jake Kauth" <jake@market-channel.com>
> hey all
>
> i've been thinking about zope-moz has going for it and have been
> blue-skying a bit.
>
> first of all, i hate the web.  all this
> HTML/CSS/DOM/Java/Javascript/CGI/Database
> stuff is INSANE.   to render one pretty page with javascript "waveovers"
is
> a
> nightmare of language-inside-language-inside-markup!
>
> whoever thought of this Web thing anyways?  the whole idea of stateless
> programming is a horrible thing!
>
> nowadays, everything we do as programmers gets so convoluted by layer
after
> layer
> of markup languages that building scalable net-based applications has
> become a nightmare!
>
> anyways, that's just how i feel about the thing :-)
>
> so here's some blue sky stuff i'm been thinking about as zope-moz moves
> forward:
>
>  - embed a python interpreter in the mozilla.  (do the "java" thing and
> let's work on
>    getting python "out there" and ubiquitous.  of course the same security
> encapsulation
>    techniques would have to be applied to the python interpreter, but it
> can be done.
>
>    java sucks.
>
>    propietary bad.  open-source good.  open-source is INSIDIOUS.
>
>    we can slowly infiltrate the browsers with python programming without
> having ot
>    worry about market-share and deadlines.
>

Except that I will miss my deadlines on Mozilla, because I don't have the
foggiest idea on how to accomplish this. I'll leave this kind of thing to
the experts. Could you find me some? =)

>  - given that we have a python interpreter in the browser, we could in
fact
> embed a
>    zope server in each browser, or at least a "ZopeRPC" server.
>
>    (a zope-style server has the benefit of encapsulating objects rather
> than
>    functional-style RPC calls, but the idea is there)
>
>  - then we get rid of the "stateless" style of browsing a web site by
> opening up
>    objects in both the server and the browser, which talk to each other
>    in a stateful way, without cookies
>

Sounds like a nice idea, but it would kill performance _big_ time. Any
server can handle only a limited number of connections. Because stateless
connections pass away again, you can serve many clients in succession.

>  - now we bind our business logic loosely with the presentation of a site,
> so that we
>    can change page design quickly and easily.
>
>    this is a zope capability already, but i'm talking about moving a lot
> more
>    of the heavy lifting out to the browser end of the browsing process.
>

Strangly enough, this is what the whole Javascript, DOM, and CSS spiel is
about. Mozilla does a damn good jon of implementing that, supporting it as
proper seperate files as wel.

> basically, i see the zope-moz effort as a way to develop better zope
> applicatios.  but it
> seems the talk has been about zope-moz as a *developer's* aid, and not a
> lot of talk
> about rolling this technology out as something to be used by the end
> users.

Zope Mozilla will indeed be a developers tool. Because Mozilla is *a*
browser, expecting that  one piece of software to be installed on the users
machine raises the bar for what you can use it for.

>
> could an entire python interpreter be installed as a plug-in?  since we
> have
> python for every unix, mac an PC out there, what's to prevent us from
> having python as
> an embedded language in the browser, and available for remote-object
> invocation
> from the client side?  TCL has a plugin for the major browser, why can't
> we?
> or has this been done and i haven't seen it?
>

You can use Python in Internet Explorer already. The ActiveX Scripting
system is quite powerful, because it exposes the browser object model to
scripting languages.

The TCL plugin only lets you embed a TCL app into a webpage, not control the
webpage itself.

> most real web applications have a lot in common with the end products of
> traditional rapid-application development GUI developers.  perhaps the gui
> objects of a
> web page should be represented as an entirely new GUI programming API?

That is what XUL, the GUI language of Mozilla, is all about. That is how we
build Zope Studio.

>
> i think it should be possible to write a program in the style (and ease)
of
> tkinter, and to simply have the remote display part of the application
> appear in the browser, without getting caught up in the whole
> stateless-programming
> mess that is the Web of today.

It is however the statelesness that has enabled the web to scale.

>
> Jpython goes a long way, but it would be nice if we could have the native
> widgets
> available via Tkinter.
>
> am i insane?  is there any technology doing this already out there?  is
all
> of
> this part of the DOM support in python?

No, Python's DOM suppor is about document manipulation in a Python program,
not access to the browser DOM. The browser will have to expose that DOM, and
then someone will have to write a binding.

Mozilla's XPCOM architecture goes a long way towardsthis, and some day
someone will connect Python to Mozilla, (or any other language even..). But
until the, I have to stick with what I've got. And with Mozilla, that is
very very powerful.

Martijn Pieters
| Software Engineer    mailto:mj@digicool.com
| Digital Creations  http://www.digicool.com/
| Creators of Zope       http://www.zope.org/
|   The Open Source Web Application Server
---------------------------------------------