5 ms·

After re-reading the document three times, it is still not clear to me - what ports this protocol uses - a simple example of communication - the reason of th

• Aeolun 5y ago
  If you use HTTP, I think the accepted idea is you use port 80. Or 443 if you want to communicate over https. I don’t think anyone needs an example of http communication. I feel like the choice of commonmark is mostly a ‘I really don’t like gemini markup’ reaction. As to why you should use it? Why not?
• Cyberdog 5y ago
  > - the reason of the technical choices (commonmark!?) Three reasons: It's pleasant to write; it's readable even when partially or completely "unrendered;" and it's limited in its capabilities while still meeting the goal of being able to present documents. As for the protocol/communication parts, it's just good ol' HTTP. Refer to an HTTP tutorial or spec if you're not yet familiar with it.
  • __void 5y ago
    well, commomark was just an example of the technical choices not explained, but for the sake of discussion let's focus on this single one: actually commonmark has enough problems (already pointed out by others - see [1] and indirectly the flourishing of sub versions) and in good substance is unambiguous, it seems to me that they are not known by the author given the choice > It's pleasant to write; it's readable even when[...] very debatable, I could as an example rebut that in a lot of keyboards literally lack the characters for some tag, but the point is that once again here we're trying to merge a content with its representation and it's an outdated approach (heck, even on html5 there's css that would serve to separate text from layout) and potentially a can of worms! > As for the protocol/communication parts, it's just good ol' HTTP. Refer to an HTTP tutorial or spec if you're not yet familiar with it. (beyond the tone used and the slight arrogance in assuming that i don't know what an http connection is - but maybe it's just my interpretation due to the language barrier), in practice this "kyuweb" is reduced to be an additional layer on top of what is already there? but shouldn't it be simple? in order to have a kyuweb browser do i have to have first a classic working browser that also sends custom header tags? and on the other side do i have to have custom classic web servers that also respond in this subformat? and if the server sends me mixed content? what should the browser do? but at this point why not use HTTP/1.0 and serve plain markdown, without building additional layers? if these remarks seem stupid, I still repeat that they are all addressed on gemini (even though the answers may not please everyone) [1] https://github.github.com/gfm/#why-is-a-spec-needed- https://github.github.com/gfm/#why-is-a-spec-needed-
    • Cyberdog 5y ago
      > actually commonmark has enough problems (already pointed out by others - see [1] and indirectly the flourishing of sub versions) and in good substance is unambiguous, it seems to me that they are not known by the author given the choice Not entirely sure what you're intending here. The document you link to shows flaws in Gruber's OG Markdown specification as examples of what CommonMark intends to fix and are therefore examples of why I say KyuWeb documents are written in CommonMark instead of Markdown. > very debatable, I could as an example rebut that in a lot of keyboards literally lack the characters for some tag, but the point is that once again here we're trying to merge a content with its representation and it's an outdated approach (heck, even on html5 there's css that would serve to separate text from layout) and potentially a can of worms! CommonMark is a markup specification, just like HTML. Heck, in most of its implementations, it "compiles to" HTML. Styling would be up to the browser. > (beyond the tone used and the slight arrogance in assuming that i don't know what an http connection is - but maybe it's just my interpretation due to the language barrier), My apologies if I came off insulting. It was not my intention. I just merely intended to indicate that KyuWeb networking is basically just HTTP, so any questions about "Does/How does KyuWeb implement X?" with regards to networking can be answered by referring to the HTTP specification. > in practice this "kyuweb" is reduced to be an additional layer on top of what is already there? but shouldn't it be simple? I don't think "layer" is the right word, but you can look at it that way if you wish. In reality it's just a handful of additional HTTP headers, and rules for using existing headers, allowing clients and servers to communicate with each other about KyuWeb-specific things. > in order to have a kyuweb browser do i have to have first a classic working browser that also sends custom header tags? No. A proper KyuWeb browser could use the same HTTP networking code as a "normal" browser but wouldn't have HTML, JS, or CSS parsers/VMs/renderers (at least not necessarily - I suppose a hybrid KyuWeb and normal web browser would be possible). > and on the other side do i have to have custom classic web servers that also respond in this subformat? Yes. Existing web servers can serve as KyuWeb servers. The server I'm currently building is simply a PHP app which would integrate with Nginx/Apache/what-have-you with FastCGI, just like Drupal or WordPress or Magento (but in practice much simpler than any of those). > but at this point why not use HTTP/1.0 and serve plain markdown, without building additional layers? Because normal web browsers don't render Markdown, and, to a lesser extent, because old resource-limited computers can't run normal web browsers.