buglabs/bugswarm-tools

Tools for developing on the BUGswarm platform.

bugswarm-tools's Issues

Presence problems as a result of the python httplib library

Currently, it does not appear that the HTTPLibConnection.close() method is properly closing the connection, so the consume.py and produce.py methods do not remove the resources they use from the MUC when killed. We are thinking about porting these scripts to use sockets rather than this library.

Remove content-type from all methods

No longer needed with 0.3.0

Update for 0.3.0 release

Update according to changes expressed in c4milo's release email.

Notes:

• Content type is no longer required as a header for POST, PUT, and DELETE methods
• Resource creation no longer requires an ID field

Prove/disprove that produce/consume.py do not leave resources in MUC after leaving.

Self-explanatory

Look into producing status codes for when a method has no response text

Destroying a resource for instance

Abstract getting the server hostname from get_keys to get_server/get_hostname

Rename methods to match API docs

Change things like 'list_user_swarms' to list since it is all in context.

Get rid of hidden Python terms

Make sure none of the Python terms are being overridden by our code.

cannot create a swarm with a resource as both producer and consumer using swarms.py

Summary:

You cannot create a swarm with a resource as both a producer and a consumer using swarms.py. The resources are specified as a map where the resource is the key and "producer" or "consumer" is the value. Since it is a map you cannot specify the same resource twice.

Expected behavior:

It would be nice if there was a way of specifying that a resource could be both a producer and a consumer.

change consume.py from 'GET' to 'POST'

Self-explanatory

Ability to create swarms containing resources by default to swarms.py create method

Self-explanatory

Rename to 'swarm', include command-line swarm client to wrap functions

Three reasons:

1. Keep in line with familiar tools that interface with services:
   node for joyent-node
   jitsu for nodejitsu
   hub for github
2. Reduce ambiguity by pointing directly to a command ( 'use swarm' > 'use bugswarm-tools' )
3. Increase usage of domain specific language to give product a personality

@aturley, @barberdt would like feedback before I go ahead with this (BIKESHEDDING)

producer.py sends invalid json to BUGswarm in some cases

Summary:

Commit ab42f17 intentionally sends invalid json in several circumstances.

ab42f17#L0R36
This will produce the following json:
{"message": {"to": ["SWARM_ID"], "payload":}}
There is no value associated with the payload key. The same thing will happen here:
ab42f17#L0R47

The system seems to keep behaving as expected, so this doesn't seem to break anything right now. However, intentionally sending invalid json makes me nervous, especially if this tool is supposed to serve as a reference.

If we just need to send some garbage to initiate the connection, then we should send a small piece of garbage and note in a comment why we're doing it. If we can get away with sending something else as the payload(a bare newline or something like that) then maybe that's a cleaner option.

Create invitations.py

Create invitations.py that uses the send, list sent invitations, list received invitations, and respond methods.

Better error handling than printing stack traces for some methods

Some of the methods will return a stack trace if you give wrong information (./api_keys create ). I am going to try and make this a bit nicer (something along the lines of "invalid password, try again").