That said, for a collaborative interface it obviously matters less about the weight of the thing and is on my list. The server stuff I may rewrite but the client side is well put together.

gist.github.com is a great tool, though for most people’s needs of course it’s too much. Most of the traffic paste2 gets isn’t even code so there’s room for a middle ground. Most people who use paste2 probably don’t know what git is and probably don’t care so a pure dev solution probably isn’t going to get it done. I want the new pase2 to be as good for Joe Average readers with no interest in creating pastes as it is for developers to create pastes.

The new code does better with trees of pastes (you can see the entire tree all the way to the root paste down to the bottom all at once), and has graphical 2-way diffs to compare any paste with another even if they’re not in the same tree. Combined with the way paste2 releases old pastes bad revisions will get thrown out of the tree and useful items are kept without any intervention.

Thanks for the comments.

While not really related with pastebins I would like to see IRC being rewritten. It stems from a time when people used terminals to communicate and had slow 2400 baud lines.
Today it would be so much nicer to have IRC channels with connected collab-spaces (not as a web-service, but part of the protocol) with firewall-proof file-exchange, private messaging, VoIP and collab editing as well as organizing. A crossover of IRC+XDCC, Google Wave, Google Docs and VoIP. But not as something new, instead as “IRC NextGeneration”.

Oh my! Till then I would like to have a pastebin, that lets us set up temporal workspaces, with a simple (! git may be too resource-hungry) history-control, the possibility to take any text from the history, edit it (collab if desired), making it a new revision, and also (!) be able to share pictures and other binaries like PDFs.

For example, right now I hang around on freenode, trying to put together an xsl-fo. I talk with people. We have so much to write in the chan, that could be much more easily expressed in code in a collab editor. In addition I need to post my experimental PDF output so the others see what is going on.

And always keep an API!

This is the best validation for an email address I’ve seen – similar to your thoughts, and the source doc they refer to is a good read as well

– http://iamcal.com/publish/articles/php/parsing_email/pdf/

dsfs@dsfsdf.com
fsdfdsf@dffsdfs.com

At the end of the day it’s all a little pointless for everybody involved thus – be a bit smarter about it. I’m not actually all that convinced it’s very sophisticated either to be fair, I mean have you seen the close-to-RFC 2822 regexps? And they don’t even tell you if the bit on the end is even slightly legit.

That said it’s all about helping users not make mistakes, if they type @gogglemail.com as opposed to the correct domain, this is why we do input validation at the end of the day – sending a validation email doesn’t fix that, and user wonders why they didn’t get a validation email. Obviously it won’t end that – but it will help.

Nice write up, enjoied reading
The introduction sounds pretty familiar, bored and geekin

But in the end, that’s what puts the fun into linux, isnt it

Greetings