💾 Archived View for gemi.dev › gemini-mailing-list › 000358.gmi captured on 2024-05-26 at 15:47:26. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Hello everyone, As content starts growing on gemini there may be cause for an rss style feed for the platform. rss is fine but it?s fairly verbose and Allows for things like embedding images and the like which don?t seem to fit well with gemini. My proposal is a simpler format where each line in a file is an item in a feed with fields separated by three colons and the line ending \r\n. The four fields would be date, link, title, text description e.g. yyyy/mm/dd ::: link_to_article ::: title ::: text describing the content \r\n A format like this is easily parsed and displayed in a client. If the gemini protocol defines a mime type for it in the standard it would be easily recognised. I am just throwing the idea out there, what do people think? -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200906/0dfd cd7d/attachment.htm>
Hello, It's the first time I post here, but I've been following the gemini protocol for some time already, because I'm implementing a graphical client, which I will release in some days... Anyway: I don't think we really need a new feed format. Instead, I think we could add a paragraph to the Gemini best practices page, describing some set of rules a Gemini feed should follow. Using the usual Gemini syntax ``` => link1 yyyy-mm-dd title1 Description1... => link2 yyyy-mm-dd title2 Description2... ``` This format is similar to what spacewalk and the capcom aggregator are already using. The description can't contain any link, but I think simple text is enough for a little descriptive paragraph. You can always get the full article by clicking at the link. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200907/13cb e07d/attachment.htm>
Am 06.09.20 um 23:15 schrieb James Henderson: > Hello everyone, > > As content starts growing on gemini there may be cause for an rss > style feed for the platform. > > rss is fine but it?s fairly verbose and Allows for things like > embedding images and the like which don?t seem to fit well with gemini. > > My proposal is a simpler format where each line in a file is an item > in a feed with fields separated by three colons and the line ending \r\n. > The four fields would be date, link, title, text description e.g. > > yyyy/mm/dd ::: link_to_article ::: title ::: text describing the > content \r\n > > A format like this is easily parsed and displayed in a client. If the > gemini protocol defines a mime type for it in the standard it would be > easily recognised. > > I am just throwing the idea out there, what do people think? > Good Morning, I like your idea of simplicity, but what about a simple csv file? A simple comma-seperated-file, working now for years in a a lot of situations and proven to bo in exchanging lots of data. Nothing new has to bb implemented. Libraries for writing csv files are existing for almost if not for every programming out there. Why implementing something new? --Carsten
The reason I went for non csv in this is that people might want to use commas in the description or title. This can be solved by enclosing strings in quotations but then if people want to include quotations in their strings they need to be escaped. The idea behind using ::: is that its rare enough to never really show up and therefore makes a fairly solid delimiter. It also makes manually writing a feed file easier because commas quotes and escapes are not a concern at all. Basically its just more simple and clean, in my mind anyway. On Mon, Sep 7, 2020 at 08:36, cblte <cblte at envs.net> wrote: > Am 06.09.20 um 23:15 schrieb James Henderson: >> Hello everyone, >> >> As content starts growing on gemini there may be cause for an rss >> style feed for the platform. >> >> rss is fine but it?s fairly verbose and Allows for things like >> embedding images and the like which don?t seem to fit well with gemini. >> >> My proposal is a simpler format where each line in a file is an item >> in a feed with fields separated by three colons and the line ending \r\n. >> The four fields would be date, link, title, text description e.g. >> >> yyyy/mm/dd ::: link_to_article ::: title ::: text describing the >> content \r\n >> >> A format like this is easily parsed and displayed in a client. If the >> gemini protocol defines a mime type for it in the standard it would be >> easily recognised. >> >> I am just throwing the idea out there, what do people think? >> > Good Morning, > > I like your idea of simplicity, but what about a simple csv file? > > A simple comma-seperated-file, working now for years in a a lot of > situations and proven to bo in exchanging lots of data. Nothing new has > to bb implemented. Libraries for writing csv files are existing for > almost if not for every programming out there. > > Why implementing something new? > > --Carsten -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200907/3665 4913/attachment.htm>
> The reason I went for non csv in this is that people might want to use commas in the description or > title. > > This can be solved by enclosing strings in quotations but then if people want to include quotations > in their strings they need to be escaped. > > The idea behind using ::: is that its rare enough to never really show up and therefore makes a > fairly solid delimiter. It also makes manually writing a feed file easier because commas quotes and > escapes are not a concern at all. > > Basically its just more simple and clean, in my mind anyway. Just my 2 cents -- I do like the idea of a line based format for this. Maybe something even simpler, building on the idea of previous proposals: => link1 date1 name1 => link2 date2 name2 => link3 date3 name3 Where link is a absolute gemini link, date is an ISO-8601 date, and name is the human readable name of the article. For example: => gemini://foo.bar/glog/1 2020-01-01 Happy New Years! This way you get a valid gemini document that you can display to humans without any changes, or you can parse it fairly easily. So you could mix two feeds together and keep them sorted by date, etc.
(I cannot see any emails from James Henderson, not even in spam. I am not sure why. I'm using ProtonMail.) Ranf Dev writes: > I don't think we really need a new feed format. cblte writes: > Why implementing something new? These are in response to James' original proposal for a new feed format, but in your responses both of you seem to propose another new one, in gemtext and CSV respectively. We already have Atom (or the inferior (so I'm told) RSS), which are established well specced feed formats with parsers for many languages. These formats are designed for machine reading which is their strength, and I think it completely fits within Gemini's design of "radical familiarity" to continue using an existing standard. makeworld
> These are in response to James' original proposal for a new feed format, but in your responses both of you seem to propose another new one, in gemtext and CSV respectively. Indeed in my previous email I made a poor choice of words. I will try to better explain my proposal here. RSS, (and atom, json...) feeds are easily parsable by machines and are already supported by feed readers, but they aren't readable by gemini clients. Also they are > fairly verbose and Allow[s] for things like embedding images Introducing a completely new feed format with its own new syntax would require writing more code to parse it, so I don't agree with that decision. Considering the above, and taking Spacewalk (gemini://rawtext.club:1965/~sloum/spacewalk.gmi) as an example, I'm proposing to use a format that doesn't require writing any new code, so that it can be displayed by already available gemini clients. ``` => link1 date1 title1 Description1... => link2 date2 title2 Description2... ``` (ISO-8601 date). Indeed, it's a new format and has its quirks, but we don't need to change anything to use it. Advanced clients can implement special features by taking advantage of this format: for example they can aggregate multiple feeds, or notify users of new items. Older clients can still fallback and show the feed as nice simple gemtext.
While I like the idea of simple line-delimited formats for feeds, I have to agree that Atom or RSS is simply the way to go here. The Gemini Protocol does not have to use the Gemini Document Format for everything. That's why the protocol supports MIME types, so you can send over JSON, HTML, Atom or RSS. By adding support for the Gemini protocol as a transport option to common tools, Gemini RSS feeds will also become widespread. Reinventing the feed format, along with the transport format, is too much work and would limit usability. -- Leo
James Henderson <henderson.j at protonmail.com> writes: > The idea behind using ::: is that its rare enough to never really show > up and therefore makes a fairly solid delimiter. It also makes > manually writing a feed file easier because commas quotes and escapes > are not a concern at all. Betting that your delim is rare instead of providing escapes isn't a great design principle in my experience. Gemini itself has already been bit by this as we saw earlier with the unescapable ``` TSV or CSV exist and have clients that can help write and read them. Leo <gemini at gkbrk.com> writes: > While I like the idea of simple line-delimited formats for feeds, > I have to agree that Atom or RSS is simply the way to go here. I'm not 100% decided yet, but the position stated by Leo here is what I'm currently leaning towards. As I wrote on irc://irc.tilde.chat/#gemini : > With the understanding that everyine got into Gemini for different > reasons, I got into Gemini after reading this web page. > https://drewdevault.com/2020/03/18/Reckless-limitless-scope.html. > Creating a new format, I see as increasing scope I believe I also for some reason also linked to this old chestnut: https://imgs.xkcd.com/comics/standards.png I could maaaybe get suckered in into supporting a format where every entry is one line. Link iso-8601-date title. No description. But my 2? is for us to stick with a format similar to Gemfeed's output.
> RSS, (and atom, json...) feeds are easily parsable by machines and are > already supported by > feed readers, but they aren't readable by gemini clients. Also they are > > fairly verbose and Allow[s] for things like embedding images > > I just want to point out that given the amount of clients being launched we can't be certain what they can or cannot support. Part of the charm of Gemini is that clients can be proactive in how they provide the user experience. For example, once I noted that many of those aggregators were reading RSS/ATOM feeds I implemented a view for them in my own little GUI client[1] which can be seen in action in this toot[2]. It is a naive display but it allows the user a glimpse into the content and helps them decide if they want to check the full link or not. In my own subjective and biased view, people should use RSS and ATOM more often. Generating a feed and a gemtext with links can be done from the same source and should provide the best of both worlds. [1]: Fafi Browser: https://git.sr.ht/~soapdog/fafi-browser [2]: https://toot.cafe/@soapdog/104784951283677217 -- https://www.andregarzia.com <http://www.andregarzia.com> Want to support me? Buy me a coffee at https://ko-fi.com/andregarzia -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200911/3dfc b30e/attachment.htm>
---
Previous Thread: [ANN] diohsc-0.1.1
Next Thread: A proposed scheme for parsing preformatted alt text