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



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


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


Sweeper for complete and aborted tasks

Sweeper to mark stale tasks as aborted


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