Telnet TTYPE support
Sparks
terminal detection and added a Penn-compatible terminfo(). I say
"compatible" inasmuch as it has '<client> <tags>' and shows 'telnet'
for Telnet compliance, or 'pueblo' for Pueblo-enabled connections,
just like Penn. Obviously, we don't have Penn's 'ssl' or
'prompt_newlines' tags, since we neither support SSL/TLS nor Telnet
Linemode.
At any rate, while getting the client name is cutesy but not terribly
important, the other tokens in terminfo() could potentially be
extremely useful, down the road. As we add support for Unicode, it
would make sense for a 'unicode' tag to be attached to any session
with support for that. Similarly, if MXP or MCP support is added, an
'mxp' or 'mcp' tag could be tossed into the terminfo() output.
Rachel Blackman
term is:
* Telnet CHARSET support.
Yeah, right now, that'll only let us tell a client that we speak
Latin1, but hey, it's still useful to have for down the road. Plus,
having added the 'send Suboption' support for TTYPE, with only minor
work it will be trivial to add CHARSET. (After all, it's not like
we're negotiating anything right now; we're offering that we support
'ISO-8859-1' and rejecting all other options!) And it'll give us a
basis for later; we can offer 'ISO-8859-1' and 'UTF-8' (both
registered IANA charsets, and valid Telnet charset options!), and if
the client accepts UTF-8, boom, unicode.
* General SQL
I'm working on splitting the inline Penn/TM3 compatible sql()
function out of the Firan-specific code, and then making it no longer
MySQL-only. I want to create a general 'SQL' handler; you'll pick
that you're using the MySQL driver, and then both the queryslave and
the inline SQL will use that, if you enable either of them. (Or, of
course, all SQL can be disabled entirely.)
I think really the SQL should be more generalized, with an abstract
SQL-accessing layer that anything wanting to get into SQL uses.
This leads to a longer-term addition of (please don't shoot me)
Mediawiki integration, which obviously requires SQL support.
Basically, in addition to 'raw_helpfile' and so on, you'll have
'wiki_helpfile' config option which points to a Mediawiki namespace.
Then any entry in that file will pull the corresponding Wiki entry,
format for text and break up into pages (accounting for the NAWS-
negotiated width and height), automatically generate any 'See also'
lines from the wiki-links, and display.
I know this seems perhaps a little feepish, but it's something I've
heard a lot of folks lamenting, that they wish they had a way to do
this. I'm going to hold off, however, until mux_string is sorted out
and we know a little of where we're going on Unicode, so I know how
to handle Unicode characters from in the Wiki.
If there are objections to this, now would be the time to stop me...! ;)
Seriously, I don't expect the CHARSET or generalizing the SQL will
earn any objections (especially since the queryslave really needs to
be finished), but I can see a few objections to the Wiki-integration
on feep-grounds. But I think it's a very useful way to have, say,
news/theme files on both an easily-maintainable wiki AND in the game,
and keep them in sync.
Roy Anger
> This leads to a longer-term addition of (please don't shoot me)
> Mediawiki integration, which obviously requires SQL support.
>
> Basically, in addition to 'raw_helpfile' and so on, you'll have
> 'wiki_helpfile' config option which points to a Mediawiki namespace.
> Then any entry in that file will pull the corresponding Wiki entry,
> format for text and break up into pages (accounting for the
>
> I know this seems perhaps a little feepish, but it's something I've
> heard a lot of folks lamenting, that they wish they had a way to do
> this. I'm going to hold off, however, until mux_string is sorted out
> and we know a little of where we're going on Unicode, so I know how to
> handle Unicode characters from in the Wiki.
>
you mentioned you were planning to do this with namespaces (IE, a News
namespace to correspond to the news wiki_helpfile), makes me question
the value of doing it via hardcode. The biggest problem with using
softcode to access mediawiki articles is that a general article can have
a ton of different formatting, plus templates, images, etc. If a custom
namespace is created then the game admin can control the content of that
namespace so that only == == and === === titles and \n line breaks are
used (as a simple example). If that's done then using softcode to change
the article into MUX format seems easy enough. So, ultimately, I get to
asking this: What extra does the hardcode implementation have over
softcode and a carefully implemented custom namespace?
Roy
Rachel Blackman
>> I've heard a lot of folks lamenting, that they wish they had a way
>> to do this. I'm going to hold off, however, until mux_string is
>> sorted out and we know a little of where we're going on Unicode,
>> so I know how to handle Unicode characters from in the Wiki.
>>
> Combining the content of this email plus the post you made to WORA
> where you mentioned you were planning to do this with namespaces
> (IE, a News namespace to correspond to the news wiki_helpfile),
> makes me question the value of doing it via hardcode. The biggest
> problem with using softcode to access mediawiki articles is that a
> general article can have a ton of different formatting, plus
> templates, images, etc. If a custom namespace is created then the
> game admin can control the content of that namespace so that only
> == == and === === titles and \n line breaks are used (as a simple
> example). If that's done then using softcode to change the article
> into MUX format seems easy enough. So, ultimately, I get to asking
> this: What extra does the hardcode implementation have over
> softcode and a carefully implemented custom namespace?
The main reason is buffer limit, honestly. (Aside from the 'OMG
parsing Wiki markup in softcode makes my eyes bleed, because MUSHcode
is not a good language for large-scale text transformation' factor.)
And the last factor, of course, is that I'm just the codewiz, not the
headwiz, of the game I'm doing code on... and the headwiz said 'MAKE
THIS HAPPEN' so my concern needed to be the 'how.' ;)
At any rate, your average news entry (if you combine all the pages of
the entry) can be far longer than the default MUX2 buffer limit.
Sure, you can increase the buffer limit, but let's say you're
discussing 'news theme' or 'news history,' which on many original-
themed games will be a good 20-30 news entries long. Yet on the
wiki, that would be a single entry; if you've ever used a Wiki like
wikipedia you'll find that you don't go to, say, http://
en.wikipedia.org/wiki/Sir_Arthur_Conan_Doyle and then have to click
to get to Sir_Arthur_Conan_Doyle_(2) or Sir_Arthur_Conan_Doyle_(3)
and so on. It's all just one entry.
And in general, the reason people WANT to have their newsfiles on a
wiki is threefold: easier maintenance by staff, ability to display
large entries all at once, and ability to cross-link between entries.
Given the second of those points, this means I don't have much hope
of taking the entry, parsing it into plaintext, and then formatting
it out according to NAWS width/height data to break into 'pages' if I
do so in softcode. Even if I use the sql access in-game to get that
wiki entry into softcode in the first place, I will probably not even
have the entire /entry/ in the buffer... much less enough buffer
leftover to even begin parsing it into plaintext. I will hit buffer
limits right out of the gate.
Sure, I could break it up into multiple pages right on the wiki, but
that loses the entire value of wiki/game integration (and also loses
the opportunity to actually use our NAWS data and format news/help
files out appropriate to the client, instead of just assuming
everyone's on TinyFugue). So the options are either turn the
softcode buffer limits up to ludicrous levels, or handle this in
hardcode.
At any rate, I've got to do some variant on this over in the
dev_firan branch /anyway/. If no one else wants the wiki stuff at
all, I will still refactor the SQL stuff out of Firan and into
general code, since I /do/ honestly think the SQL stuff needs to be
reworked and shouldn't be specific to the --enable-firanmux portion
to begin with. But I can then include the wiki_helpfile integration
in Firan only.
Because honestly, if no one feels the Wiki stuff is generally useful,
then it's a lot easier for me; I need only integrate the read-only
newsfiles Firan needs, not do the sort of wholesale integration folks
have talked about on ElectricSoup and WORA. I just thought I would
bring up the possibility as a general --enable-mediawiki option,
since it would be something new, different and potentially useful...
but no skin off my nose either way! :)
Roy Anger
> At any rate, I've got to do some variant on this over in the dev_firan
> branch /anyway/. If no one else wants the wiki stuff at all, I will
> still refactor the SQL stuff out of Firan and into general code, since
> I /do/ honestly think the SQL stuff needs to be reworked and shouldn't
> be specific to the --enable-firanmux portion to begin with. But I can
> then include the wiki_helpfile integration in Firan only.
Ie, I gather, stuff like --enable-sql and --enable-16kbuffer and so on.
With him over in Asian and on dialup though it might be hard for him to
comment and explain, but I do know he wants to break up --enable-firan
into various parts.
>
> Because honestly, if no one feels the Wiki stuff is generally useful,
> then it's a lot easier for me; I need only integrate the read-only
> newsfiles Firan needs, not do the sort of wholesale integration folks
> have talked about on ElectricSoup and WORA. I just thought I would
> bring up the possibility as a general --enable-mediawiki option, since
> it would be something new, different and potentially useful... but no
> skin off my nose either way! :)
Its not that I feel the mediawiki integration isn't useful, but rather
I'm questioning exactly what you want it to do. The buffer issue is one
thing, though again its possible to work around it. The typical
history1, history2 layout many game's use is a little silly anyway, and
replicating that on a wiki takes away from the power of the wiki to have
proper articles with cross linking. Though, yes, proper wiki articles
can easily go over the default 8k buffer on MUX, or even over the 16K
buffer that --enable-firan has.
Perhaps, if I could suggest something, you could add a wiki.conf file.
IF wiki_helpfile is in the <netmux>.conf file then the game uses
wiki.conf to convert wiki formatting. For example, wiki.conf might have:
==TEXT== to [center(ansi(hb,TEXT),78)]
===TEXT=== to [ansi(hy,TEXT)]
Anyway, that's a thought I had that would allow the game admin to
control what the wiki formatting turns into on the game, and allow them
to add as much as they want, allowing for very simple or more complex
articles on the wiki.
I guess my concern is just that if you're going to add this I'd like to
see it be a serious addition and not just something that could be easily
dummied up in softcode. I'd also like to see more of your ideas floated
here or on BrazilMUX, just to give people a chance to see where you're
going with it. Like your goal with SQL to make it more generic, I think
it would be good to make sure that anything done to integrate MUX and
mediawiki will fit for various games and isn't too tailored to just one
wiki/game implementation.
Rachel Blackman
> options. Ie, I gather, stuff like --enable-sql and --
> enable-16kbuffer and so on. With him over in Asian and on dialup
> though it might be hard for him to comment and explain, but I do
> know he wants to break up --enable-firan into various parts.
Yeah, he and I have discussed this. Everything Firan-specific was
wrapped in --enable-firan initially to avoid having to redesign it,
and just 'get it working.' It was never intended as the long-term
goal, though I expect some things will remain in enable-firan. I
really doubt anyone else needs the IMMOBILE stuff, for instance.
> Perhaps, if I could suggest something, you could add a wiki.conf
> file. IF wiki_helpfile is in the <netmux>.conf file then the game
> uses wiki.conf to convert wiki formatting. For example, wiki.conf
> might have:
> ==TEXT== to [center(ansi(hb,TEXT),78)]
> ===TEXT=== to [ansi(hy,TEXT)]
This is basically what I intended in concept, yes. Especially since
it allows weird people to use Pueblo markup, or if MUX3 eventually
supports MXP, using MXP markup. The grammar would have to be a
little different, of course, since '==TEXT==' should probably not
only get marked out as a heading but should also probably be allowed
to potentially section-break, etc.
The translation table of the parser should not be hardcoded; just the
methods to access the raw wiki, and then to break up the resulting
plaintext-formatted sections up into pages accounting for the
receiving user's NAWS data.
> I guess my concern is just that if you're going to add this I'd
> like to see it be a serious addition and not just something that
> could be easily dummied up in softcode. I'd also like to see more
> of your ideas floated here or on BrazilMUX, just to give people a
> chance to see where you're going with it. Like your goal with SQL
> to make it more generic, I think it would be good to make sure that
> anything done to integrate MUX and mediawiki will fit for various
> games and isn't too tailored to just one wiki/game implementation.
Ah, okay, I misunderstood. (Mistake of late-night posting and then
reading replies before morning tea!) We're more or less on the same
page, then; this is basically why I brought it up here. If it's
something deemed more generally useful, I'd like to flesh it out into
something more serious (though in that case, I would prefer to hold
off on more than basic design until we sort out what we're doing on
Unicode, so that there's a sane/sensible way to deal with Wiki's
native UTF8-ness). If it is NOT useful or is considered too feepish
for general inclusion, I'll do a more minimal implementation and fold
it into just --enable-firan, since we need it one way or another.
I'd just prefer it was done in a more generally useful, flexible way,
both for the sake of good design and for the sake of having as little
custom one-game-specific code in an --enable switch as possible. :)
Roy Anger
> Yeah, he and I have discussed this. Everything Firan-specific was
> wrapped in --enable-firan initially to avoid having to redesign it,
> and just 'get it working.' It was never intended as the long-term
> goal, though I expect some things will remain in enable-firan. I
> really doubt anyone else needs the IMMOBILE stuff, for instance.
could easily replace it, but the point is that some of us find this
stuff useful. ;)
>> Perhaps, if I could suggest something, you could add a wiki.conf
>> file. IF wiki_helpfile is in the <netmux>.conf file then the game
>> uses wiki.conf to convert wiki formatting. For example, wiki.conf
>> might have:
>> ==TEXT== to [center(ansi(hb,TEXT),78)]
>> ===TEXT=== to [ansi(hy,TEXT)]
> This is basically what I intended in concept, yes. Especially since
> it allows weird people to use Pueblo markup, or if MUX3 eventually
> supports MXP, using MXP markup. The grammar would have to be a little
> different, of course, since '==TEXT==' should probably not only get
> marked out as a heading but should also probably be allowed to
> potentially section-break, etc.
See, while it probably makes sense most of the time to force == == to
behave on MUX like on the wiki and have it be a section header and a
section-break (though not an anchor since MUX doesn't need/use hyperlink
anchors), I'd rather be allowed to determine the behaviour myself as a
game admin. I mean, we have to assume that someone setting this up is
going to have some experience using mediawiki and as such should
understand what the various formatting options do (or at least, in the
case of the advanced stuff know where to go and learn about them). As
such, I'm of the opinion that the game admin should be free to translate
wiki's == == into whatever they want for the game. I also assume that
the code you're adding is going to translate the \n in the article into
line breaks anyway, so there's already going to be some line breaks in
place from when an article does '==Swords==\nThis is some information
about how swords work in our world.'
>
> Ah, okay, I misunderstood. (Mistake of late-night posting and then
> reading replies before morning tea!) We're more or less on the same
> page, then; this is basically why I brought it up here. If it's
> something deemed more generally useful, I'd like to flesh it out into
> something more serious (though in that case, I would prefer to hold
> off on more than basic design until we sort out what we're doing on
> Unicode, so that there's a sane/sensible way to deal with Wiki's
> native UTF8-ness). If it is NOT useful or is considered too feepish
> for general inclusion, I'll do a more minimal implementation and fold
> it into just --enable-firan, since we need it one way or another.
>
> I'd just prefer it was done in a more generally useful, flexible way,
> both for the sake of good design and for the sake of having as little
> custom one-game-specific code in an --enable switch as possible. :)
Wiki's are useful to games in a number of ways, from making it much
easier to setup a website, so making it easier to maintain the site and
update the information, to allowing players to contribute and so on.
Several games are already using them, including mine. I even know that a
few of my players showed our wiki to other games, and those admins loved
our wiki and are sold on creating their own. That said, obviously adding
this borders on being too feepish, but if its open enough that every
game can configure it their way, within reason, then I think its useful.
I know, too, that you're going to be a more active developer than some,
what with the presence and business of Firan, so I'm certainly less
worried you're going to walk away while things are half done and leave
Brazil in the lurch.
I did have a few questions about things you may or may not be considering.
Links. For me the way wiki's cross link articles is big feature. It
makes it much easier to locate data and stumble onto new stuff. However,
the drawback in this case is that a wiki is designed to link between all
articles, independent of namespace. I would not want to change how
linking works, and I would want my news files in the wiki to be able to
have a link mid-sentence to other articles. That, however, can't work
with displaying things in game. Those links need to be changed to
something else. I see links falling into three broad categories. 1)
Links to other articles in the same namespace. IE, 'See Also' type
links. 2) Links to other wiki articles. 3) External links.
1) These are the important links to worry about, as players need to know
what other files to look at. Have you given thoughts to how to handle this?
2) These are somewhat important, but as they're out of the namespace the
helpfile command can't access them. What were you thinking of doing for
them?
3) External links are probably the easiest to drop during the
conversion, but again, any plans/ideas for these?
Access control. Right now you can use 'raw_helpfile +shelp text/shelp'
to use a shelp.txt file for the +staff command. Then you can do 'access
+shelp STAFF' to limit the command to staff members. However, wikis are
pretty poor at restricting access to pages. At the very least you need
to install one of several extensions. Did you have thoughts for access
control, or were you going to avoid that mess and simply say 'this is
designed only for publically accessible files?'
Roy
Rachel Blackman
>> since it allows weird people to use Pueblo markup, or if MUX3
>> eventually supports MXP, using MXP markup. The grammar would have
>> to be a little different, of course, since '==TEXT==' should
>> probably not only get marked out as a heading but should also
>> probably be allowed to potentially section-break, etc.
> See, while it probably makes sense most of the time to force == ==
> to behave on MUX like on the wiki and have it be a section header
> and a section-break (though not an anchor since MUX doesn't need/
> use hyperlink anchors), I'd rather be allowed to determine the
> behaviour myself as a game admin.
Hence why I said it should be /allowed/ to potentially section-break;
there should be a way in the wiki.conf grammar to support that (i.e.,
the translation should not be a simple text-replacement, but should
be able to attack some conceptual meaning to blocks of wiki markup as
well).
> I did have a few questions about things you may or may not be
> considering.
>
> Links. For me the way wiki's cross link articles is big feature. It
> makes it much easier to locate data and stumble onto new stuff.
> However, the drawback in this case is that a wiki is designed to
> link between all articles, independent of namespace. I would not
> want to change how linking works, and I would want my news files in
> the wiki to be able to have a link mid-sentence to other articles.
> That, however, can't work with displaying things in game. Those
> links need to be changed to something else. I see links falling
> into three broad categories. 1) Links to other articles in the same
> namespace. IE, 'See Also' type links. 2) Links to other wiki
> articles. 3) External links.
Right, let me address each of these.
> 1) These are the important links to worry about, as players need to
> know what other files to look at. Have you given thoughts to how to
> handle this?
Yes. This is actually pretty much the core reason /why/ Adam asked
that I look into doing the wiki newsfile stuff, because Firan's cross-
referencing is becoming a real bear to maintain; witness:
-rw-rw-rw- 1 firan firan 1797030 Feb 16 13:41 news.txt
...1.6 megabytes of newsfile is not fun to try and keep cross-
references updated for. ;)
At any rate, during the parsing any link to an article in the same
namespace will be stored in a list, and added to a 'See also: '
listing at the bottom of the page it appears on. Potentially also at
the end of the article, i.e. at the end of the last page. This would
be another config option you could tune, to determine if you want
'See also' links on the same article-fragment (helpfile page) they
occur in, at the end of the /entire/ article, or both.
> 2) These are somewhat important, but as they're out of the
> namespace the helpfile command can't access them. What were you
> thinking of doing for them?
If the namespace they link into is handled as a helpfile also (just a
different help command), it will be 'See also <x> on: ' where <x> is
the appropriate command. Like how, at present, a 'news factions'
file may have 'See also help on: +factions' at the bottom. I.e.,
they will be handled like case 1, albeit accounting for the differing
namespace.
If they are not handled game-internally, they will be treated as an
external link and handled like case 3.
> 3) External links are probably the easiest to drop during the
> conversion, but again, any plans/ideas for these?
Again, configurable logic. Optionally drop them all, or add an
'External references: ' listing at the end of the article.
> Access control. Right now you can use 'raw_helpfile +shelp text/
> shelp' to use a shelp.txt file for the +staff command. Then you can
> do 'access +shelp STAFF' to limit the command to staff members.
> However, wikis are pretty poor at restricting access to pages. At
> the very least you need to install one of several extensions. Did
> you have thoughts for access control, or were you going to avoid
> that mess and simply say 'this is designed only for publically
> accessible files?'
I basically was planning to avoid that mess entirely, yes. I figure,
you don't get to put access restrictions on a per-page basis in
raw_helpfiles, you don't get to do it in a wiki_helpfile either.
As for the entire namespace... game-side, you can restrict the
command by doing an 'access' directive; wiki-side, you can restrict
access to the namespace using one of the extensions if you want (or
admittedly, Mediawiki 1.9 is a bit better about that). The helpfile
portion would be a read-only access; it's not my place to control the
wiki side, just to access it.
Really, the only writing I would do to the Wiki database (if I bother
to implement this) would be the oft-requested 'keep a Mediawiki user
database in synch with player records' thing various games have
wanted custom patches for. That wouldn't be hard to implement once
you already have all the Wiki access goo, but it would definitely be
a separately tunable option. And it's not one I need/want, so it's
definitely lower on my list of potential priorities; it's something I
can examine later if people are still wanting it. :)
Roy Anger
>
> Really, the only writing I would do to the Wiki database (if I bother
> to implement this) would be the oft-requested 'keep a Mediawiki user
> database in synch with player records' thing various games have wanted
> custom patches for. That wouldn't be hard to implement once you
> already have all the Wiki access goo, but it would definitely be a
> separately tunable option. And it's not one I need/want, so it's
> definitely lower on my list of potential priorities; it's something I
> can examine later if people are still wanting it. :)
>
>
should be an option as well. To me, it makes sense to have the option to
make sure that the game and wiki have the same user accounts and
passwords. Given that edits would be occurring on the wiki, I know I'd
what to be able to easily track users. That's something that I kind of
regret with my game and its wiki -- player's can create users with any
name. Most use their PC name, but a few use other names and it can be a
little hard to see who did certain edits.
Stephen Dennis
Brazil's intention is to break up --enable-firan into separte options.
Ie, I gather, stuff like --enable-sql and --enable-16kbuffer and so on.
With him over in Asian and on dialup though it might be hard for him to
comment and explain, but I do know he wants to break up --enable-firan
into various parts.
Wiki stuff:
I don't grok the wiki integration enough to comment as right now my head is full of private, surrogate code points, casing, and state machines for UTF-8 at the moment. So, I'm just going to ignore those details for now. UTF-8 changes to the server should begin appearing with the the next check-in.
With regard to the wiki integration, as long as it's surrounded by --enable, we have options. My hope is that every effort is made to make it generically useful or at least expandable later before a specific game invests itself heavily in a specific, narrow implementation. Games come and go, so that usually opens up the opportunity to start over fresh, but for this game, whatever is done will be the way it is for the foreseeable future, so be careful. Yeah, a platitude for the choir is all I have at the moment. Good Luck!