zippy / anansi Goto Github PK

Currently there's no way to know which contacts were created via a channel. So auto-deleting them when deleting a channel isn't possible. We need to figure out if this important, and if so add a scape to hold that information.

could be redis, couchdb, or something else.

There may be some small modifications that need making, as well as testing that all dependencies work on 1.3. Not sure if aleph does yet or not.

At the very least a simple search groove

We need to be able to edit the channel information.

currently you can't tell if a channel like IRC or XMPP is open or closed.

There has to be a keyword scape that allows searching content across all droplets.

This also probably requires improving the scape query system...

User should be able to delete a channel from the setup menu.

Question: what happens to any associated droplets?

User should be able to delete tags

There has to be a way to include in a query a request not to see certain droplets, i.e. ones tagged as in the trash, or spam, etc.

The plethora of contacts needs to be hide-able, or something.

1bf80214770837250b fixes a bug caused by nil subjects in e-mail. The problem is that you can make JSON elements with nil items and this was causing it up the line. The fix is a bad fix in that it simply skips such e-mails. Need to look deeper at which kinds of e-mails produce that result in the JavaMail code.

UI should add html using the goog.EditField component instead of textarea as is used now.

There seems to be a timezone problem where dates parsed by java.util.Date. don't take into account the +0000 in the rfc-822 string passed in.

FAIL at (util.clj:17)
Expected: "2011-10-04T03:21:40.000Z"
Actual: "2011-10-04T05:21:40.000Z"
FAIL at (util.clj:19)
Expected: "2011-10-04T03:21:40.000Z"
Actual: "2011-10-04T05:21:40.000Z"

email & twitter search channels don't necessarily have a natural "from" address as do xmpp to add to the "me" contact when the channel is created. Figure out how to handle this at create time for those channels.

Currently you can only have one address of a given channel type per contact. This needs to be fixed.

• attachments
• forward
• reply-all
• spam filter

currently lots of state stuff is just being stored in vars accessed by globals like: s/grooves

This should probably be refactored into a single state object so that reseting state is automatic, and so on. Also this might cleanly allow for various different kinds of state info, i.e. some of it is the local stuff on the client side, and other aspects are syncronized to the server.

Currently the UI is doing a bunch of manual translations on channel names to try and discover the channel type so it can manage the contacts and other things. This needs to be made discoverable in the state.

For example see:
ss/src/streamscapes.clj#get-channel-ident-scape-from-type

Jasmine?

Google Closure Testing: http://closure-library.googlecode.com/svn/docs/namespace_goog_testing.html

?

ability to select contact(s) and merge into other existing contact

We need a first pass through the css to beautify the UI.

If a carrier (channel) can carry a particular grammar, the groove/grammar language must also specify how to convert from the base grammer to that channel's encoding of the groove. The current example we have of this is that xmpp messages natively look like they match subject-body-grammar, but really they are used for simple-message. This means that when creating droplets, folks will use the simple-message groove, but that has to be converted to the base grammar.

Currently we do groove matching on receive, but we don't handle groove transformation on send. This must be done.

Not that for now this is hacked to work in the xmpp-out-bridge.

• you shouldn't be able to delete your own contact info

Currently when you create a new contact or edit it the values client side aren't actually refreshed. We have to match the state in the dialog with the state sent to the server.

This means either mean reconstructing the dialog or inserting it. Something smart should be done about how to handle this ala pivotal stuff that Lews has been describing.

editing contact needs to allow not specifying some channel addresses without creating that big nil bug.

gotta be able to pick more than one droplet to apply an action to.

1- delete contacts
2- hide, or something, contacts that are auto-created. Maybe all such contacts are the "unknown person" or something.
3- merge/move contact
4- multiple addresses of a given type per contact

There has to be some way where users can connect a detected incoming droplet, (by some grammar, or something) to an outgoing flow.

Gotta be able to make the contacts list shrink down...

Streamscapes icons needed for UI

Client is far too slow to refresh after about 100 droplets. Gotta fix somehow.

all over the place we are filtering against :last-address in the receptor list. There should be meta-information about receptors that stores that.

User should be able to delete a droplet.

Currently a copy of the compository is instantiated into grooves the first time the code runs. This means that if you update the compository you won't see any changes reflected in already running code. This needs to be addressed. It's part of versioning etc..

All over the place, including in the scape names, we started with the notion of "identity" so there are ident receptors and ident-scapes and so on. This needs to be renamed to contact, to align with our new notion of what it actually is.