Create archive of TowTruck sessions #57

Open
aarondruck opened this Issue Feb 28, 2013 · 15 comments

Comments

Projects
None yet
5 participants
@aarondruck
Contributor

aarondruck commented Feb 28, 2013

create searchable archive of towtruck sessions

@ianb

This comment has been minimized.

Show comment Hide comment
@ianb

ianb Feb 28, 2013

Member

searchable? Or just a way to archive them and replay them?

Member

ianb commented Feb 28, 2013

searchable? Or just a way to archive them and replay them?

@ghost ghost assigned aarondruck Mar 4, 2013

@simonwex

This comment has been minimized.

Show comment Hide comment
@simonwex

simonwex Mar 4, 2013

Member

I think the next step in this one is to do some design around the view/replay/search functionality so we know what we'll need to save.

Member

simonwex commented Mar 4, 2013

I think the next step in this one is to do some design around the view/replay/search functionality so we know what we'll need to save.

@ianb

This comment has been minimized.

Show comment Hide comment
@ianb

ianb Mar 4, 2013

Member

My assumption is that we'd record things at the connection level, saving everything outgoing and incoming (along with timestamps of the messages). Then to replay we'd pick one channel (in or out, or both) and simply emit those messages at appropriate times. We'd probably mark the messages as being part of a replay, to let components change what they do based on that, but I don't have any ideas of what would be different right now, except perhaps we might change nicknames or other things slightly to show that it's a recording and not a live interaction.

In either case, the person replaying will get the experience of what a third person would have viewed. They won't see local clicks, etc. (Until perhaps we have a follow mode of some sort – but then it'll kind of fall out automatically once we implement those other features).

Doing it at a low level will mean that everything happens unless we stop it from happening, so I don't think we'd need to design much, just refine the result.

We'd want to start the recording with a fake "hello" message, to trigger initialization messages that we'd want in the recording.

Member

ianb commented Mar 4, 2013

My assumption is that we'd record things at the connection level, saving everything outgoing and incoming (along with timestamps of the messages). Then to replay we'd pick one channel (in or out, or both) and simply emit those messages at appropriate times. We'd probably mark the messages as being part of a replay, to let components change what they do based on that, but I don't have any ideas of what would be different right now, except perhaps we might change nicknames or other things slightly to show that it's a recording and not a live interaction.

In either case, the person replaying will get the experience of what a third person would have viewed. They won't see local clicks, etc. (Until perhaps we have a follow mode of some sort – but then it'll kind of fall out automatically once we implement those other features).

Doing it at a low level will mean that everything happens unless we stop it from happening, so I don't think we'd need to design much, just refine the result.

We'd want to start the recording with a fake "hello" message, to trigger initialization messages that we'd want in the recording.

@simonwex

This comment has been minimized.

Show comment Hide comment
@simonwex

simonwex Mar 4, 2013

Member

What DOM would we start with? The original view, or a current view of the URL that the session was started at?

Member

simonwex commented Mar 4, 2013

What DOM would we start with? The original view, or a current view of the URL that the session was started at?

@ianb

This comment has been minimized.

Show comment Hide comment
@ianb

ianb Mar 4, 2013

Member

If we're not doing DOM recording (which I don't think we'd want to do to start), you'd start on the page where the session started. We'd be relying on that page being the same as when the recording was made.

Member

ianb commented Mar 4, 2013

If we're not doing DOM recording (which I don't think we'd want to do to start), you'd start on the page where the session started. We'd be relying on that page being the same as when the recording was made.

@simonwex

This comment has been minimized.

Show comment Hide comment
@simonwex

simonwex Mar 4, 2013

Member

This seems like a bit of a can-o-worms until we commit to doing some DOM recording. My thought is that we hold off until we do, or this feature drives it.

Thoughts?

Member

simonwex commented Mar 4, 2013

This seems like a bit of a can-o-worms until we commit to doing some DOM recording. My thought is that we hold off until we do, or this feature drives it.

Thoughts?

@ianb

This comment has been minimized.

Show comment Hide comment
@ianb

ianb Mar 4, 2013

Member

I don't see why it's particularly worse than our current expectations that sites have stable DOMs. The long-term viability of a recording would be damaged, but I don't think we need to worry about that in order to start on the feature.

Member

ianb commented Mar 4, 2013

I don't see why it's particularly worse than our current expectations that sites have stable DOMs. The long-term viability of a recording would be damaged, but I don't think we need to worry about that in order to start on the feature.

@simonwex

This comment has been minimized.

Show comment Hide comment
@simonwex

simonwex Mar 4, 2013

Member

The fact that it's a recording, to me means the long-term viability is the important part.

What milestone should we target with this one? Beta?

Member

simonwex commented Mar 4, 2013

The fact that it's a recording, to me means the long-term viability is the important part.

What milestone should we target with this one? Beta?

@ianb

This comment has been minimized.

Show comment Hide comment
@ianb

ianb Mar 4, 2013

Member

I think it's a when-we-feel-like-it feature. Its first iteration won't be useful to many people, but its first iteration is necessary before we do the second iteration, and so on. I don't even know now if this is something we care about for the Beta.

Member

ianb commented Mar 4, 2013

I think it's a when-we-feel-like-it feature. Its first iteration won't be useful to many people, but its first iteration is necessary before we do the second iteration, and so on. I don't even know now if this is something we care about for the Beta.

@aarondruck

This comment has been minimized.

Show comment Hide comment
@aarondruck

aarondruck Mar 6, 2013

Contributor

I say we don't do this for Beta either. Let's add this to the backlog. Do I just close it out?

Contributor

aarondruck commented Mar 6, 2013

I say we don't do this for Beta either. Let's add this to the backlog. Do I just close it out?

@ianb

This comment has been minimized.

Show comment Hide comment
@ianb

ianb Mar 11, 2013

Member

Here's what I'm thinking for an initial implementation:

You enter /record in the chat to start. This pops up a window to https://towtruck.mozillalabs.com/towtruck/recorder.html#&towtruck=shareId

This adds a "virtual" participant, who is the recording agent. It sends the hello message, triggering all the normal responses, and says hello-back later as necessary. It is not however a full client. It creates its own channel to the hub, and all participants see it as a virtual participant. It never goes to any URLs, never does any actions, it just watches.

As messages come in it records them. It adds timestamps to all messages, but otherwise doesn't change them. For now maybe it stores the messages in a textarea and expects the user to copy the text out and into some destination. Ideally they get put in some location where they can be loaded using CORS.

A second command /load URL loads a message log from the URL, closes the chat window, and immediately starts playing back the log, based on the timing in the log. This is done by simply emiting each message from the log. I don't think anything else is required – emiting the messages and ignoring responses should be sufficient. Probably a "bye" message should be added at the end regardless of whether it is in the log.

Member

ianb commented Mar 11, 2013

Here's what I'm thinking for an initial implementation:

You enter /record in the chat to start. This pops up a window to https://towtruck.mozillalabs.com/towtruck/recorder.html#&towtruck=shareId

This adds a "virtual" participant, who is the recording agent. It sends the hello message, triggering all the normal responses, and says hello-back later as necessary. It is not however a full client. It creates its own channel to the hub, and all participants see it as a virtual participant. It never goes to any URLs, never does any actions, it just watches.

As messages come in it records them. It adds timestamps to all messages, but otherwise doesn't change them. For now maybe it stores the messages in a textarea and expects the user to copy the text out and into some destination. Ideally they get put in some location where they can be loaded using CORS.

A second command /load URL loads a message log from the URL, closes the chat window, and immediately starts playing back the log, based on the timing in the log. This is done by simply emiting each message from the log. I don't think anything else is required – emiting the messages and ignoring responses should be sufficient. Probably a "bye" message should be added at the end regardless of whether it is in the log.

@simonwex

This comment has been minimized.

Show comment Hide comment
@simonwex

simonwex Mar 11, 2013

Member

+1

Member

simonwex commented Mar 11, 2013

+1

ianb added a commit that referenced this issue Mar 11, 2013

@ianb

This comment has been minimized.

Show comment Hide comment
@ianb

ianb Mar 11, 2013

Member

I couldn't help it, once I got to thinking about how to do it I had to try to do it. Now you can do /record in the chat window and you get a popup. If you copy/paste and publish the log somewhere accessible, you can do /playback URL to start playing the logs.

It should work somewhat intelligently across multiple pages. It'll play the first hello message from the new page, but then pause. When you start a playback it'll store your location in localStorage until you are finished, so it'll pick back up if you follow along to the new page.

Member

ianb commented Mar 11, 2013

I couldn't help it, once I got to thinking about how to do it I had to try to do it. Now you can do /record in the chat window and you get a popup. If you copy/paste and publish the log somewhere accessible, you can do /playback URL to start playing the logs.

It should work somewhat intelligently across multiple pages. It'll play the first hello message from the new page, but then pause. When you start a playback it'll store your location in localStorage until you are finished, so it'll pick back up if you follow along to the new page.

@simonwex

This comment has been minimized.

Show comment Hide comment
@simonwex

simonwex Mar 11, 2013

Member

Awesome.

Member

simonwex commented Mar 11, 2013

Awesome.

@csalexwilliams

This comment has been minimized.

Show comment Hide comment
@csalexwilliams

csalexwilliams Nov 29, 2015

Hi Ian -- I'm a big Mozilla fan and longtime user of TogetherJS. I've used it for a number of academic projects, and I am beginning integrate it more heavily into my graduate research.

More recently, I've started playing with the /record and /playback command. Whenever I use the command, I receive a warning from Playback.js that states that the mouse event couldn't be replayed (i.e. "could not play back message"). I tested and confirmed that the behavior is present in both Firefox and Chrome.

If you don't have the time to figure out why things might be going awry, can you direct me to a working example?

Thanks!

Hi Ian -- I'm a big Mozilla fan and longtime user of TogetherJS. I've used it for a number of academic projects, and I am beginning integrate it more heavily into my graduate research.

More recently, I've started playing with the /record and /playback command. Whenever I use the command, I receive a warning from Playback.js that states that the mouse event couldn't be replayed (i.e. "could not play back message"). I tested and confirmed that the behavior is present in both Firefox and Chrome.

If you don't have the time to figure out why things might be going awry, can you direct me to a working example?

Thanks!

csalexwilliams added a commit to csalexwilliams/togetherjs that referenced this issue Nov 29, 2015

Fixed _getChannel for Session objects. (#57)
Explicitly defined _getChannel method for Session ClassObjects. Should
allow recording/playback to work appropriately.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment