Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Local save-file format - two files seems awkward #19

Open
pdkl95 opened this issue Aug 10, 2013 · 2 comments
Open

Local save-file format - two files seems awkward #19

pdkl95 opened this issue Aug 10, 2013 · 2 comments

Comments

@pdkl95
Copy link

pdkl95 commented Aug 10, 2013

Currently, when a recording is saved locally, it is saved as two files.

  • /tmp/showtime.$PID.script
  • /tmp/showtime.$PID.times

(with the matching --retry option requiring two mandatory arguments)

This sems... awkward. It would be a lot more consistent with most programs (and easier to learn) if those files were wrapped up into a single object. A few ways this could be accomplished:

  1. Use a directory

Simply change the prefix to /tmp/showtime.$PID/ and put the script and
times files in it. This requires very few changes. I'm uncertain on if the
use of a directory could be a problem.
2. Some sort of container format (e.g. tar)

A container is also very easy to implement, but it would complicate live
editing, such as when -e is used. (I don't recommend this method)
3. Appending the files, with some separator.

A file that had the timing data up to some section marker would be easy
to parse and still be editable. For example

[...]
0.000154 232
0.000049 2
0.000015 19
0.001528 549
END_TIMING_DATA
Script stated on Sat 10 Aug 2013 07:51:50 AM PDT
[...]

Unfortunately, non-printable data in the script would cause problem
when editing the file, and it would probably be necessary to base64
or \0xxx escape the script data itself. It would also result in the need to
edit a potentially very large file.
4. Some sort of fancier format

Currently, editing the times file requires a bit of guesswork. If script
fragments could be seen interleaved with the times, though, it would allow
for much easier editing.

This method probably contains all of the problems that the previous (Append)
method has, and would require a significantly larger amount of time
to implement. This method could be cleanest to extend in the future,
though, if/when other features are added.

All of these would allow for setting the full output name (path) with a
traditional -o <PATH> and simply --retry <PATH>

Currently, I'd probably recommend the directory method as it requires very minimal changes. A well-defined file-format would be nice, though...

@poulson
Copy link

poulson commented Aug 12, 2013

I don't see any problem with keeping the recording split into two consistently named files.

@ConradIrwin
Copy link
Owner

The reason for the two-file format is purely historical: I found out about script (which uses this format) before ttyrec (which uses a superior one-file format).

Unfortunately, because I'm lazy I converted from ttyrec-format to script-format on the client so that I didn't have to update ConradIrwin/showterm.io.

I would love to change to using the ttyrec format, which is a three-phase process:

  1. Implement the ttyrec parser in javascript.
  2. Make the server always serve ttyrec format.
  3. Update the client to convert from script format to ttyrec format and upload new showterms in that.
    (optional: run a migration to update the current database).

I'd love a hand with all of this, otherwise may be able to get some of it done next weekend.

Conrad

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants