« Javascript Maze | Home | Review: Sony Ericsson Z710i »
Nopaste App Design, Revisited
By Jacob Cohen | March 30, 2007
What is a Nopaste app?
A Nopaste app, or Pastebin, is a site where you can paste source code or other text and then share a URL so that other people can view it.
Mine can be found here: http://rafb.net/paste/
Origins of the idea
Mine was originally written as a response to seeing other pastebins in use on IRC. There were not many, but a lot of people seemed to use nopaste.snit.ch. It seemed like a cool idea, and I thought it would be useful to write one that did syntax highlighting in multiple languages. I believe mine was the first to do this.
At the time I wrote it, it was certainly the only pastebin that supported multiple languages beyond PHP and Perl. It supported C, C++, Java, Perl, Pascal, PHP, Ruby, and Python. Today, there are many pastebins supporting all of these languages.
Here are the design criteria I used when writing the original. Many of these stemmed from the fact that in its first incarnation, it lived on a small PC sitting under my desk at work.
- Be efficient with CPU usage when doing syntax highlighting
- Don’t fill up my hard drive
- Provide line numbering
- Provide a shareable URL
Be effieicnt with CPU
I decided to do the syntax highlighting of a code snippet at the time it was pasted. The highlighted version was saved to disk, along with the plaintext version. When the URL was shared to other people to view the code, each visitor simply triggered serving a simple HTML file from disk, which requires very little resources from a web server.
Don’t fill up my hard drive
I limited the size of code you could paste, and the frequency (no more than once every ten seconds). Additionally, the stored pastes would be purged from disk after twenty four hours, so only the bookkeeping information would remain.
Provide line numbering
I wanted to provide line numbers that would not inject themselves into your selection when you wanted to cut and paste from a code snippet. At the time, I implemented this by putting the line numbers into a table cell, and the code into another cell. This meant that selecting a section of code would get just the code, without the line numbers.
Provide a shareable URL
This point came easily after I had addressed the first. When I wrote the syntax highlighted file to disk, I stored the generated filename I had used, and the user’s browser was redirected to this URL after the paste had succeeded. All they had to do was copy the URL out of their browser bar to share it with other people.
So what has changed?
Today, these requirements and their solutions remain much the same as they were in 2002. Over the years, I have considered changing things like allowing a re-highlighting of a page at view time, but then I realize it might not be terribly useful to be able to view the same code snippet highlighted under the rules of multiple languages. It is probably simpler to just create a new paste with a new language selected.
Possible new requirements:
- Provide a way to extend the lifetime of a paste beyond 24 hours
- Provide a way to delete something that was accidently pasted
Paste lifetime management
I see URLs being used in newsgroups and message boards, and after 24 hours these links become useless. These people need a way to extend the lifetime of the pasted code or make it permanent. Additionally, people who accidentally paste copyrighted or proprietary code should be given a means of removing it that doesn’t involve sending e-mail.
Topics: General |
May 29th, 2007 at 8:27 pm
One thought on your two “possible new requirements” is to allow users who use it often enough to create an account for the purpose of viewing all their pastes and marking some (say up to 5) as permanent, and being able to check/uncheck them at will. This way they can have a paste last as long as they need, and then uncheck it, at which point it is flagged, and deleted after 24 hours. Each post posted by a logged in user would be linked to that user (obviously) and thus it would be easy for them to delete posts that they have added, but would keep them from deleting other people’s posts.
Of course, there could be an “anonymous” paste, which would operate the same as it does now.
Just some thoughts..
May 30th, 2007 at 10:33 am
Jamie,
Excellent ideas. I’ve been mulling over the idea of adding support for customer accounts. Additionally, it might be useful to allow the paste author to password-protect a paste with some arbitrary password. This would prevent the complexity of full-blown group management, yet still allow people to limit the visibility of stuff they paste.
With accounts, I could do cool things like automatically persisting 5 pastes per user. When that user wants to make a 6th paste, it would flag the oldest paste for deletion in 24 hours. Or, if they wanted, they could mark that paste as a “permanent” paste, and it would be removed from the queue.