Easier-to-use URLs

[mbomb007]

TIO has a nice URL scheme for each language, so if I want to use PHP, I can go to https://tio.run/#php

I would really like a way to easily pick which language I'm on with a quick type in the address bar. All I had to type was tio.run#php. This way, I could also easily bookmark a language, or see in my browser history which language I was using for each program.

As it is right now, if I select PHP on ATO, I get sent to https://ato.pxeger.com/run?1=m724IKNgwYKlpSVpuhZoFJQGAA, and this doesn't tell me anything about the language I'm on, nor is it something I can remember in order to type it in my address bar. I'd like to see something like: https://ato.pxeger.com/#php?1=m724IKNgwYKlpSVpuhZoFJQGAA

I'd also like a shorter or simpler URL in general than ato.pxeger.com, as that's hard to remember, but that's more of a nitpick.

[pxeger]

This is partly a duplicate of #46, but I'll leave it open because you've also provided some other valuable feedback.

You can already use https://ato.pxeger.com/run?L=php, but you're right that it could be shorter.

The idea for a shorter name and domain has been discussed a few times before, but I haven't come up with anything that is:

• short
• unique
• better than the frankly horribly clunky "Attempt This Online"
• available as a cheap domain name ;)

[mbomb007]

You can already use https://ato.pxeger.com/run?L=php

That's helpful to know. Would it be possible to keep the L=php part in the URL after arriving, and also only switch to the complicated-looking URL after something has been entered?

[PIG208]

Would it also be possible to pass a query parameter C with the value of the code encoded in base64 without compression? So that third party apps can programmatically generates links to the playground from user input, without replicating this specific implementation detail:

attempt-this-online/frontend/lib/urls.ts

Lines 7 to 27 in c20bd16

	function save(data: any): string {
	const compactedData = [
	data.language,
	data.options,
	data.header,
	data.headerEncoding,
	data.code,
	data.codeEncoding,
	data.footer,
	data.footerEncoding,
	data.programArguments,
	data.input,
	data.inputEncoding,
	];
	const msgpacked = msgpack.encode(compactedData);
	const compressed = deflateRaw(msgpacked);
	const b64encoded = fromUint8Array(compressed, true); // true means URL-safe
	const params = new URLSearchParams();
	params.set(SCHEMA.toString(), b64encoded);
	return params.toString();
	}

The specific use case for us is generating a link next to any markdown code block. It opens up a code playground like ato using the language chosen for highlighting.

[mbomb007]

I think it would make more sense to add an API endpoint for link generation.

[PIG208]

Yeah. Maybe an endpoint that returns an HTTP 302 response?

[mbomb007]

Yeah. Maybe an endpoint that returns an HTTP 302 response?

I meant, create an endpoint where you can pass the data:

     data.language, 
     data.options, 
     data.header, 
     data.headerEncoding, 
     data.code, 
     data.codeEncoding, 
     data.footer, 
     data.footerEncoding, 
     data.programArguments, 
     data.input, 
     data.inputEncoding, 

as parameters, and it will return the URL in the response.

[PIG208]

Ah, I see. Maybe a GET endpoint that takes these data as query parameters, and redirects in response?

Redirection would be prefer because then this alternative URL can be used in place of the compacted one (like an alias), and it saves the implementation overhead of needing a roundtrip to fetch the URL and store the response. The URL would still be available to applications if they choose to not follow it.

[mbomb007]

Ah, I see. Maybe a GET endpoint that takes these data as query parameters, and redirects in response?

Redirection would be prefer because then this alternative URL can be used in place of the compacted one (like an alias), and it saves the implementation overhead of needing a roundtrip to fetch the URL and store the response. The URL would still be available to applications if they choose to not follow it.

The thing is, if the server logs requests (maybe it doesn't?), then the code is going to be in the log files if it's a GET request. (And also uncompressed, making the log files longer.) It should be a POST request and avoid the convenience of alternative URLs.

[mbomb007]

In the end, it's all up to @pxeger, of course.