Skip to content

Instantly share code, notes, and snippets.

@progrium
Created December 15, 2009 10:16
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save progrium/256833 to your computer and use it in GitHub Desktop.
Save progrium/256833 to your computer and use it in GitHub Desktop.
SERVICE MODULES and default/suggested mount point: (mount points are like ports)
- wiki #
- task queue *
- command line !
- twitter gateway @
- auction $
- voting % (its a scale? wow)
- review &
Command metasyntax:
| = denotes mount point
Common verbs to act on subject/resource and short modifier (after subject):
- add, +
- remove, -
- check, ?
- edit, = (can be assumed with a payload?)
- get, (no sigil needed)
Common universal? verbs. Is there nothing you can't question?
- help (lists commands)
Long form commands:
/<verb> <arg> <opt_arg?> <slurp_arg..> /<modifier>
Short form commands: (a particular command verb is assumed)
<page> <content..> might mean /get <page> <content..>
The general template is *I* *verb* *thesubjects* *modifierly* where the *I* is implicit in the sender and the adverb is often missing.
Proxy Protocol: (for getting around banned numbers, presumably some carriers ban some numbers some of the time... -- Also good for avoiding international fees, if they exist or something)
send
|/send <num> <text..>
|<num> <text..>
(nothing special setup for responses, this is just one-off stuff)
Tunnel Protocol:
setup: {num}, returns a code that when posted to will forward and all responses will be forwarded back
Wiki Protocol:
(Can also be used for group chat when used with watches)
For authors:
replace
|<page> <content>
|/edit <page> <content>
append
|<page>+ <content>
|/add <page> <content>
For readers
get
|/get <page>
|<page>
get previous revision
|/last <page>
|<page>^
watching
|<page> /watch OR /follow OR /join
|<page> /stop OR /leave OR /unfollow
(or any of these as longform, ex: |/watch <page>)
Task Queue Protocol:
Does it service multiple queues? queues could be named, or there could be one global queue for the whole number. This is related to the question of how the TQ nests in a larger shortnet host. Perhaps designed so it supports both. If a named queue is specified, it uses that. So the protocol should support an optional named queue in some cases (ok,fail can reference a global job id that doesn't require a named queue)
Sure, a "global" queue is a good default. People might even actually use the queue as a way to hand out finite resources. People will "get" on a company car and return it when they are done. Nice. Is there a name that unifies reservations and queuing?
For submitters:
submit: create a new job with some description, "." is aliased to the global queue
|/add<queue> <description..?>
|<queue?>+ <description>
check: find out if it is pending, assigned, and if it has any update text ("stat")
|/check <queue>
|<queue?>?
cancel: drop the job if pending, alert the worker if assigned, cancel it!
|/remove<queue>
For workers: (temporary english names for now)
get: get a pending job and its description
|/get <queue>
ok: return the job as completed (optional conclusion message "customer was pleased")
|/ok <queue> <conclusion..?>
fail: return the job as failed (optional message "customer was pissed")
update: provide additional info on an assigned job ("customer seems likely to buy")
Auction Protocol:
offer: start an aution with a given name and let the bid notifications start asyncing back to you
bid: a bid is just some string, but people will probably offer a price of some kind ("6 beaver pelts")
close: shut the auction down and stop sending bids
(you can close at any time, then you call the person who you'd like to make the real deal with)
A Voting Protocol:
For admins:
|/propose <issue>: create a new issue (with some secret name you only give to the people who will vote)
|/notify_quorum <issue> <n>: proposer can set a level at which they will be notified when enough votes are cast, optional
|/close <issue>: like closing an auction, cleans stuff up and stops voting, stats are retained until a new issue is proposed on the same key
For voters:
|/yay <issue>
|/nay <issue>
+ and - for shortform, breaks with common uses of them, but its voting so maybe it's clear
change the context/meaning. +/- is add/remove count
For any:
|/query <issue>: get the counts
voting? there are many voting structures. this should be the simple obvious one. if anybody wants the more complex, they can create it themselves (or commission somebody to)
Review Protocol:
/review <thing> <stars> <comment..?> : only one rating per address
/get <thing>: get average rating, last comment
|<thing> --> /get <thing>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment