I really do not like that we call our "servers" "Ports". I think a much better term would be "Listener". I've talked to glyph before about this, and he's usually been too busy to discuss it with me (at least, that's what *he* says...), so here it is on the list. What's wrong with using "Listener"?
A lot of people get confused by the term "Port". When they think "Port", they don't necessarily think of "something that sits on a port, and listens for incoming connections". That's just how I understand it. Another argument against Port is that it's not only for "waiting for incoming connections" -- clients also allocate ports when they connect to remote hosts. So, even technically, Port is an inaccurate term for this class. You might find other technical details that make "Listener" slightly inaccurate, but it still just Makes Sense to most people (I'm guessing -- DavidC_, after me using the word "Port", and explaining that I'd rather prefer "listener", told me he would've immediately understood what I was talking about if I had used that term from the beginning).
So, it should just be known that I am vehemently against using "Port" for this class. If you can come up with something better than Listener (and that also *makes sense* without having it explained to me first), then that's great.
Here I am, responding to a message on the mailing list that I was too busy to respond to in chat. Those of you reluctant to use the mailing list, take note :)
On Mon, 30 Jul 2001, Chris Armstrong wrote:
I really do not like that we call our "servers" "Ports". I think a much better term would be "Listener". I've talked to glyph before about this, and he's usually been too busy to discuss it with me (at least, that's what *he* says...), so here it is on the list. What's wrong with using "Listener"?
Well, "listener" seems equally vague to me :), and in questions like this the status quo wins by default.
A lot of people get confused by the term "Port". When they think "Port", they don't necessarily think of "something that sits on a port, and listens for incoming connections". That's just how I understand it. Another argument against Port is that it's not only for "waiting for incoming connections" -- clients also allocate ports when they connect to remote hosts. So, even technically, Port is an inaccurate term for this class. You might find other technical details that make "Listener" slightly inaccurate, but it still just Makes Sense to most people (I'm guessing -- DavidC_, after me using the word "Port", and explaining that I'd rather prefer "listener", told me he would've immediately understood what I was talking about if I had used that term from the beginning).
I'd be interested to hear more feedback on this. Do folks generally think that "listener" makes more sense than "port"?
So, it should just be known that I am vehemently against using "Port" for this class. If you can come up with something better than Listener (and that also *makes sense* without having it explained to me first), then that's great.
"ServerSocket" probably makes the most sense... but then it would make sense to change everything around to sound more like the java.net classnames. I've not really been happy with the classnames in twisted.internet, so I encourage further debate...
______ __ __ _____ _ _ | ____ | _/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://twistedmatrix.com/users/glyph
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 30 Jul 2001, Glyph Lefkowitz glyph@twistedmatrix.com wrote:
"ServerSocket" probably makes the most sense... but then it would make sense to change everything around to sound more like the java.net classnames.
ServerSocket is the official Pythonic name, as in "the ServerSocket module". - -- gpg --keyserver keyserver.pgp.com --recv-keys 46D01BD6 54C4E1FE Secure (inaccessible): 4BD1 7705 EEC0 260A 7F21 4817 C7FC A636 46D0 1BD6 Insecure (accessible): C5A5 A8FA CA39 AB03 10B8 F116 1713 1BCF 54C4 E1FE Learn Python! http://www.ibiblio.org/obp/thinkCSpy
"Port" to me suggests some sort of system resource, whereas "Listener" at least connotes something is being *done*. If indeed, we are talking about a class whose responsibility it is to receive requests and handle them, then a more active name such as "Listener" (or even "server") might be more appropriate.
-----Original Message----- From: twisted-python-admin@twistedmatrix.com [mailto:twisted-python-admin@twistedmatrix.com]On Behalf Of Moshe Zadka Sent: Monday, July 30, 2001 10:55 PM To: twisted-python@twistedmatrix.com Cc: twisted-python@twistedmatrix.com Subject: Re: [Twisted-Python] "Ports" vs. "Listeners"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 30 Jul 2001, Glyph Lefkowitz glyph@twistedmatrix.com wrote:
"ServerSocket" probably makes the most sense... but then it would make sense to change everything around to sound more like the java.net classnames.
ServerSocket is the official Pythonic name, as in "the ServerSocket module". - -- gpg --keyserver keyserver.pgp.com --recv-keys 46D01BD6 54C4E1FE Secure (inaccessible): 4BD1 7705 EEC0 260A 7F21 4817 C7FC A636 46D0 1BD6 Insecure (accessible): C5A5 A8FA CA39 AB03 10B8 F116 1713 1BCF 54C4 E1FE Learn Python! http://www.ibiblio.org/obp/thinkCSpy
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
On Mon, 30 Jul 2001, Matthew Walker wrote:
"Port" to me suggests some sort of system resource, whereas "Listener" at least connotes something is being *done*. If indeed, we are talking about a class whose responsibility it is to receive requests and handle them, then a more active name such as "Listener" (or even "server") might be more appropriate.
Terms like "request", "receive", and "handle" in this context are maddeningly vague. :)
And actually, your reasoning (although inverted) is the reason I chose the word "Port". The actual Port instance does nearly nothing except to maintain state associated with the connection-accepting socket (persistently, only what numeric port it's on); the associated protocol.Factory instance generates Protocol instances, which "handle" the incoming "requests", insofar as such a thing is ever done (they convert the data into events and make appropriate callbacks to user code...)
"Listener" really implies to me that the user has to subclass it to make it *do* something. However, I'll agree that the word "listen" more clearly implies what it is that a Port does specifically, so I'm more in favor of deprecating direct use of the Port class, replacing it with twisted.internet.main.Application.listenOn(...); I've already started doing so.
______ __ __ _____ _ _ | ____ | _/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://twistedmatrix.com/users/glyph
Does anyone know how I can get the Reality Servers running on a Windows system? I have been able to get a static server working okay, but I don't know what the parameters for mkrealityserver are.
Thanks in advance for help.
ChrisH
On Tue, 31 Jul 2001, Chris Hadgis wrote:
Does anyone know how I can get the Reality Servers running on a Windows system? I have been able to get a static server working okay, but I don't know what the parameters for mkrealityserver are.
Thanks in advance for help.
It's very similiar to getting it working on UNIX. Do you have Inheritance.tar.gz or TRDemo.tar.gz from the 'reality' page on twistedmatrix.com?
______ __ __ _____ _ _ | ____ | _/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://twistedmatrix.com/users/glyph
From: "Glyph Lefkowitz" glyph@twistedmatrix.com
On Tue, 31 Jul 2001, Chris Hadgis wrote:
Does anyone know how I can get the Reality Servers running on a Windows system? I have been able to get a static server working okay, but I
don't
know what the parameters for mkrealityserver are.
Thanks in advance for help.
It's very similiar to getting it working on UNIX. Do you have Inheritance.tar.gz or TRDemo.tar.gz from the 'reality' page on twistedmatrix.com?
Yes I have. I have both of those.
The doco for mkrealityserver indicates there are two parameters: map.rpl and map.spl. This will ultimately produce a file called pump.spl. I understand this, but I don't know where to get the rpl and spl files from, or how to generate them.
Cheers, ChrisH
On Wed, 1 Aug 2001, Chris Hadgis wrote:
From: "Glyph Lefkowitz" glyph@twistedmatrix.com
It's very similiar to getting it working on UNIX. Do you have Inheritance.tar.gz or TRDemo.tar.gz from the 'reality' page on twistedmatrix.com?
Yes I have. I have both of those.
The doco for mkrealityserver indicates there are two parameters: map.rpl and map.spl. This will ultimately produce a file called pump.spl. I understand this, but I don't know where to get the rpl and spl files from, or how to generate them.
A command like 'gnusto build_map x.rpl mapcopy.py' in one of the Inheritance or TRDemo directories will create 'x.rpl' which you can use with mkrealityserver. HTH.
______ __ __ _____ _ _ | ____ | _/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://twistedmatrix.com/users/glyph
From: "Glyph Lefkowitz" glyph@twistedmatrix.com
A command like 'gnusto build_map x.rpl mapcopy.py' in one of the Inheritance or TRDemo directories will create 'x.rpl' which you can use with mkrealityserver. HTH.
This does help, actually.
If anyone is interested, I can write up some notes on how to get various aspects of TM working on Windows platforms.
Once I put the Inheritance and TRDemo directories in the right places, I was able to create a .spl file for both Inheritance and TRDemo. There was a problem with TRDemo - twisted.library is missing. Is this library available anywhere or has it been superseded? I ran the Inheritance module, and after going through some code to find the username and password, I was able to run this successfully. I am now able to move around in the inheritance game, but that's about it.
Again, if anyone is interested in docs for running any of this, I will be happy to produce some.
Does anyone know the status of reality servers?
I'm really enjoying playing around with all of this stuff.
Cheers, ChrisH
Chris, documentation on running Twisted under Windows would be an extremely valuable addition to the Twisted community. :-)
Cheers,
Jason
-----Original Message----- From: twisted-python-admin@twistedmatrix.com [mailto:twisted-python-admin@twistedmatrix.com]On Behalf Of Chris Hadgis Sent: Wednesday, August 01, 2001 5:33 PM To: twisted-python@twistedmatrix.com Subject: Re: [Twisted-Python] Reality Servers
From: "Glyph Lefkowitz" glyph@twistedmatrix.com
A command like 'gnusto build_map x.rpl mapcopy.py' in one of the Inheritance or TRDemo directories will create 'x.rpl' which you can use with mkrealityserver. HTH.
This does help, actually.
If anyone is interested, I can write up some notes on how to get various aspects of TM working on Windows platforms.
Once I put the Inheritance and TRDemo directories in the right places, I was able to create a .spl file for both Inheritance and TRDemo. There was a problem with TRDemo - twisted.library is missing. Is this library available anywhere or has it been superseded? I ran the Inheritance module, and after going through some code to find the username and password, I was able to run this successfully. I am now able to move around in the inheritance game, but that's about it.
Again, if anyone is interested in docs for running any of this, I will be happy to produce some.
Does anyone know the status of reality servers?
I'm really enjoying playing around with all of this stuff.
Cheers, ChrisH
-- This transmission is for the intended addressee only and is confidential information. If you have received this transmission in error, please delete it and notify the sender. The contents of this e-mail are the opinion of the writer only and are not endorsed by the Mincom Group of companies unless expressly stated otherwise.
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
I'd like to emphatically second Jason's comment here!
Documentation is a serious sore point of many Python projects, including Twisted, and I'd like to encourage anyone who has the time to do so to write and maintain documentation, especially HOWTOs and tutorials. (The API documentation is passable as reference material, although it too needs work.)
In addition to the Windows documentation, it might be nice to have a slightly more GUI frontend to Twisted for windows users, who don't have a very good command line interface. I really don't know where to start with such a tool though, because the GUI seems so open-ended to me, but if you can think of an easier process while you're writing documentation, please suggest that to the list.
More comments interspersed below...
On Wed, 1 Aug 2001, Jason L. Asbahr wrote:
Chris, documentation on running Twisted under Windows would be an extremely valuable addition to the Twisted community. :-)
Cheers,
Jason
and Chris Hadgis wrote:
This does help, actually.
If anyone is interested, I can write up some notes on how to get various aspects of TM working on Windows platforms.
Once I put the Inheritance and TRDemo directories in the right places, I was able to create a .spl file for both Inheritance and TRDemo. There was a problem with TRDemo - twisted.library is missing. Is this library available anywhere or has it been superseded? I ran the Inheritance module, and after going through some code to find the username and password, I was able to run this successfully. I am now able to move around in the inheritance game, but that's about it.
Unfortunately, that's about as far as we got. You can put things in things, and if you read author.py you should get a few hints as to "verbs" you can use to create things... hopefully some of the ex-reality authors can chime in here...
Again, if anyone is interested in docs for running any of this, I will be happy to produce some.
Seconding Jason's opinion, as above.
Does anyone know the status of reality servers?
What do you mean by Status?
I'm really enjoying playing around with all of this stuff.
Great to hear it! :) ______ __ __ _____ _ _ | ____ | _/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://twistedmatrix.com/users/glyph
Documentation is a serious sore point of many Python projects, including Twisted, and I'd like to encourage anyone who has the time to do so to write and maintain documentation, especially HOWTOs and tutorials. (The API documentation is passable as reference material, although it too needs work.)
I currently operate on the MacOS X architecture and if I can get Twisted working on its platform I will be more than happy to document it for further use.
In addition to the Windows documentation, it might be nice to have a slightly more GUI frontend to Twisted for windows users, who don't have a very good command line interface. I really don't know where to start with such a tool though, because the GUI seems so open-ended to me, but if you can think of an easier process while you're writing documentation, please suggest that to the list.
What about the use of Wx Windows, since it has the WxPython API extensions, that way one wouldn't have to worry about reinventing the wheel used to work with X or Windows.
On Thu, 2 Aug 2001, M.J. Stahl mjmstahl@one.net wrote:
What about the use of Wx Windows, since it has the WxPython API extensions, that way one wouldn't have to worry about reinventing the wheel used to work with X or Windows.
I hardly think Glyph's problem was the widget sets.
From: "Glyph Lefkowitz" glyph@twistedmatrix.com
[snip]
... I ran the Inheritance module, and after going through some code to find the username and password, I was able to
run
this successfully. I am now able to move around in the inheritance game,
but
that's about it.
Unfortunately, that's about as far as we got. You can put things in things, and if you read author.py you should get a few hints as to "verbs" you can use to create things... hopefully some of the ex-reality authors can chime in here...
I'll have a look at author.py tonight (hopefully).
By the way, your suggestion of changing "reality" to "twisted.reality" when running faucet did the trick. I can now proceed through the game via the tk interface. How does this mesh with the web browser interface? Or is it something separate?
Does anyone know the status of reality servers?
What do you mean by Status?
Is anyone actively working on them? Are there any long-range plans for them?
I think I asked before if they were supposed to be like TADS interpreters or Z-machines, or are they to be something different.
It's going to take some time to go through the various modules and find out how they fit together, and how the reality server interprets and processes sentences. If there are docs on how to create a reality world they would be helpful.
I'm really enjoying playing around with all of this stuff.
Great to hear it! :)
I'll reply to the list when I get some more information together, or when I get some more questions :)
In our city we get a public holiday on Wednesday but I think most of the day is already taken up by family plans. If only I had discovered these sorts of projects 10 to 15 years ago...
Cheers, ChrisH
On Mon, 13 Aug 2001, Chris Hadgis wrote:
[snip]
By the way, your suggestion of changing "reality" to "twisted.reality" when running faucet did the trick. I can now proceed through the game via the tk interface. How does this mesh with the web browser interface? Or is it something separate?
The web browser interface is still proof-of-concept. There is no way to interact with the game using actions; keepalive HTTP connections and other such nightmares prevented me from doing so. It'll probably eventually be most useful as an authoring interface.
Does anyone know the status of reality servers?
What do you mean by Status?
Is anyone actively working on them? Are there any long-range plans for them?
Not "actively", although I use the Reality service as a testing ground for most of my changes, since it is a simple and typical application of the Twisted framework. So, it remains up to date but does not accumulate any significant new functionality over time. Unless, of course, some enterprising hacker were to come along and contribute some... :-)
I think I asked before if they were supposed to be like TADS interpreters or Z-machines, or are they to be something different.
It inherits much from that culture, but it's designed to be an online environment as well as single-player, and the single-player component runs mostly in realtime (but can optionally be turn-based). So I'd have to say it's something different, and I don't know of any similiar projects.
It's going to take some time to go through the various modules and find out how they fit together, and how the reality server interprets and processes sentences. If there are docs on how to create a reality world they would be helpful.
Most of the documentation for Twisted Reality was written several years ago, and referred to the Java version of TR. It is obviously no longer accurate or relevant :). Documentation is a known sore point and you're encouraged to document your experiences; keep in mind that asking questions on the mailing list means that at least we'll have somewhere to refer other people asking the same questions to, so it does help!
______ __ __ _____ _ _ | ____ | _/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://twistedmatrix.com/users/glyph
From: "Glyph Lefkowitz" glyph@twistedmatrix.com
The web browser interface is still proof-of-concept. There is no way to interact with the game using actions; keepalive HTTP connections and other such nightmares prevented me from doing so. It'll probably eventually be most useful as an authoring interface.
Okay, I won't worry too much about it then :)
Is anyone actively working on them? Are there any long-range plans for
them?
Not "actively", although I use the Reality service as a testing ground for most of my changes, since it is a simple and typical application of the Twisted framework. So, it remains up to date but does not accumulate any significant new functionality over time. Unless, of course, some enterprising hacker were to come along and contribute some... :-)
I use the tk interface from faucet. I take it this is the Windows, or non-Unix version of the interface. I notice the gtk interface is more advanced than the tk interface. This is something I will be fixing in the near future. I even made my first TR chage -- the text in the two major windows (the description and the item list) now wraps. When I make a few more changes I will try and create a diff file so the changes can be added to the CVS. Is there an official change log, or revision history, or something similar?
I think I asked before if they were supposed to be like TADS interpreters or Z-machines, or are they to be something different.
It inherits much from that culture, but it's designed to be an online environment as well as single-player, and the single-player component runs mostly in realtime (but can optionally be turn-based). So I'd have to say it's something different, and I don't know of any similiar projects.
Okay. I will look at getting it to work the way the other IF systems do for a single player, then see how multi-player IF might look. I actually did try to start two faucets to connect to TRdemo. A crash on the second faucet told me the address was already in use. Is it possible, in theory, for me to be able to run two faucets for the one demo? If it is, I will add this to my to-do list for the tk interface.
It's going to take some time to go through the various modules and find out how they fit together, and how the reality server interprets and processes sentences. If there are docs on how to create a reality world they would be helpful.
Most of the documentation for Twisted Reality was written several years ago, and referred to the Java version of TR. It is obviously no longer accurate or relevant :). Documentation is a known sore point and you're encouraged to document your experiences; keep in mind that asking questions on the mailing list means that at least we'll have somewhere to refer other people asking the same questions to, so it does help!
I will try and document the functions as I get around to finding out what they all do and making changes to them. The next change I want to make is to get the tk interface to recognise 'n' as a valid command (go north). I know the gtk interface does this so I will copy what I can.
I will post about my progress with this as I make some :)
Cheers, ChrisH
On Tue, 31 Jul 2001, Moshe Zadka wrote:
ServerSocket is the official Pythonic name, as in "the ServerSocket module".
Where does this module appear?
glyph@helix:~% python2.1 Python 2.1 (#1, May 31 2001, 15:00:32) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-81)] on linux2 Type "copyright", "credits" or "license" for more information.
import ServerSocket
Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: No module named ServerSocket
______ __ __ _____ _ _ | ____ | _/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://twistedmatrix.com/users/glyph
On Tue, 31 Jul 2001, Glyph Lefkowitz glyph@twistedmatrix.com wrote:
On Tue, 31 Jul 2001, Moshe Zadka wrote:
ServerSocket is the official Pythonic name, as in "the ServerSocket module".
Where does this module appear?
Woooops! my bad: SocketServer
Python 2.1 (#1, Apr 27 2001, 01:24:08) [GCC 2.95.3 20010219 (prerelease)] on linux2 Type "copyright", "credits" or "license" for more information.
import SocketServer print SocketServer.__doc__
Generic socket server classes.
This module tries to capture the various aspects of defining a server: ....
On Mon, 30 Jul 2001, Glyph Lefkowitz wrote:
On Mon, 30 Jul 2001, Chris Armstrong wrote:
A lot of people get confused by the term "Port". When they think "Port", they don't necessarily think of "something that sits on a port, and listens for incoming connections". That's just how I understand it. Another argument against Port is that it's not only for "waiting for incoming connections" -- clients also allocate ports when they connect to remote hosts. So, even technically, Port is an inaccurate term for this class. You might find other technical details that make "Listener" slightly inaccurate, but it still just Makes Sense to most people (I'm guessing -- DavidC_, after me using the word "Port", and explaining that I'd rather prefer "listener", told me he would've immediately understood what I was talking about if I had used that term from the beginning).
I'd be interested to hear more feedback on this. Do folks generally think that "listener" makes more sense than "port"?
Well my misunderstanding comes from already having worked with sockets. A tcp port is just a number attached to each packet. When you want to make a server you call listen() on a bound port number. You listen for people who want to talk to you. So you create a Listener.
By the way, spread.pb is neat.
name: David Creswick website: http://braznet.com/david jabber id: davec@jabber.org
well, since you asked... "Listener" is very passive, non-directed. It would be nice if we could convey the idea of something dedicated/allocated wishing/waiting/hoping for a _potential connection. It's not "someone who happens to be listening" to a broadcast, it's more like "operators are standing by."
Of course, the word "operator" is plainly no good, as it's a loaded term in this environment. A close synonym is "receptionist", but that's a bit unwieldy and doesn't feel quite right to me. "clerk" is too general, "teller" (as in bank) doesn't work either.
I'm not sure "port" is really that bad. It's a point of contact, something with a *specific address* which may be connected to (which "Listener" does /not/ convey), something that things traveling to/from remote locations go through. And hell, if you're going to use a phrase like "TCP", you might as well use the standard terminology that goes with it. =)
You're right though, in saying that not all ports are for inbound connections, they're also for outbound connections. Maybe a qualifier is in order?
PortListener ListnerPort ListeningPort InPort InboundPort ReceptivePort ReceivingPort DockingPort OpenPort SuckingPort TapPort WatchedPort SentryPort ok I think I better stop there
-
Chris Armstrong -
Chris Hadgis -
David C -
Glyph Lefkowitz -
Jason L. Asbahr -
Kevin Turner -
M.J. Stahl -
Matthew Walker -
Moshe Zadka