💾 Archived View for gemi.dev › gemini-mailing-list › 000360.gmi captured on 2024-08-25 at 11:15:36. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
I've been seeing people talk about syndication formats how we'd like
something a little less annoying than RSS and Atom.
I'd like to suggest JSON Feed as a possible alternative:
https://jsonfeed.org/
Here's the Simple Example from the 1.1 version of the spec:
{
"version": "https://jsonfeed.org/version/1.1",
"title": "My Example Feed",
"home_page_url": "https://example.org/",
"feed_url": "https://example.org/feed.json",
"items": [
{
"id": "2",
"content_text": "This is a second item.",
"url": "https://example.org/second-item"
},
{
"id": "1",
"content_html": "<p>Hello, world!</p>",
"url": "https://example.org/initial-post"
}
]
}
Obviously, we generally wouldn't use content_html. We could either use
`content_text` or, if we're feeling particularly insular, `_gemini_text`
(see the Extensions section of the spec)
Extensions: https://jsonfeed.org/version/1.1#extensions-a-name-extensions-a
I have a hunch that most people here, if not everyone, would prefer a
strictly line-based format, but I wanted to suggest this, if only to be
sure that we generally _don't_ want something like this.
On Sun, Sep 06, 2020 at 05:53:45PM -0700, mailinglists at ngalt.com wrote: > I've been seeing people talk about syndication formats how we'd like something a little less annoying than RSS and Atom. > > I'd like to suggest JSON Feed as a possible alternative: > > https://jsonfeed.org/ JSON Feed has a healthy amount of acceptance in the syndication space? enough acceptance to satisfy me, that is. And besides RSS, Atom, and JSON Feed, I don't know of any other common syndication formats at all! So I'm assuming there are no well-accepted syndication formats that are line-oriented. Given that, I don't think we need to invent a new syndication format. JSON feed is simple enough: For a publisher, JSON feed should be easier to write than RSS or Atom, but not by a wide margin. If you're just filling out a text template, it may not make much of a difference to you. I maintain a tool that produces Atom feeds for Gemini blogs, and I would be happy to produce a JSON Feed as well. For a consumer, the difference is probably bigger. I expect JSON Feed to be substantially easier to parse than RSS or Atom. Basic JSON parsing utilities are pervasive and usually just produce an object. The last time I did XML parsing, it was much more complex and involved responding to callbacks during an XML tree walk job. So, I would like the consumers of feeds (CAPCOM and Spacewalk to name two) to give opinions about what feed format should be our de facto standard. I imagine it makes the most difference to them. But I'm inclined to think JSON Feed would be best. After all it might make me more likely to create a feed-consuming tool than if the standard was XML. > Obviously, we generally wouldn't use content_html. We could either use `content_text` or, if we're feeling particularly insular, `_gemini_text` (see the Extensions section of the spec) Using content_text sounds fine to me, but I don't know the spec well enough to make a call.
easeout at tilde.team writes: > So, I would like the consumers of feeds (CAPCOM and Spacewalk to name > two) to give opinions about what feed format should be our de facto > standard. I imagine it makes the most difference to them. But I'm > inclined to think JSON Feed would be best. After all it might make me > more likely to create a feed-consuming tool than if the standard was > XML. I've been grabbing feeds, running a script to rewrite Gemini URLs to a URL that points to a local Gemini proxy, and then use that to get feeds in my feed reader. I like using RSS because it's one less wheel to reinvent. I might be in the minority of hand-rolled users though. > - meff
I also like JSON Feed especially how easy it is to parse, but also it has official easy to read docs, something that Atom and especially RSS seem to lack. Re: other feed formats, there's also indieweb's h-feed, but that is not applicable here. On Mon, Sep 7, 2020, 4:32 AM Meff <meff at meff.me> wrote: > easeout at tilde.team writes: > > > So, I would like the consumers of feeds (CAPCOM and Spacewalk to name > > two) to give opinions about what feed format should be our de facto > > standard. I imagine it makes the most difference to them. But I'm > > inclined to think JSON Feed would be best. After all it might make me > > more likely to create a feed-consuming tool than if the standard was > > XML. > > I've been grabbing feeds, running a script to rewrite Gemini URLs to a > URL that points to a local Gemini proxy, and then use that to get feeds > in my feed reader. I like using RSS because it's one less wheel to > reinvent. I might be in the minority of hand-rolled users though. > > > > - meff > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200907/afee 8935/attachment.htm>
> I'd like to suggest JSON Feed as a possible alternative: It's an interesting format. Definitely easier to write, althogh I'm not that partial to it since I don't plain on hand-writing my feeds anyway. I do plan on supporting this in my client Amfora however, along with subscribing to Atom and RSS feeds. If anyone else is doing work in Go they will find the gofeed library helpful, it just added support for JSON feeds in v1.1.0. https://github.com/makeworld-the-better-one/amfora https://github.com/mmcdole/gofeed makeworld
On Mon, 07 Sep 2020 16:42:07 +0000 colecmac at protonmail.com wrote: > > I'd like to suggest JSON Feed as a possible alternative: > > It's an interesting format. Definitely easier to write, > althogh I'm not that partial to it since I don't plain on > hand-writing my feeds anyway. > > I do plan on supporting this in my client Amfora however, > along with subscribing to Atom and RSS feeds. If anyone else > is doing work in Go they will find the gofeed library helpful, > it just added support for JSON feeds in v1.1.0. > > https://github.com/makeworld-the-better-one/amfora > https://github.com/mmcdole/gofeed > > makeworld I'd really prefer a RSS feed over JSON. My 2 cents.
>I'd really prefer a RSS feed over JSON. My 2 cents. I'm curious why, is it just the existing ecosystem? On Mon, Sep 7, 2020, 2:47 PM Tom <tgrom.automail at nuegia.net> wrote: > On Mon, 07 Sep 2020 16:42:07 +0000 > colecmac at protonmail.com wrote: > > > > I'd like to suggest JSON Feed as a possible alternative: > > > > It's an interesting format. Definitely easier to write, > > althogh I'm not that partial to it since I don't plain on > > hand-writing my feeds anyway. > > > > I do plan on supporting this in my client Amfora however, > > along with subscribing to Atom and RSS feeds. If anyone else > > is doing work in Go they will find the gofeed library helpful, > > it just added support for JSON feeds in v1.1.0. > > > > https://github.com/makeworld-the-better-one/amfora > > https://github.com/mmcdole/gofeed > > > > makeworld > > I'd really prefer a RSS feed over JSON. My 2 cents. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200907/552b df55/attachment.htm>
On Mon, 7 Sep 2020 17:29:51 -0400
"A. E. Spencer-Reed" <easrng at gmail.com> wrote:
> >I'd really prefer a RSS feed over JSON. My 2 cents.
> I'm curious why, is it just the existing ecosystem?
>
Well part of it. But mostly I think a lot of the JSON is better than
XML is more hype than merit. And It's not exactly hard to find a good
XML library on any platform I've used. And libexpact is very efficient.
I also like the TSV style approach but think it can potentially
limiting. Also could probably lead to less than desirable layouts in
the future as the only real way to expand that is adding another
column, leaving the old ones in and having positional parsers.
--
_________________________________________
/ There's no such thing as pure pleasure; \
\ some anxiety always goes with it. /
-----------------------------------------
\
\
/\ /\
//\\_//\\ ____
\_ _/ / /
/ * * \ /^^^]
\_\O/_/ [ ]
/ \_ [ /
\ \_ / /
[ [ / \/ _/
_[ [ \ /_/
It is true that JSON usually resolves to an object, but that makes it a
bit more of a chore to deal with when using non-object-oriented
languages. I'm not sure why you had a difficult time writing XML
parsers, but it shouldn't be too different from something along the
lines of var = $root->array[n]->post;. I don't feel too strongly either
way, but I do feel that JSON being so much better than XML is largely
overhyped and while there are extreme edge-cases where some more
specialized interchange format could be more efficient than XML often
times there is just not that huge of a difference to warrant going in a
completely new direction and leaving behind decades of development into
XML based tools. To me the XML vs JSON argument is a lot like
bikeshedding, and I'd go with XML because it's what we already have and
doesn't have problems with non-javascript langs.
But if we really want to drag the XML vs JSON bikeshed all the way out,
might as well use an existing bikeshed blog than start up a new one.
This is linked to from XMPP.org myths & legends
https://www.balisage.net/Proceedings/vol10/html/Lee01/BalisageVol10-Lee01.html
It explores the XML vs JSON debate in the most painstaking through
detail.
Abstract
We all know that XML is "fat" and JSON is the "thinner", "faster",
"smaller", "better" markup. We know this to be true because we've been
told it over and over. It's "obvious" and "inherently true" because XML
has redundant end tags, namespaces, entities and other extra "pounds of
fat" that JSON doesn't have. But where is the science supporting this?
What are the facts and what is myth? When people make design and
architecture decisions it should be supported by facts not speculation.
In this paper I show the results of an ongoing series of real world
tests of Markup performance in browsers across a wide variety of
devices, browsers and operating systems and attempt to quantify markup
performance with experimental results and maybe trim the fat myth one
calorie at a time.
--
_________________________________________
/ There's no such thing as pure pleasure; \
\ some anxiety always goes with it. /
-----------------------------------------
\
\
/\ /\
//\\_//\\ ____
\_ _/ / /
/ * * \ /^^^]
\_\O/_/ [ ]
/ \_ [ /
\ \_ / /
[ [ / \/ _/
_[ [ \ /_/
Nah, I don't think JSON is always better. I like XML, I just personally find JSON easier to work with. It's no longer tied to the JS ecosystem, python, PHP, go and other languages all have support for it in their respective stdlibs. On Tue, Sep 8, 2020 at 4:30 PM Tom <tgrom.automail at nuegia.net> wrote: > It is true that JSON usually resolves to an object, but that makes it a > bit more of a chore to deal with when using non-object-oriented > languages. I'm not sure why you had a difficult time writing XML > parsers, but it shouldn't be too different from something along the > lines of var = $root->array[n]->post;. I don't feel too strongly either > way, but I do feel that JSON being so much better than XML is largely > overhyped and while there are extreme edge-cases where some more > specialized interchange format could be more efficient than XML often > times there is just not that huge of a difference to warrant going in a > completely new direction and leaving behind decades of development into > XML based tools. To me the XML vs JSON argument is a lot like > bikeshedding, and I'd go with XML because it's what we already have and > doesn't have problems with non-javascript langs. > > But if we really want to drag the XML vs JSON bikeshed all the way out, > might as well use an existing bikeshed blog than start up a new one. > > This is linked to from XMPP.org myths & legends > > https://www.balisage.net/Proceedings/vol10/html/Lee01/BalisageVol10-Lee01.html > It explores the XML vs JSON debate in the most painstaking through > detail. > > > Abstract > > We all know that XML is "fat" and JSON is the "thinner", "faster", > "smaller", "better" markup. We know this to be true because we've been > told it over and over. It's "obvious" and "inherently true" because XML > has redundant end tags, namespaces, entities and other extra "pounds of > fat" that JSON doesn't have. But where is the science supporting this? > What are the facts and what is myth? When people make design and > architecture decisions it should be supported by facts not speculation. > In this paper I show the results of an ongoing series of real world > tests of Markup performance in browsers across a wide variety of > devices, browsers and operating systems and attempt to quantify markup > performance with experimental results and maybe trim the fat myth one > calorie at a time. > > -- > _________________________________________ > / There's no such thing as pure pleasure; \ > \ some anxiety always goes with it. / > ----------------------------------------- > \ > \ > /\ /\ > //\\_//\\ ____ > \_ _/ / / > / * * \ /^^^] > \_\O/_/ [ ] > / \_ [ / > \ \_ / / > [ [ / \/ _/ > _[ [ \ /_/ > -- ? <https://www.google.com/teapot> -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200909/eae2 a802/attachment.htm>
On Wed, 9 Sep 2020 08:20:25 -0400
"A. E. Spencer-Reed" <easrng at gmail.com> wrote:
> Nah, I don't think JSON is always better. I like XML, I just
> personally find JSON easier to work with. It's no longer tied to the
> JS ecosystem, python, PHP, go and other languages all have support
> for it in their respective stdlibs.
Sure, I know that. And yes it's pretty easy to find a JSON library for
many programming langs as well. I'm just saying that JSON doesn't as
cleanly map to language variable types for non object-oriented languages
than XML does.
--
________________________________________
/ There are three reasons for becoming a \
| writer: the first is that you need the |
| money; the second that you have |
| something to say that you think the |
| world should know; the third is that |
| you can't think what to do with the |
| long winter evenings. |
| |
\ -- Quentin Crisp /
----------------------------------------
\
\
/\ /\
//\\_//\\ ____
\_ _/ / /
/ * * \ /^^^]
\_\O/_/ [ ]
/ \_ [ /
\ \_ / /
[ [ / \/ _/
_[ [ \ /_/
It was thus said that the Great Tom once stated: > > Sure, I know that. And yes it's pretty easy to find a JSON library for > many programming langs as well. I'm just saying that JSON doesn't as > cleanly map to language variable types for non object-oriented languages > than XML does. I'm not sure what you mean by that---I can see writing a JSON library for a dynamic langauge easier than a non-dynamic one (say, Lua vs. C) but I don't see what OOP has to do with it. -spc
Greetings All!
My www site has for sometime been displaying a homespun gopher proxy
(IE: my website displays my gopherhole). Since I recently installed a
gemini server on my home network, I wanted to expand my proxy to gemini
too. This is complete: https://leveck.us/gemini/1436.ninja/
I am having issues, however. With the gopher proxy, I hand binary files
over to curl via php after sending the appropriate header. Curl doesn't
currently support gemini, and I have been chasing my tail on getting
images (and binary files such as my RPoD Palm OS Software Horde) to work
with my proxy.
Anyone got ideas?
Here is the networky portion of the proxy source:
28 //Gemini Protocol Code
29 //Nathaniel Leveck September 2020
30 $host = $host;
31 $port = 1965;
32 $cert = '/var/www/cert/cert.pem';
33 $context =
stream_context_create();
34
stream_context_set_option($context, 'ssl', 'local_cert', $cert);
35 stream_context_set_option($context, 'ssl', 'verify_peer', false);
36 stream_context_set_option($context, 'ssl', 'verify_peer_name',
false);
37 stream_context_set_option($context, 'ssl', 'allow_self_signed',
true);
38 $socket = stream_socket_client('ssl://'.$host.':'.$port, $error,
$errorString, 2,
39 STREAM_CLIENT_CONNECT, $context);
40 fwrite($socket, "gemini://" . $url . "\r\n");
41 fread($socket,8192); //disregard the
status + meta
42 $content = fread($socket,8192000); //read a suitably large number
of bytes
fread, I assume, is my issue. socketread showed me no love...
--
jynx
gopher://1436.ninja
gemini://1436.ninja
https://leveck.us
On 9/9/20 5:01 PM, Mr. Leveck wrote:
> Greetings All!
>
> My www site has for sometime been displaying a homespun gopher proxy
> (IE: my website displays my gopherhole). Since I recently installed a
> gemini server on my home network, I wanted to expand my proxy to gemini
> too. This is complete: https://leveck.us/gemini/1436.ninja/
>
> I am having issues, however. With the gopher proxy, I hand binary files
> over to curl via php after sending the appropriate header. Curl doesn't
> currently support gemini, and I have been chasing my tail on getting
> images (and binary files such as my RPoD Palm OS Software Horde) to work
> with my proxy.
>
> Anyone got ideas?
>
> Here is the networky portion of the proxy source:
> 28? //Gemini Protocol Code
> 29? //Nathaniel Leveck September 2020
> 30? $host = $host;
> 31? $port = 1965;
> 32? $cert = '/var/www/cert/cert.pem';
> 33? $context = stream_context_create();
> 34 stream_context_set_option($context, 'ssl', 'local_cert', $cert);
> 35? stream_context_set_option($context, 'ssl', 'verify_peer', false);
> 36? stream_context_set_option($context, 'ssl', 'verify_peer_name', false);
> 37? stream_context_set_option($context, 'ssl', 'allow_self_signed', true);
> 38? $socket = stream_socket_client('ssl://'.$host.':'.$port, $error, $errorString, 2,
> 39? STREAM_CLIENT_CONNECT, $context);
> 40? fwrite($socket, "gemini://" . $url . "\r\n");
> 41? fread($socket,8192); //disregard the status + meta
> 42? $content = fread($socket,8192000); //read a suitably large number of bytes
>
> fread, I assume, is my issue. socketread showed me no love...
>
The code was ill formatted. How about a retry?
--
jynx
On Sun, Sep 06, 2020 at 05:53:45PM -0700, mailinglists at ngalt.com said unto me: > I've been seeing people talk about syndication formats how we'd > like something a little less annoying than RSS and Atom. > > I'd like to suggest JSON Feed as a possible alternative: Personally I'm happy with Atom and RSS as the defacto standards. As background, I use tt-rss as a feed reader and it's pretty trivial to simply subscribe to Atom/RSS feeds using a proxy (eg: https://proxy.vulpes.one/gemini/going-flying.com/~mernisse/atom.xml gets my capsule's glog feed) or whipping up your own feed proxy. I feel that existing syndication formats are sufficiently mature, well supported and flexible. Since the user-agent side is the greenfield I'm more excited to see what sort of text based feed readers will appear. --Matt -- Matthew Ernisse matt at going-flying.com http://www.going-flying.com/
What I don't like about JSON Feed in this context is that content is mandatory. It can't be just a list of links a la gemfeed.
On Sep 10, 2020, at 11:58 AM, Sandra Snan <sandra.snan at idiomdrottning.org> wrote: > > What I don't like about JSON Feed in this context is that content is > mandatory. It can't be just a list of links a la gemfeed. True, but: - titles are optional (this is a concession to microbloggers) - The spec doesn?t explicitly disallow ?content_text?: ?? (pardon the auto-curled quotes) in feeds
Nathan Galt <mailinglists at ngalt.com> writes: > - The spec doesn?t explicitly disallow ?content_text?: ?? (pardon the > auto-curled quotes) in feeds That is unfortunately completely wack. I wanna live my life right? "A. E. Spencer-Reed" <easrng at gmail.com> writes: > Re: other feed formats, there's also indieweb's h-feed, but that is > not applicable here. Thank you for bringing up h-feed as kind of a cautionary tale of when an insular community creates yet another feed format. I had forgotten about h-feed :/
---
Previous Thread: A proposed scheme for parsing preformatted alt text