You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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...
The text was updated successfully, but these errors were encountered:
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:
Implement the ttyrec parser in javascript.
Make the server always serve ttyrec format.
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.
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:
Simply change the prefix to
/tmp/showtime.$PID/
and put thescript
andtimes
files in it. This requires very few changes. I'm uncertain on if theuse 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
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 toedit 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...
The text was updated successfully, but these errors were encountered: