( request.muf  --  12/17/11  by Squirrelly )
(

    rough design..

    A program to track in-muck requests for new characters and for
    wizards to create the new characters.
    Orignially designed for Equestria MUCK.

    Exective Summary:
        A player does:
            @request NewCharacterName
        Player will be promted for any needed info {email, etc.}.
        Wizards will be notified of requests.
        A wizard does:
            @request #work
        It will pull the first one and display info about it.
        The wizard will be given instructions as to what options are next.

        A summary for reference follows:
        The wizard may then do one of the following:
            If wishes to Approve the request:
                @request #create
                    This will attempt to create the character and set
                    initial props, and inform the wizard if successful.
                    If it fails, go to the #deny option.
                @request #email
                    Copy and paste the displayed message into your
                    email program and send to the given email address.
                    Replace needed parts in <>s, if any.
                    This option may be repeated if needed.
                @request #sent
                    Do this once the email successfully goes out.
                @request #emailfail
                    If the email fails or bounces at any time.
            If wishes to deny:
                @request #deny
                @request #email
                    Copy and paste the displayed message into your
                    email program and send to the given email address.
                    Replace needed parts in <>s, if any.
            If wishes to ignore {invalid entry, etc.}:
                @request #ignore

    tentative syntax...
        @request [#<option>] <character name>

        <options>:
            {none/blank}
                Submit a request for the given character name.
            #help
            #status
                Check the status of the given character.
                If <character name> is blank, show all requests by user.
                    ? For wizards, show status of what they are working on?
        Wizard-only <options>:
            #list {or if entirely blank?}
                Show a list of character requests.
                <character name> may be one of the following:
                    A specific name in the list:
                        The status just for the character will be given.
                    {blank} or #pending
                        Will list all pending requests needing work.
                    #working
                        All requests currently being worked on.
                    #waiting
                        Email sent, but has not logged in yet.
                    #completed
                        Created and character has logged in.
                        {too many?}
                    #all
                        All requests.
                        {too many?}
            #work
                Pulls the <character name> entry {or if blank, the first
                    pending one} and sets it as being worked by you.
                The following commands can then leave off
                    the <character name> part and will apply to the entry
                    you are working on:
                        #create, #deny, #ignore, #email, #sent {, #ban?}
            #create
                {calls @makechar prog..}
            #deny
            #ignore
            #forbid
                "name":  Exactly that name
                /name/:  A pmatch pattern
                name:    If name appears anywhere in a requested name
                {...need to handle if you forbid something that matches
                    existing entries...}
            #allow
            #email
            #sent
            #emailfail
            ?? #ban {ban a player from using this?}

    Properties:
        On program:
        On #0:
            @requests
                /db/<name>
                    {all main data is stored here so doesn't have to be
                        moved around when status changes, but have pending
                        and waiting prop dirs for quick lookups}
                    /status: <status>
                        Redundant data in case prop dirs need to be rebuilt,
                            plus additional info.
                        <status> may be one of:
                            N:  New entry {pending}
                            W:  Being Worked {but not created yet; pending}
                            C:  Created {being worked; still pending}
                            D:  Denied {pending; done when email sent}
                            E:  Email has been sent {waiting}
                            I:  Ignored {done; no email}
                            F:  Finished {done}
                    /log/<timestamp>: <db ref> <status>
                        Same value for <status> as for /status prop.
                    /requester
                        /dbref: <db ref of requesting player>
                        /hostname: <requester host / ip info>
                    /worker: <db ref of worker; not set if none>
                    /dbref: <db ref of new character once created>
                /pending/<name>
                    {...use an index number to matain order?...}
                /waiting/<name>
                /deny
                    /exact/<name>
                    /contains/<name>
                    /pmatch/<index>:<pattern>

        On wizard:
            @request
                /working: <name>


    ideas...
        Alerts:
            ##REQUEST> New @request for "<requested name>" by "<requester>".
                Send to logged-in on-duty wizards upon new request.
            ##REQUEST> There are <number> pending @request{s}.
                Display to wizards when they log in, if any are pending.

        What if a character name is requested, approved, later toaded, and
            then later requested again?  Replace old entry in the db?
            Same for if denied/ignored?

        If requested by existing character, use/approve info from them,
            or require full verification?

        If denied, and was requested by an existing character, should
            handle just as a page-mail rather than email?

)