mirror of
https://github.com/asciinema/asciinema.git
synced 2026-04-25 16:05:52 +03:00
[GH-ISSUE #70] Decouple terminal recording from asciinema.org #667
Labels
No labels
bug
compatibility
feature request
fit for beginners
help wanted
hosting
idea
improvement
packaging
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/asciinema#667
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ku1ik on GitHub (Aug 11, 2014).
Original GitHub issue: https://github.com/asciinema/asciinema/issues/70
Recording should not be tied to asciinema.org.
You should be able to:
asciinema rec <filename>,asciinema play <filename>,asciinema play <url>,This is a prerequisite for #49, it is in fact a simpler version of it.
Saving/sharing/replaying from a local file means we have to decide on the data format.
Requirements for data format:
asciinemaand external toolsOption 1: use current format used by asciinema.org
zip file with custom extension (like
.asciicastfor ex), including 3 files:meta.json- with metadata like width/height of terminal, title, etcstdout- raw stdout bytes,stdout.timing- timing information.Current implementation uses these 3 files when uploading the recording to asciinema.org.
This however isn't really compatible with live streaming idea and doesn't address all the requirements above.
Option 2: new JSON based format
With frames inlined, to be used when persisted:
With frames delegated to an URL, to be used when streaming:
frames_urlis a URL to streaming endpoint, either http or websocket.Format of the single frame:
JSON isn't suited to store arbitrary binary data in strings and raw stdout output contains lots of non-printable bytes so we should encode them. Base64 or encoding each byte in hex or utf would do.
or
Streaming endpoint(s) could be implemented to spit out each new frame in a separate line.
@choucavalier commented on GitHub (Oct 26, 2014):
What's up? When will we be able to keep our records local and use them from our side?
@ku1ik commented on GitHub (Dec 19, 2014):
@toogy once it's ready ;)
@crosbymichael commented on GitHub (Dec 19, 2014):
The json objects with base64 seem to work well and is very simple to implement in go as the marshaler handles encoding
[]byteto base64 if needed.@muescha commented on GitHub (Dec 19, 2014):
For editing base64 is not good.
It hides the content :(
One requirement should be: content is readable and if i make diffs the i should see which typo i fixed in a version.
Plain text instead of base54 is my priority.
@muescha commented on GitHub (Dec 19, 2014):
For editing base64 is not good.
It hides the content :(
One requirement should be: content is readable and if i make diffs the i should see which typo i fixed in a version.
Plain text instead of base54 is my priority.
@muescha commented on GitHub (Dec 19, 2014):
Non printable bytes should encoded as human readable commands.
@PragTob commented on GitHub (Dec 19, 2014):
Just FYI, there is a branch on my fork where I already went through the work that files get saved locally and extracted all the ruby files from the web app that were used for post processing: https://github.com/PragTob/asciinema/commits/save-files-locally
I don't have time right now to adjust it to all the requirements listed here, but it could be a starting point. We used it successfully in a project like this :)
@ku1ik commented on GitHub (Jan 26, 2015):
@muescha I understand this concern. However, it's important that this file is easily readable by javascript. The obvious choice for file format here is JSON. Now, if JSON allowed control characters (range 0x00-0x1F) we could easily store the data directly in JSON strings, ie:
"foo\x09bar\x1b[1mbooold\x1b[0m". Unfortunatelly, while Javascript does allow storing both printable characters and control characters in its strings, JSON doesn't (you get parsing error with any decent parser).I don't really want to create additional, human readable abstraction over control characters, it feels like an unnecessary complication with benefits which don't really justify it. Anyway, I'm happy to discuss all alternatives.
@ku1ik commented on GitHub (Jan 26, 2015):
I did a bit more research. I was partially wrong. I did some tests, and looked at JSON format RFC. It seems you cannot encode control characters in JSON string directly (raw byte) or as
"\x09", but you can do it by specifying Unicode codepoint value as"\u0009".It means that this should be possible:
"foo\u0009bar\u001b[1mbooold\u001b[0m"@muescha commented on GitHub (Jan 26, 2015):
the idea behind humand readable commands is to edit the json and fix errors/typos or remove sensitive data from recordings.
example how it can be done:
@ku1ik commented on GitHub (Jan 26, 2015):
@muescha I understand it, sure. However...
To achieve what you described the recorder would need to include a complete and correct ANSI parser. See here for more details: http://www.vt100.net/emu/dec_ansi_parser . Basically, a terminal is a state machine where the meaning of every byte printed to stdout can change between states. You cannot just assume that
0x09is "tab", because0x09can also mean "put" action in "DCS passthrough" state (as seen on this diagram http://www.vt100.net/emu/vt500_parser.png).I think the best we can get here is to keep the data in UTF-8 encoded string, with every non-printable character encoded as
\u1234. For example:@hai-nguyen-van commented on GitHub (Feb 14, 2015):
+1 👍
@dave-tucker commented on GitHub (Feb 17, 2015):
👍 I'd like to see this functionality.
@ku1ik commented on GitHub (Feb 24, 2015):
Recording and replaying from local files has been implemented in #80. I need to document the new file format and update asciinema.org code to accept it. Then we should have a new release soon.
@hai-nguyen-van commented on GitHub (Feb 24, 2015):
@sickill Thanks
@hai-nguyen-van commented on GitHub (Feb 24, 2015):
@sickill Thanks
@ku1ik commented on GitHub (Mar 2, 2015):
Hey! Please help testing 1.0.0.rc1: https://github.com/asciinema/asciinema-cli/releases/tag/v1.0.0.rc1
@cmoulliard commented on GitHub (Mar 4, 2015):
I have done some tests with the release 1.0.0.rc1 and that looks great. I have one additional question : Would it be possible to upload the asciinema record not on asciinema.org web site but on our own web server ? Is it possible ?
@choucavalier commented on GitHub (Mar 4, 2015):
@cmoulliard 👍
@ku1ik commented on GitHub (Mar 5, 2015):
@cmoulliard thanks for testing.
Re uploading to other place than asciinema.org:
You can set up your own asciinema site and point the recorder to it as described here in FAQ: https://asciinema.org/docs/faq
@cmoulliard commented on GitHub (Mar 9, 2015):
@sickill I have done a test using locally on my machine a Python SimpleHTTPServer but I get a error '501' during HTML post communication :
The json file is well created at the location indicated but I suspect that SimpleHTTPServer of Python does not support HTTP POST. Can you make some recommendations please ?
@ku1ik commented on GitHub (Mar 9, 2015):
@cmoulliard it's not possible to use any HTTP server to accept asciicasts. You need your own instance of asciinema website. This repository contains the code of the website+API: https://github.com/asciinema/asciinema.org
@ku1ik commented on GitHub (Mar 9, 2015):
@cmoulliard it's not possible to use any HTTP server to accept asciicasts. You need your own instance of asciinema website. This repository contains the code of the website+API: https://github.com/asciinema/asciinema.org
@cmoulliard commented on GitHub (Mar 9, 2015):
Thx. Should be good to mention that into the FAQ. Is it possible to provide a skeleton of the web project that we could run locally as I suppose that we only need one HTML file + css + javascripts if we would like to integrate asciinema into our own web server ?
@ku1ik commented on GitHub (Mar 9, 2015):
I'll update FAQ, thanks.
Currently hmlt+js+css wouldn't be sufficient as the recording is being preprocessed after it is uploaded to the website. It's being converted to the simple format that is easy to understand for the JS player.
I plan to update the player so it can directly play asciicasts without a need for any preprocessing. It will be possible then to just have a simple html+js+css combo to host the recordings on your own site, just as you imagined.
@cmoulliard commented on GitHub (Mar 9, 2015):
Thx. Excellent news. Great project indeed.
@choucavalier commented on GitHub (Mar 9, 2015):
@sickill: that would be so great 👍
@ku1ik commented on GitHub (Mar 12, 2015):
1.0 has just been released with local recording support.
@cmoulliard commented on GitHub (Mar 12, 2015):
I have done a test but I don't see how I could generate static content for a local web server.
BTW, the help command of
asciinema playeris not really verbose :@ku1ik commented on GitHub (Mar 12, 2015):
@cmoulliard this doesn't look like 1.0. Can you check
asciinema --version?@ku1ik commented on GitHub (Mar 12, 2015):
@cmoulliard this doesn't look like 1.0. Can you check
asciinema --version?@cmoulliard commented on GitHub (Mar 12, 2015):
Here is the version :
~/Downloads/asciinema-1.0.0-darwin-amd64$ ./asciinema --version
asciinema 1.0.0-062ba8a
@cmoulliard commented on GitHub (Mar 13, 2015):
Is it the latest version ? If this is the case, there is a problem to display the help messages and we can't generate content for local HTTP Server
@ku1ik commented on GitHub (Mar 14, 2015):
You used
asciinema play -hand then./asciinema --version. Note the difference:./Is it possible that you have 0.9.9 installed in your PATH?
@cmoulliard commented on GitHub (Mar 15, 2015):
Version tested is : ./asciinema --version --> asciinema 1.0.0-062ba8a
Nevertheless, we have discussed the possibility to upload a video/*.json
file to our own web site but this feature is not there as we can't only
upload yo asciinema.org
On Sat, Mar 14, 2015 at 9:39 PM, Marcin Kulik notifications@github.com
wrote:
Charles Moulliard
Apache Committer / Architect @RedHat
Twitter : @cmoulliard | Blog : http://cmoulliard.github.io
@ku1ik commented on GitHub (Mar 15, 2015):
See here: https://github.com/asciinema/asciinema/issues/70#issuecomment-77817450
You can set ASCIINEMA_API_URL env var (as described in FAQ on the site) , or set it in configuration file (see Configuration section in readme).
@cmoulliard commented on GitHub (Mar 16, 2015):
Question: In one of your comments, you have mentioned that "It will be possible then to just have a simple html+js+css combo to host the recordings on your own site, just as you imagined." Is this feature available now ?
@ku1ik commented on GitHub (Mar 16, 2015):
Ah, yes. I should have been more clear on that, sorry. I plan to do that in the future, but it's not available yet.
@ku1ik commented on GitHub (Mar 16, 2015):
Ah, yes. I should have been more clear on that, sorry. I plan to do that in the future, but it's not available yet.
@cmoulliard commented on GitHub (Mar 16, 2015):
This is what you develop here ? https://github.com/asciinema/asciinema-player
@cmoulliard commented on GitHub (Mar 16, 2015):
But this project does not support the same json format as you proposed with asciinema 1.0 ...
@cmoulliard commented on GitHub (Mar 16, 2015):
The projects is almost done excepted that code "asciinema player" and "ascinema player js" should be aligned to support the same json format
I have done a small modification to already pass as parameter the json file recorded by asciinema
@ku1ik commented on GitHub (Mar 16, 2015):
The JS player expects preprocessed data and it doesn't support new asciicast format directly. asciinema.org is converting this new json format into the simple format that is readable by the player.
I'll be working on updating the player to support new format directly. Once it's done the code you proposed will work indeed.