A: Multiple port listening is the idea that you can have more than just #0 listening on a port for incoming connections within the MOO. This means you can offer services from within the MOO, like http, or gopher, or ftp even.
A: MPL isn't a way to make MOO objects into HTML, or vice versa. This is an interesting concept, but it seems like something not in the scope of this little project.
A: Mostly because, A) I like it, and B) it's a great alternative to multiplexing many kinds of data across a single connection. It also allows things like services to be offered in the MOO.
A: ftp://ftp.ccs.neu.edu:/pub/mud/servers/lambdamoo/patches
A: The reason I hacked the LambdaMOO server to be able to have arbitrary objects listen on ports stems from a discussion that I had with Jay Carlson in our apartment one night. Essentially the argument is this: The MOO server can have a single connection (the player connected on the main port), and multiplex communication in weird ways over that (MCP is one way to do this) or the server can have multiple ports to communicate over via any number of protocols (this is the goal of MPL). One of the original goals was to have JHM not have to listen for HTTP requests on the main port, parse out things that started with 'get' and etc etc etc for HTTP. This, I hope is obvious, would eventually happen with every protocol that people wanted to use with standard clients. Instead of having to do that, why not just put some object that's designed to deal with HTTP, on some port, and have standard web clients connect to a port, and get HTML? Seemed easy enough. Well here it is. With MPL you can define daemon objects that sit around waiting for connections, pass the connections on to an object that speaks the protocol, and *bam* drops the connection when done.