Acconut

> It's for building specialized services such as key value stores, L7 proxies, static websites, etc.

First of all, thank you for publishing this project. It's very interesting in my opinion since I never thought about the benefits of an event loop. Would you mind explaining briefly why an event loop is a better suit for these applications? Is it due to performance and efficiency?

> I've done lots of event loops in the past (eg hellepoll in c++) and think that the cost of that is on the programmer - keeping track of things, callbacks, state machines and things and avoiding using the stack for state etc is all hard work and easy to mess up.

I very much agree. In the past, I have had quite some fun developing a few streaming parsers using Node.js, which also uses an event loop. And while these parser worked relatively good and efficient, debugging them was not an easy task. In addition, understanding the code is also a though challenge, especially for people other than the original authors.

When I started using Go more and more, I really enjoyed the different I/O-model using goroutines and blocking function calls. It also has a few drawbacks but the mental model is a lot easier to reason about.

People, I followed on Twitter, kept sharing links mentioning HN or citing from comments. After some time I decided to check it about but it took me some time until I realized what this "thing" was and appreciate the value behind it.

Splitting a resource into multiple parts and embedding in into a single message in order to avoid external storage and the need for locking is an interesting approach, but sadly not an option for me. Nevertheless, I appreciate your response.

At my workplace, we are currently looking for a distributed locking mechanism. Since we are already heavily using Redis in our system, it seems to be convenient to rely on it, too, but we heart a lot of criticism against it.

Does anyone have experience with distributed locks and would be kind enough to share?

Funnily, there is no PHP 6. While work had begun for this version, it was later abandoned due to some major issues regarding Unicode handling, as far as I know. Most of the features already implemented in PHP 6 were shipped in PHP 5.4 and they continued with PHP 7 in order to avoid confusion.

Indeed, resumable uploads are not a thing we invented. Nevertheless, we think it's handy to have a document describing the approach and client and server implementations.

We also considered the use of the Content-Range headers for resuming uploads but dropped this idea in favour of custom headers since the purpose written down in the HTTP specification was not compatible with the way we wanted to use it.

Great to hear, you enjoy it. I am Marius, the current project lead of the tus project and I guess I can provide some answers for you.

The biggest benefit and the main reason of its origin is the ability to resume an interrupted upload at any time resulting in more efficient resource usage and user experience. In addition the fact that it's developed openly and by a community is also noticeable. You do not have to reinvent the wheel since others have already spend time, efforts and thoughts building a working system you can use for free. The tus project already offers a growing list of client and server-side implementations. Last but not least, optional features such as parallel uploading and checksums are available.

On the other hand, you have the overhead of adapting an external system. Whenever you want to build software, you can choose between doing it yourself or using an existing solution, where latter can be tough to achieve depending on your architecture. Furthermore, tus introduces a small overhead in terms of numbers of requests needed for an upload. Usually, you need one to create the upload and another one to transfer the actual data (excluding eventual CORS requests in a browser), in contrast to the traditional model of uploading where a single request is used. Normally, this overhead is negligible, especially when the files are getting bigger.

No, I do not think this should be implemented. The proper way (in addition to server-side validation, of course) is to utilize JavaScript in order to verify the file's size. This solution also allows different maximum sizes for different file types as one example in the discussion shows. Using JavaScript also adds additional flexibility when trying to achieve custom error messages. In general, I think the HTML specification is getting quite bloated these days, but this is not the place to discuss this.

Gandi seems to be exactly what I was referring to, thanks.

I can relate to your problem regarding the memory optimized plan. Are you aware of any cloud provider, similar to Linode or DigitalOcean, which allow to specify the numbers of cores and GBs of memory by yourself? All the services I know only provide fixed machine types.

The Community edition is updated every half a years and seems to receive the new features then but I can't verify it.