[Twisted-Python] I was looking for offhanded ways to improve us.
glyph at twistedmatrix.com
Sat Apr 28 18:39:14 EDT 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
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
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
1.1.0: Rudimentary relational storage of Things, Radix's config interface.
Finished version of Inheritance, packaged separately. Batteries not
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
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
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
______ __ __ _____ _ _
| ____ | \_/ |_____] |_____|
|_____| |_____ | | | |
@ t w i s t e d m a t r i x . c o m
More information about the Twisted-Python