[Tinymux] Features that strike my fancy

[Mark hassman]

Things I see that are likely not high on anyone's priority list either:

Local Extensibilty:  similar to Penn's but tailored to MUX.  I'm working 
this and hope to have something useful to submit in a few weeks while 
still in alpha period.    The idea is to have very few entry points.   
Primary will to be register callback functions keyed off specific events 
(load db, save db, create obj, dest obj, ...).  Those callbacks will 
then be called with appropriate arguments on that event happening.   
Second portion is to allow extending the command and function tables.   
When finished, it should be capable of decoupling the various add-ins 
(BT, WOD_REALMS, and HSpace) and make it available to various other systems.

The other aspect I was asked to look at was fiddling  @mail.  It appears 
to suffer from the "many hands" syndrome but I've not really delved into 
it.  I'd gut and replace it, personally.    Features requested are 
differentiation on the To:, CC:, and BCC: fronts; separation of messages 
between the note and the original when doing forwards; tracking of 
senders by dbref to deal with senders swapping names in between; 
capability of handling anonymous mail senders (configurable); ability to 
re-send a @mail message if you forgot a  recipient via recalling the 
message from another recipient into the send buffer.   I'm sure there 
are numerous other ideas on that front.

On the longer term front,

Replace the configuration parameter handling with a system capable of 
writing the current configuration to a file (either the current config 
file or an alternate).   The historical load only setup is rather 
antiquated and should be replaced, IMO.   Being able to dump the 
configuration makes it more flexible for admins who are shell impaired 
and easier for those admins who want to make a change on the fly and 
forget it.   The temporary behavior can easily be retained by not 
writing the conf file.    

Beyond that, since MUX is in the C++ world, I'd start to migrate away 
from the entire  predefined buffer lengths.   The std::string class 
provides enough to eliminate most of that but may have portability 
problems with a few platforms.   That would be a major shift but should 
be better in the end.  

Lastly, just toss up a list of "addressable items" that those of us not 
in the pimary development loop can take a look at.    You can always 
reject the patches if you feel it doesn't meet the requirements of what 
you want.

My $0.13.

    -Mark


Stephen Dennis wrote:

>Perhaps it isn't a high-priority on anyone's list, but I'd like to
>enabling Chinese-language MUSHes by supporting UTF-8.
>
>Also, I'd like to change the way ANSI is handled and replace the LBUFs
>with an ANSI-aware string object. TinyMUX is using C++, so I could
>leverage that. Maintaining speed is the still the trick though, but
>with this, color is pervasively understood. Like so:
>
>    'add(%xr123,%xg123)' ---> '246'
>
>There are at least a handfull of things I'd like to tackle in MUX at some point.
>
>Brazil
>_______________________________________________
>Tinymux mailing list
>Tinymux at tinymux.org
>http://www.tinymux.org/mailman/listinfo/tinymux
>  
>