[Twisted-Python] I was looking for offhanded ways to improve us.

Glyph Lefkowitz glyph at twistedmatrix.com
Sat Apr 28 16:39:14 MDT 2001


Looks like 0.9 has been quite a while in coming.  The Rt. Hon. Rev. Short and 
I have been discussing lots of interesting ideas for improvement of twisted 
reality; I quite some time looking at Squeak and considering strategies for 
adopting Smalltalk to improve the reliability of the core, but eventually 
gave up.

It looks like the strategy for insulating the game engine from unstable code 
is going to be server distribution; much like twisted web allows multiple 
users to run untrusted (except for the fact that gloop sends pickles, but 
this is an implementation deficiency not a design flaw) web servers on the 
same machine, I think that the central "reality reservoir" server on Zaibach 
will allow users to install doors to their areas.

I also think that there's going to be a small paradigm shift in TR's approach 
to game code; I think that twisted.reality was attempting to be 
unrealistically game-agnostic.  The core will start to make a few more 
assumptions about things like inventory, damage, and containment.  The 
supporting "bulky" code (containing big string and tuple constants et. al.) 
will continue to live in twisted/library/, but I don't think it's possible to 
elegantly encapsulate anything meaningful in such a bare-bones simulation 
that's currently twisted/reality.py.

I've written a draft "official twisted python coding standard", currently at

	http://www.twistedmatrix.com/users/glyph/standard.html

Comments, corrections, and pointers to inconsistencies in the existing code 
will be welcomed, but if anybody says anything about NerdyCaps, I'm going to 
break some teeth.

And finally, I'd like to see some discussion of a release strategy, as 
charming as "whenever we get around to it" has been :).  I recommend 
something like this (note that I don't put dates next to *anything*...

	0.8.5: the fixes which are currently in (CGI, refactorings to Twisted 
Reality, swing faucet, etc), preliminary demo code, segregation of 
Inheritance into a separate package, "dead" protocols directory.

	0.9.0: "live" protocols implementation, used by at least .web (hopefully 
.gloop too); full, publicly running TR demo (assuming also some more 
improvements to the TR core, some more library functionality).

	0.9.1: Simple distributed TR server.

	0.9.2: Distributed TR server + SSL certificates.

	0.9.3: Postgres protocol client, asynchronous DB API spec.

	0.9.4: Some sort of relational storage for TR objects (?)

	0.99.*: Writing tests and hammering the heck out of what we've got, adding 
minor features and polish to TR and the TR demo.

	1.0.0: unit tests for everything.  Media firestorm, we take radix's leash 
and dash and I run the mop-up operation in-character in the TR demo :)

Here, there's some speculation as to whether we should do a fork to "stable" 
and "unstable" versions of TPy.  Any thoughts?  Further #s here assume such a 
fork doesn't happen.  These are more of an overarching plan than specific 
functionality.

	1.1.0: Rudimentary relational storage of Things, Radix's config interface.  
Finished version of Inheritance, packaged separately.  Batteries not 
included.

	1.2.0: "dict" protocol client and server for TR.  More and better of the 
config interface.  Meatier back-end for mail handling, real mail server 
(perhaps integrated with PMS?)

	1.3.0: better Faucet, perhaps with PyGame.  Start of work on 
_Inheritance_II:Acquisition_, which has a "massively" multiplayer "mode" as 
well as the multi- and single-player modes.  (This will, in truth, be a 
different game, set in a similiar but much larger world.)  The game won't be 
a strict sequel, but more in the way that Beyond Zork was a Zork sequel.

	1.4.0: Fairly complete inet.d replacement: pop3, imap, telnet, talk, ident, 
IRC client-compatible server; all implemented with Moshe's protocols 
framework.

	1.5.0: 100% for-real relational storage of TR objects, finished version of 
the schema and extensibility mechanisms for that schema.

	1.6.0: Peer-to-peer TR additions; each client is a server too.  Finish 
_Acquisition_, beginnings of serious work on an even larger game.

	1.7.0: _Inheritance_III:Collection_, single-player only, but a testbed for 
features used in a larger game, mostly those which involve automatically 
generating large areas.  If we do spatiality, here's where it gets exercised.

	1.8.0: generalizations of peer-to-peer framework and trust web, to do 
something like mojo nation.

	1.9.0: Robustness improvements.  netcat from /dev/urandom to a gloop or 
twisted.web socket fails gracefully.  I go to jail for a year because of 
features released with 1.8.0.

	2.0.0: Full implementation of CORBA, NFS, XML-RPC, SMB, SSH, and NTP, all of 
which are TR-aware.  Javascript interpreter.  Enterprise.  Highly concurrent 
resource control for multi-user Python.  Moxie.  Green eggs.  Appleshare 
server and client.  Ham.  X font server.  Kerberos.  Zephyr.  CODA.  built-in 
remote debugging.  Completely transparent python-relational interface with 
syntax additions built using MobiusPython.  Kitchen sink.  Bathroom sink.  
Implement "corridors" before Lilo gets around to it, move OPN to 
twistedmatrix.com.  _Inheritance_IV:Subtype_Polymorphism_.

	2.0.1: Internet.

	2.0.2: Divunal.

-- 
                      ______      __   __  _____  _     _
                     |  ____ |      \_/   |_____] |_____|
                     |_____| |_____  |    |       |     |
                     @ t w i s t e d m a t r i x  . c o m
                     http://twistedmatrix.com/users/glyph





More information about the Twisted-Python mailing list