atom.xml

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">

 <title>tus.io</title>
 <link href="http://feeds.feedburner.com/tusio" rel="self"/>
 <link href="http://tus.io/"/>
 <updated>2014-01-22T21:26:25+01:00</updated>
 <id>http://tus.io/</id>

 
 
 <entry>
   <author>
     <name>Felix Geisendörfer</name>
     <email>hello@tus.io</email>
   </author>
   <title>Protocol v0.2.1</title>
   <link href="http://tus.io/blog/2013/05/08/protocol-v0.2.1"/>
   <updated>2013-05-08T16:42:00Z</updated>
   <id>http://tus.io//blog/2013/05/08/protocol-v0.2.1</id>
   <content type="html">&lt;p&gt;This is a minor protocol release:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Fix &lt;a href=&quot;https://github.com/tus/tus-resumable-upload-protocol/pull/19&quot;&gt;#19&lt;/a&gt;:
Final-Length header was called Final-Size in one place by accident. (&lt;a href=&quot;https://github.com/vayam&quot;&gt;Naren
Venkataraman&lt;/a&gt;)&lt;/li&gt;
&lt;li&gt;Define that PATCH requests MUST use &lt;code&gt;application/offset+octet-stream&lt;/code&gt; as the
&lt;code&gt;Content-Type&lt;/code&gt;. (&lt;a href=&quot;https://github.com/felixge&quot;&gt;Felix Geisendörfer&lt;/a&gt;)&lt;/li&gt;
&lt;li&gt;Define that &lt;code&gt;Final-Length&lt;/code&gt; values MUST NOT be negative. (&lt;a href=&quot;https://github.com/felixge&quot;&gt;Felix
Geisendörfer&lt;/a&gt;)&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;All patches can be seen &lt;a href=&quot;https://github.com/tus/tus-resumable-upload-protocol/compare/v0.2...v0.2.1&quot;&gt;here&lt;/a&gt;.&lt;/p&gt;
</content>
 </entry>
 
 
 <entry>
   <author>
     <name>Felix Geisendörfer</name>
     <email>hello@tus.io</email>
   </author>
   <title>Protocol v0.2</title>
   <link href="http://tus.io/blog/2013/05/01/protocol-v0.2"/>
   <updated>2013-05-01T00:35:00Z</updated>
   <id>http://tus.io//blog/2013/05/01/protocol-v0.2</id>
   <content type="html">&lt;p&gt;After releasing our first draft a few weeks ago, we received an incredible
amount of feedback and suggestions. Based on this feedback as well as
&lt;a href=&quot;http://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/0155.html&quot;&gt;discussing&lt;/a&gt;
the problems with the &lt;a href=&quot;http://trac.tools.ietf.org/wg/httpbis/trac/wiki&quot;&gt;IETF HTTPbis Working
Group&lt;/a&gt;, we identified a few
key issues with &lt;a href=&quot;https://github.com/tus/tus-resumable-upload-protocol/blob/v0.1/README.md&quot;&gt;v0.1&lt;/a&gt; of the
protocol:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;code&gt;PUT&lt;/code&gt; requests are not appropiate for transfering partial resources&lt;/li&gt;
&lt;li&gt;The &lt;code&gt;Content-Range&lt;/code&gt; and &lt;code&gt;Range&lt;/code&gt; headers are not meant for resuming an
interrupted resource transfer.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;After lots of careful thinking, we came up with a new approach that uses:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;code&gt;PATCH&lt;/code&gt; instead of &lt;code&gt;PUT&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;A new &lt;code&gt;Offset&lt;/code&gt; header used by &lt;code&gt;HEAD&lt;/code&gt; responses and &lt;code&gt;PATCH&lt;/code&gt; requests alike&lt;/li&gt;
&lt;li&gt;A &lt;code&gt;Final-Length&lt;/code&gt; header to provide the final file size to the server&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;We also split the protocol into a core protocol which takes care of
resumability, and nothing else, as well as optional protocol extensions.&lt;/p&gt;

&lt;p&gt;The result of this has just been published as v0.2 can be seen on the &lt;a href=&quot;/protocols/resumable-upload.html&quot;&gt;protocol
page&lt;/a&gt;. Also included is a new &lt;a href=&quot;/protocols/resumable-upload.html#7&quot;&gt;FAQ
section&lt;/a&gt; which will expanded over time.&lt;/p&gt;

&lt;p&gt;We feel that the overall result is a drastic simplification of the problem down
to its essence, and we encourage interested developers to implement prototypes.&lt;/p&gt;

&lt;p&gt;Our next step is upgrading tusd, the jquery client and the ios client to the
new protocol version. Once the protocol has reached a little more maturity, we
are also thinking about providing an executable protocol verification tool for
implementers.&lt;/p&gt;
</content>
 </entry>
 
 
 <entry>
   <author>
     <name>Felix Geisendörfer</name>
     <email>hello@tus.io</email>
   </author>
   <title>A protocol for resumable file uploads</title>
   <link href="http://tus.io/blog/2013/04/15/a-protocol-for-resumable-file-uploads"/>
   <updated>2013-04-15T15:00:00Z</updated>
   <id>http://tus.io//blog/2013/04/15/a-protocol-for-resumable-file-uploads</id>
   <content type="html">&lt;p&gt;&lt;strong&gt;tl;dr:&lt;/strong&gt; We are happy to announce version 0.1 of the &lt;a href=&quot;/protocols/resumable-upload.html&quot;&gt;tus resumable upload
protocol&lt;/a&gt; and are interested in your
feedback!&lt;/p&gt;

&lt;p&gt;With mobile devices becoming the dominant source of user generated media files,
reliable file uploading through unreliable mobile networks has become an
important issue for anybody interested in content acquisition.&lt;/p&gt;

&lt;p&gt;Reliability here means the ability to detect network errors, and resuming an
upload without having to start from the beginning. In many scenarios this can
mean the difference between a file reaching your application, or the user
giving up in frustration.&lt;/p&gt;

&lt;p&gt;Ideally, this should be a trivial feature to add. In reality however, there is
quite a lack of solutions in this space. Sure, there are a few JavaScript
libraries that claim to support resumable uploading, but in reality you will
end up spending a lot of time coming up with your own API for it, or
implementing a poorly specified one specific to a library. This is incredibly
frustrating, especially if you are planning to support this feature on multiple
platforms such as HTML5, iOS and Android.&lt;/p&gt;

&lt;p&gt;Now, if you&amp;#39;re a big company like Google, you may sit down and create such a
protocol for your needs. And in fact, Google has been working on a &lt;a href=&quot;http://code.google.com/p/gears/wiki/ResumableHttpRequestsProposal&quot;&gt;such a
protocol&lt;/a&gt;
since 2010, for the now defunct Google Gears. The latest incarnation of this
are two incompatible protocols for &lt;a href=&quot;https://developers.google.com/drive/manage-uploads&quot;&gt;Google
Drive&lt;/a&gt; and
&lt;a href=&quot;https://developers.google.com/youtube/v3/guides/using_resumable_upload_protocol&quot;&gt;YouTube&lt;/a&gt;.
But unfortunately both of these protocols rely on a non-standard http status
code (&lt;code&gt;308 Resume Incomplete&lt;/code&gt;), and are far from being generic enough for
general adoption.&lt;/p&gt;

&lt;p&gt;This means that smaller companies are currently doomed to invent, implement and
maintain their own incompatible protocols and solutions for something that
should be a trivial component of a modern application.&lt;/p&gt;

&lt;p&gt;We find this unacceptable, so the &lt;a href=&quot;http://www.tus.io/&quot;&gt;tus project&lt;/a&gt; is a
community project that was born in order to level the playing field and make
resumable file uploading easy for anybody to implement.&lt;/p&gt;

&lt;p&gt;Today we are happy to release version 0.1 of &lt;a href=&quot;/protocols/resumable-upload.html&quot;&gt;our
protocol&lt;/a&gt;. Interested developers are
encouraged to experiment with it, and we are very interested in any feedback
you may have.&lt;/p&gt;

&lt;p&gt;Later this week we will also release some initial clients for
&lt;a href=&quot;https://github.com/tus/tus-jquery-client&quot;&gt;jQuery&lt;/a&gt; and
&lt;a href=&quot;https://github.com/tus/tus-ios-client&quot;&gt;iOS&lt;/a&gt;, so make sure to follow this blog
and these repositories for future updates!&lt;/p&gt;
</content>
 </entry>
 
 
 <entry>
   <author>
     <name>Kevin van Zonneveld</name>
     <email>hello@tus.io</email>
   </author>
   <title>Hello world</title>
   <link href="http://tus.io/blog/2013/04/06/hello-world"/>
   <updated>2013-04-06T20:45:00Z</updated>
   <id>http://tus.io//blog/2013/04/06/hello-world</id>
   <content type="html">&lt;p&gt;Hey everybody, we&amp;#39;re starting a new blog here to discuss file uploading, and
the protocol we are working on. So keep an eye on this space!&lt;/p&gt;
</content>
 </entry>
 

</feed>