Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Hello. I'm the author of this document. It looks like someone posted this to HN without my knowledge after a discussion on IRC yesterday. I was intending to post it myself, but probably not until I had some working software for it - I've been hacking away at a server in my free time but hadn't gotten very far yet. I expect that the process of writing actually functioning software using these ideas will cause the ideas themselves to adapt to the realities of implementing software for them.

All that said, I appreciate the premature feedback. :)



- Why is KyuWeb limited to HTTP/1.1?

- This might be a silly question, but could you explain to me why did you pick a new header, instead of something like `Accept: text/kyu`?


> Why is KyuWeb limited to HTTP/1.1?

Because HTTP/2 requires encryption. … Or so I thought. As I was double-checking my answer, I found that it looks like that is actually no longer the case: https://http2.github.io/faq/#does-http2-require-encryption

Given that, I might re-evaluate stopping at 1.1 in the future. But let's keep it there for now.

Why do we not want to force encryption? Because modern encryption algorithms can be dog slow on old 16-bit systems and effectively impossible on 8-bit ones.

But for clients and servers that support it, SSL/TLS encryption will work the same way as it does for HTTP.

> This might be a silly question, but could you explain to me why did you pick a new header, instead of something like `Accept: text/kyu`?

Because that header is supposed to specify a content type(s). If I were creating a new content type as part of this, I might use it, but the idea is that KyuWeb documents are just Markdown documents, nothing more. Thus `text/markdown` a more correct value for the `Accept` header.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: