FYI: we're thinking of using Python (and ultimately Zope) to facilitate an online authoring environment for the new, "open source" Graph Evaluation Language (GEL) project. I'm forwarding the following note (from GEL's lead engineer) in the interest of discovering where Python, Zope, and GEL might *collide* in a beneficial manner. If this post is inappropriate for this list please let me know and I'll refrain from overstepping the bounds in future. Regards, Ray Thompson <rayd@90068.com>
From: "Mike Roberts" <mike@swirl.com> Subject: Media distribution (was RE: Biota: Biota 3 Followup) + Python questions Date: Tue, 16 Nov 1999 23:38:25 -0800 Reply-To: rayd@90068.com
This is a very long piece of mail.
I have a very dumb question about Python ... What's the size of python without it's file i/o libraries and other (seperable) things ? The source a few megs - reasonable. Given the ease of interface to C++ exhibited, it would not be hard to produce a python binding for gel, and this is clearly a desirable thing for many applications.
There's issues of not having certain functionality available for outside access (obviously you can't have stuff in a widespread distributed environment without some form of security mechanism, or the environment might be a little TOO viral and propagate in ways which are undesirable to the host machines ;)). There's also issues about connection to the gel interfaces/objects, but since we are in C++ I don't think these are hard, and the even python license is compatable with the gel license. We've glanced at it before, but getting the basic graph based multiprocessor stuff and graphics going has been of more importance, and a very large project in itself. It's more a question of whether anyone wants Python working with things :) badly enough to do the work.
What's possible is to install the Python (or Elk) interpreter into a dynamically loadable binary module for gel, connecting in the same way the geometry plug-ins currently work (Peter and I are working on extending this for behaviors now, so our interface is bidirectional). Fundamentally, I still think dynamic graphs are the best possible way to go for very small foot print distribution and efficiency of rendering things like textures, and especially for consumer boxes like the PS2, but other langauges are certainly interesting and have paradigm coverage graph languages don't, so the combination would be very interesting. More on this in a bit.
The way I am thinking this would work would be that you would download chunks of Python into the downloaded Python engine (which sits in a binary plug in for gel); essentially force feeding Python via gel to the python interpreter. I have no idea how well that would work, so perhaps one of the python people could let me know. If I have a buffer of python in whatever form, in C++, is putting it into python easy ? This would have the advantage that you'd be able to use the same working communications harness to control a bunch of other machines. It would not be necesary to have Python running on all the gel machines, instead you could use one python machine as a controller to control parallel execution of Gel on a bunch of machines. One Python-gel machines it would run in parallel with other things like Physics sims affecting the matrix of binary plug-ins in gel. (This feed principle is how you get gel to do a video wall effect by having of a number of machines viewing a virtual world simultaniously).
We've thought about using Elk in a similar way, mainly because using scheme or similar opens up the gamut of established AI techniques, and I think it's important to leave these languages as a development choice, as they are now, ie, attach to a lot of them. Putting them in loadable modules works, but not every language is as flexible as python.
The main issue from my point of view (not necessarily that of all biotans) is having a good distribution story for content - I have to be concered with this since we are trying to make something ubiquitous which will run for all people, not just those with the motivation to load and install something big and/or unweildy, but down to the level of getting pretty much everything they need to run a world using control in a page and having the rest streamed to them. Since the various interested corporate parties (Sun/Sony/Microsoft, etc) are locked into a distribution war, this currently means a small executable bootstrap "player" which you can sneak in as a piece of executable web content, and which is viral enough to be capable of loading more of itself and establishing a self sustaining distribution mechanism (which is some of the reasoning behind peer-peer). Right now I see that as < 1Mb, for the base case. It's really a question of which medium you choose for your art, and how widely you plan to have it seen. It's the reason flash is successful and VRML is not.
Next bit is not per the discussion above, but intended to give an easy way for people to play with Gel. We hope to have a gel browser plug in with server side scripting using the scripting language (dumb, but functional) sometime in the next month or so, so you could use Python, TCL, etc, to generate this language and pipe it to a Gel world and view it. Thus you can model an alife world on a server and have a lot of different views of it on clients. The textual form of the language looks like this (and is the same stuff which is in default.gel if you have the distribution) :
Nurb.new NAME "TheUFO" UUID "6184a9004fe711d38bf70080c75cdbc5"; TheUFO.setUrl URL "http://www.gel3d.org/ss1.1ur"; TheUFO.setUrlShaders URL "file://www.gel3d.org/ss1Materials.mtl"; TheUFO.setPosition XYZ Vec3f 71.924194,69.475967,0.000000 ; PointLight.new NAME "PointLight0" UUID "3775ace255a511d38bf7-0080c75cdbc5"; PointLight0.setIntensity XYZ Vec3f 0.500000,0.0200000,0.000000 ; PointLight0.setPosition XYZ Vec3f -75.636734,346.116150,281.291260 ; Timer.new NAME "Timer0" UUID "5c144565566e11d38bf70080c75cdbc5";
You'd stream this to a gel machine via our udp layer, or it will be able to request it via http.
Text gel is pretty much ready for streaming - all of the functionality has been distributed out into the object set, at least for building things. Eventually this goes to byte codes and compact numeric representations for streaming efficiency. Other things are done by establishing connections in the graph and between machines :
Conversation.new NAME "Conversation0" UUID "7dfd1747573811d38bf70080c75cdbc5"; Conversation0.setAddress IP "180.244.253.24"; EdgeMaker.new NAME "FilerEdgeMaker"; FilerEdgeMaker.createByName FROM "TheUFO" FROMPORT "button1On" TO "Timer0" TOPORT "toggle"; FilerEdgeMaker.createByName FROM "Timer0" FROMPORT "output" TO "CircleGenerator0" TOPORT "receiveEvent";
As I mentioned, all of this stuff can be sent dynamically using UDP or TCP, so the first stage would be to get something running which was capable of streaming text gel to a gel machine from python or other similar language running on a server. I hope to provide a C++ stuff module for use in Python or elsewhere to do reliable UDP streaming in order to get this going. Dan's working on peices of this now, mainly dealing with horrible low level UDP buffering issues.
I have heard of a thing called SWIG as being useful for this kind of stuff.
--m Mike Roberts, 7f.com, www.gel3d.org
-----Original Message----- From: biota-errors@lists.best.com [mailto:biota-errors@lists.best.com]On Behalf Of Daniël van Gils Sent: Monday, November 15, 1999 2:24 PM To: biota@lists.best.com Subject: Re: Biota: Biota 3 Followup
Try this,
http://www.foretec.com/python/workshops/1998-11/proceedings/pa pers/asbahr/asbahr.html
Daniel van Gils