mimsoftware / haste-server Goto Github PK

Store the document in multiple parts using split key names:

"data.{key}" = "{base64 encoded gzipped file}"
"info.{key}" = "{stringified json object containing metadata about the file}"

This prevents having to store the document inside a stringified json object. In the future this would likely make streaming large objects directly to redis easier to implement. This also allows for potentially splitting really large files into multiple entries, a la

"data.0.{key}" = "..."
"data.1.{key}" = "..."

The downside is this means when requesting a file, two database entries have to be queried/pulled, however the keys used are predictable so they could potentially be pulled in a single query (assuming redis supports this).

When querying/storing a file remember to use transactions, even though node is single-threaded.

As part of this, we should also update the current gzipping process to only gzip if the file size is > some threshold. The zip + b64 inflates documents of really small size (probably only restrict non-gzipping to plaintext).

http://stackoverflow.com/questions/7844001/what-is-the-lower-threshold-to-not-perform-http-compression

From that it sounds like we should use deflate/inflate instead of gzip/gunzip for text files (I've not actually looked into the difference yet...), and probably set some threshold at around 256 bytes.

By recognizing that the data pasted is a single URL, you could redirect the user to that URL immediately. This would implement URL shortening!

Ability to paste copied images into the browser and upload them just like text.

Example:

/XxYyZz#21

Would jump/highlight to line 21 after loading the doc.

Currently it just generates a bunch of random numbers. We should probably hash some form of the content or timestamp and then convert the hash into some legible key.

Apparently the current version used can cause problems with some combination of text to parse and browsers. (see toptal#69).

The library used is available here: https://highlightjs.org/

The 'Raw' function is Ctrl/Cmd + Shift + R, which is typically a browser's 'refresh and clear cache' function. The 'Duplicate & Edit' is Ctrl/Cmd + D which is typically 'bookmark this page'.

We should come up with new shortcuts that aren't so typical to overwrite existing browser behavior.

Extensions act as a good indicator of file type, so we may either want to allow any extension to be added, or force some extension based on the content-type.

Since we plan to be able to save files as well as text, both should compress pretty well. Built into node.js and should be rather simple to do.

They execute the browser-default commands like new window, etc.

Version 37.0.2062.124 m

They should not be covering content.

Right now the main application links to jquery via googleapi. The jquery library should be added to the repo and hosted by the haste server.

We may eventually want to utilize the user's clipboard (paste copied images, copy URLs into clipboard, etc.).

The ZeroClipboard library uses an invisible flash plugin to manipulate the clipboard.
http://zeroclipboard.org/

Helpful for the case of videos/raw files that don't have a good on-screen representation.

In case of accidental information leakage

I think this is because of how the body tag works. When in edit mode a textarea component is taking up the full dimension of the page. When not in edit mode the body tag is only the size of the text pasted.

Might be fixed with adding:

html {overflow-y:hidden; height: 100%;}
body {overflow-y:auto; height: 100%;}

They could type in something like example.com/mycustomkey. We would then check to see if "mycustomkey" exists. If it does, we show it to them, otherwise we give them a page that says "This key hasn't been created yet" and let them create it.

I got multiple problems trying to use file storage. Switched to redis and it works, but you may want to either fix it or remove the feature.
Nice work on this!

Dependencies have changed

Perhaps add a dropdown box at the top that allows you to select from the available syntax highlighting.

Maybe have a button next to it that allows you to save your choice so the next time the paste is viewed it uses the syntax highlighting you chose.

Dropped a .log file and when redirected to the raw file, was prompted to download file rather than viewing the text. Probably just need better mime-type parsing on file upload.

We should probably also special-case drops of files that have a mime-type of text, instead of redirecting to the raw document, load it to be highlighted/parsed.

Hitting Ctrl+A on viewing a paste will select line numbers. This is likely not desired.

It lags the browser, but why would you do this ;)

When storing things to the db we should put it in a JSON format so we can include additional metadata, such as content-type (text, image), title, upload date (this info might be available direct from redis), etc.

The application.js code is a bit tedious to follow and doesn't feel like it's organized very well, especially since new features are continued to be added. This should be cleaned up for better viewing of different types of pastes.

Not sure about the exact design. Maybe make it its own page. Or have it available from a drop down or something.

Windows captures screenshots to the clipboard, meaning moving an image onto haste requires an extra save/upload step. It would be nice to have this streamlined into a single paste operation.

http://joelb.me/blog/2011/code-snippet-accessing-clipboard-images-with-javascript/ has more information on how to capture the image from the clipboard in Chrome and FF.

Making the pastes completely immutable kinda sucks. What if you paste something and realize there's a minor typo and want to fix it? You have to duplicate the entire thing and submit it as a new paste?

I guess if we were enforcing short lived pastes that probably wouldn't be a big deal. They would expire and get cleaned up in sort order. But if we want longer lived pastes, then editing seems like a necessity.

We should at least be able to configure whether or not editing is allowed.

Use Cmd instead of Ctrl.

This causes unnecessary merge conflicts. The file is generated on the fly by the server anyways, so no need for it to be part of the repo.

Hi

File extension

For example, if you upload Minecraft.exe and then download it, you just get a file with the document key as name. It's not really convenient.

Same for images, would be nice to at least have the format :-)

Better understanding

When sharing a file that isn't text nor image, it would be nice to have a bigger, clearer "download" link.

Thanks.

Not sure exactly what the original intent is, but I don't think we really need to do anything fancy with the history state.

No reason to have a link to quick-tweet a paste..