Move content parsing to the client

[holmesal]

Because of #160, we need to move at least gif handling to the client. Let's just move everything (it's really easy).

Here are the steps:

1. Recognize when a link is posted (with any old regex)
2. Make a HEAD request (it's a type, like GET or POST, that returns only the headers for the content) to the url(s) you pulled out of the message.
3. Switch on the content-type header you get back, and build+send the message accordingly. list of content types.

So it's pretty straightforward, should be doable in a couple of hours on each platform. It does give us a bit more code surface to maintain, but it also takes a significant load off the server and that's something everyone can enjoy

[DogsForArms]

So this is only when someone has copied a url into their compose-message-text-field? Sounds good.

[DogsForArms]

Oh wait. it's parsing hubot's non mp4 response. Ok so specifically, something like this?

Person A: "Hubot animate me something" then maybe hubot ~ONLY~ responds to personA "http://someWebUrlPointingToA.gif" then person A (with their own IP) ~ONLY~ changes that url into something more like "http://gifycat.com/#newVersionAsAn.mp4" and person A tells hubot about it, and hubot then responds to the chat with an mp4 for all?

[DogsForArms]

or an edit on the above, only one person delegates parsing hubot's response from a gif to an mp4 via gifycat, not necessarily the sender of the hubot command, but instead, the first person who receives the message from hubot. (person A might have locked their phone)

[holmesal]

@DogsForArms it's both - content-parsing with pasted URLs can be moved to the client, but hubot's an interesting edge-case.

Clients should definitely be responsible for their own messages, and I think hubot messages should be "open-season" - any client can convert them. We can use a transaction here.

This isn't a big deal yet, but it's something we'll want to push out an update on iOS around a week or so before we want it to be live.

[DogsForArms]

ok sounds good. not sure if they've fixed transactions on ios yet.

[holmesal]

They should, they're just about to hit 100,000 developers :)

[DogsForArms]

WOW

[holmesal]

I think there's an even simpler solution here - make the head requests/content-parsing a display problem, not a data problem.

Any client that sees a URL makes a HEAD request to determine the type, and if it's a type that the client recognizes then the client fetches the content and displays it however is necessary. If it's not, it just stays a URL.

So basically all of the messages in firebase would go back to type:text (for now, but let's leave the door open to doing type:join, type:leave, type:poke etc down the road), and every client would individually figure out how to best display any detected URLs.

Yo diggity?

[holmesal]

Based con conversation today:

Optimization for parsing / GFYCAT solutions

1. The first client to see a message is responsible for parsing it on the behalf of the sender.

Pros - no server load Cons - coordination, out of date versions

2. Every sender looks for unparsable things before they send (not images, gifs, etc), and every client looks for parseable things on receive (images, gifs, etc).

The server only sees things that clients aren't able to see for themselves.

1. Sender types a message + hits send.
2. Sender parses for URL and, if found, makes a head request for that URL.
3. If the content-type is something that this client would be able to display, does nothing. If it comes back as something else, he creates a parse request to ask the server to check it out.

Pros - no server load Cons - complexity, out-of-date-versions, potential choppy scrolling

1. Sender updates the message on HEAD request response

[holmesal]

Closing this for now, but we'll dig this up down the road when we get the time to do some optimization