On Apr 20, 2004, at 5:02 PM, Christopher Armstrong wrote:

Pavel Pergamenshchik wrote:

...

On Tue, 20 Apr 2004 16:04:50 -0400 Christopher Armstrong wrote:

...

So it's officially counted :-) ::

-------- Original Message -------- Subject: Re: [Twisted-Python] Sub-project Naming Date: Tue, 20 Apr 2004 12:47:45 -0700 (PDT) From: Jeremy Noetzelman To: Christopher Armstrong

FWIW, tmlabs.* has my vote! Metoo!!!@#one!#@! This seems to the least unacceptable of the offered solutions. FWIW, I feel strongly about avoiding "cute" names for (web, news, mail)-level packages. I'd rather see twisted.ssh than twisted.conch, but I suppose that needed a distinct name for the client executable.

Well, if we go with tmlabs.*, then we won't need to worry about this. All packages will probably just keep their current names (barring special cases like im/words integration. We'll probably just call that 'words' and put all IM protocols there).

I'm +1 on tmlabs as well, but I'm unsure about the cute names. On one hand, it's harder for a new user to figure out that (a) twisted does ssh and (b) it's named conch.. but on the other hand, if you say conch, people know you're speaking of a specific implementation of ssh, where if it was called "twisted ssh" it might cause some confusion in that regard. I think PuTTY, SecureCRT, Transmit, etc. do a fine job of marketing themselves as protocol-specificish applications without explicitly mentioning which protocols they support (which is probably more of a bonus, because it's future proof). So because there are good reasons either way, I say we just stick with the cute names -- but maybe try a little harder to market them to new users. An idea would be to have a "protocol matrix" document that is easy to find from twistedmatrix.com (no more than 1 click away from the front page, but it could almost be the front page) that is a table of wire protocols <-> implementation names with perhaps a note about their stability and completeness. -bob

Cory Dodt wrote:

Bob Ippolito wrote:

| On Apr 20, 2004, at 5:02 PM, Christopher Armstrong wrote:

| | So because there are good reasons either way, I say we just stick with | the cute names -- but maybe try a little harder to market them to new | users. An idea would be to have a "protocol matrix" document that is | easy to find from twistedmatrix.com (no more than 1 click away from the | front page, but it could almost be the front page) that is a table of | wire protocols <-> implementation names with perhaps a note about their | stability and completeness. | | -bob

+1

I just like the cute names because they are more google-friendly.

I'm not even concerned with "cute names" vs "descriptive names". I think they should stay what they already are wherever reasonable. -- Twisted | Christopher Armstrong: International Man of Twistery Radix | Release Manager, Twisted Project ---------+ http://radix.twistedmatrix.com/

On Apr 20, 2004, at 6:57 PM, Glyph Lefkowitz wrote:

On Apr 20, 2004, at 5:23 PM, Bob Ippolito wrote:

...

An idea would be to have a "protocol matrix" document that is easy to find from twistedmatrix.com (no more than 1 click away from the front page, but it could almost be the front page) that is a table of wire protocols <-> implementation names with perhaps a note about their stability and completeness.

Bob, this is a _great_ idea. Do you think you could do a first pass? :)

No ;) -bob

I've been passing around instances of pb.Copyable classes for some time, registering them via pb.setCopierForClassTree()... However, this doesn't allow me to pass the classes themselves. I dug around in jelly and found jelly.globalSecurity.allowInstancesOf(), which seems to do what I want, but makes me nervious as it's pretty buried... Passing classes seems like a reasonable thing to do, but now I wonder if there is some reason that jelly doesn't allow it (except via a buried method call)? Or is this just an accidental misfeature? -Jasper

On Wed, 21 Apr 2004, Andrew Bennetts wrote:

On Tue, Apr 20, 2004 at 04:20:32PM -0700, Jasper Phillips wrote:

...

I've been passing around instances of pb.Copyable classes for some time, registering them via pb.setCopierForClassTree()... However, this doesn't allow me to pass the classes themselves.

I dug around in jelly and found jelly.globalSecurity.allowInstancesOf(), which seems to do what I want, but makes me nervious as it's pretty buried...

Passing classes seems like a reasonable thing to do, but now I wonder if there is some reason that jelly doesn't allow it (except via a buried method call)? Or is this just an accidental misfeature?

Why not just pass the name of the class, and unserialise that as appropriate?

I'm not a PB expert (or even close), but I always lean towards passing data rather than code (or code-like things like classes) over remote method calls when I can :)

That's certainly feasible, but then I have an extra unserialize step cluttering my code as the classes passed have attributes I want to access. In general I'm passing game state which exists naturally as code, and while I could always serialize and unserialize it, why bother if I don't have to? Plus, isn't unserializing classes based upon their name exactly what jelly does? On the other hand it's debateable whether the things I'm passing _should_ be classes at all (they represent a type of terrain, with statically accessible fields describing their game effects). However, the quality of my code is really a seperate issue. -Jasper

On Wed, 21 Apr 2004, Andrew Bennetts wrote:

On Tue, Apr 20, 2004 at 05:48:00PM -0700, Jasper Phillips wrote:

...

That's certainly feasible, but then I have an extra unserialize step cluttering my code as the classes passed have attributes I want to access. In general I'm passing game state which exists naturally as code, and while I could always serialize and unserialize it, why bother if I don't have to?

That's odd, I would've expected game state to exist naturally as *data*, not code. :)

I don't think the distinction between code and data is necesarrily so clear... Basically my point was that I wasn't interested in something like XML RPC, and would rather treat remotely passed objects as if they were local to the extent possible. Using `Terrain.moveCost` instead of `unserialize("Terrain").moveCost` seems good to me.

Perhaps you should elaborate more on how you're representing things?

Ok. I'm perfectly happy to get a critique of my design out of this if I can! ;-) I'll try to keep it concise. I have a dictionary of hexes keyed by their grid location. map.cells = {(1,1):hexCellInstance, ...} Each of these cells has a .terrain, which is a reference to a Terrain subclass. These have static data and methods, for use by various game algorithms, e.g. how far can unit Foo move through Mountains. On each turn a (filtered) version of this state is passed to game clients, so that they can view it, validate their orders against it, etc. -Jasper PS I'm off to watch a movie, so won't be able to respond further until later tonight.

On Tue, Apr 20, 2004 at 04:42:46PM -0400, Pavel Pergamenshchik wrote:

On Tue, 20 Apr 2004 16:04:50 -0400 Christopher Armstrong wrote:

...

So it's officially counted :-) ::

-------- Original Message -------- Subject: Re: [Twisted-Python] Sub-project Naming Date: Tue, 20 Apr 2004 12:47:45 -0700 (PDT) From: Jeremy Noetzelman To: Christopher Armstrong

FWIW, tmlabs.* has my vote!

Metoo!!!@#one!#@! This seems to the least unacceptable of the offered solutions. FWIW, I feel strongly about avoiding "cute" names for (web, news, mail)-level packages. I'd rather see twisted.ssh than twisted.conch, but I suppose that needed a distinct name for the client executable.

+1 on tmlabs.<sane-name> Regards, Stephen Thorne

Alex Levy wrote:

+1 for me on tmlabs.<whatever-its-called-now>

+1 on this. Keep the same names. -- Valentino Volonghi aka Dialtone Linux User #310274, Gentoo Proud User Blog: http://vvolonghi.blogspot.com Home Page: http://xoomer.virgilio.it/dialtone/

On Tue, 2004-04-20 at 18:57, Alex Levy wrote:

On Tue, 2004-04-20 at 17:53, Stephen Thorne wrote:

...

+1 on tmlabs.<sane-name>

+1 for me on tmlabs.<whatever-its-called-now>

+1 on tmlabs.<same-names-i-like-calling-it-conch> -p -- Paul Swartz (o_ pswartz at hampshire dot edu //\ Box 1286, x5248, AIM: Z3Penguin V_/_ GPG Key: http://stout.hampshire.edu/~pks03/public.key