Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

GAE-XMPP Conversations by Mind Map: GAE-XMPP Conversations
0.0 stars - reviews range from 0 to 5

GAE-XMPP Conversations

Amusing name idea: * wixard Straight-forward idea name: * xmpp_conversations

Models

Conversation

Inherits from db.Expando

Properties, user, init time, last_updated, messages (all, including most current), steps_so_far (list), status (either complete, ongoing, or aborted), next_step (the name of the next step), list_shortcut, the name of the method to call if the user says /list without args

conversation protocol, The idea is that you use your conversation object as a long-running transaction, storing whatever intermediate or state data you need as expando properties, On your own models, you might provide a "from_conversation" @staticmethod that constructs one of your model objects from a conversation

Base handler

Overrides text_message

On new text_message, looks up conversations to see if the user has an active one, if there's no active conversation, falls through to self.unhandled_command

Appends current message to conversation

On function exit, commits conversation

Runs function for next_step

Adds next_step to steps_so_far

Updates last_updated

Adds a few command

/abort, manually ends the current conversation

/replay, replays the conversation up to where you are (useful if you accidentally quit your IM client or your browser crashes and you don't feel like hunting through your logs)

maybe /new, First steps are called whatever_new, /new would then call whatever, /new would be smart and mark any existing conversation as aborted (maybe with a setable warn time), Could support partial command names

maybe /help, Calls the help_message @staticmethod on all registered responders and passes them the message, Can optionally take a responder name for detailed help from just that resonder, Can optionally take a command name, so /help list or /help new

maybe /list, /list is for functions that give the user a list of available options, generically, /list would take the name of some property to list, Could support partial list names, /list lists would give you all the things you can list, In a smart world, /list with no arguments will see if the current conversation has a list_shortcut and then run that

steps protocol

A step is the step name, followed by _step

A step takes self and the conversation, and a reply_only flag (for /replay)

first step is something followed by _new

list protocol

it's not uncommon to have something you want to list that you wouldn't necessarily want to list by default

functions that just generate a list of something are whatever_list, receives self and the message

Could be conversation aware and check to see if there's a current conversation with list_shortcut set if /list is called with no args. If so, will call the correct list

Ideas

Let classes be registered to handler to handle different /new commands

for example, /new shake or /new task

Have registered classes provide a message for /help

These handlers are called responders

Tasks

Sweeper for complete and aborted tasks

Sweeper to mark stale tasks as aborted

Config

Conversation timeout

General timeout

Timeout after user signout, On user timeout, a task it set to mark all of that user's tasks as aborted if the user doesn't sign back in in the allotted time