SubToMe for syndication plugin

[mattsches]

Call me old-fashioned, but I would prefer to make Subtome optional instead of default. As YL said, it's an external service that loads a lot of external stuff, and who knows how long it will live anyway.

Don't get me wrong, I pretty much like what they're doing, and a "centralized" solution might be useful for a lot of readers. People like me who host their own instance of ttrss, however, gain little from it.

True, I disabled the whole syndication plugin in one of my blogs recently because autodetection works everywhere nowadays. Still, my gut feeling says this should be optional.

Mattsches

PS: @onli If you ask the icon author (pfefferle), say "hi" to him from me, I know him personally

[onli]

Hi

PS: @onli If you ask the icon author (pfefferle), say "hi" to him from me, I know him personally ;)

Sure will do that :)

Let me try to cover those concerns.

it's an external service that loads a lot of external stuff

The way it is build, that is not really true. It only loads external stuff when clicking on the rss-icon. And it does not load much, it loads one small js file (https://www.subtome.com/load.js) which loads one iframe (https://www.subtome.com/?subs/#/subscri ... s%29%29%3B) that is not that big as well.

and who knows how long it will live anyway.

This is backed by the long-lived superfeedr (https://superfeedr.com/). And it all is open source, if the central service died, we could - in the worst case - host our own instance. Or just replace it with a button to the raw feed.

People like me who host their own instance of ttrss, however, gain little from it.

That is true, I don't see that as a real negative though… no gain doesn't mean harm.

@Garvin: Looking at the script, it looks to me that one can indeed set a suggested service, cause the script reads

Code: Select all

document.subtomeBtn.dataset.subtomeSuggestedServiceUrl;

I will try this out.

[mattsches]

The way it is build, that is not really true. It only loads external stuff when clicking on the rss-icon. And it does not load much, it loads one small js file (https://www.subtome.com/load.js) which loads one iframe (https://www.subtome.com/?subs/#/subscri ... s%29%29%3B) that is not that big as well.

That's true, but still: I would prefer a default setup that depends as little as possible on external sources.

As far as I'm concerned, we can make it the top optional checkbox and even recommend it in the documentation. I just don't like the "hard" dependency on their service, as stable and useful it may be.

I think we were always trying to keep S9y as slim and - at the same time - as extendable as possible, and we should stick to that

That being said: I would love to see even more Open Web stuff (Webmentions, Pubsubhubbub, …) in S9y, and I know that you already started to implement some of it. Let me know if I can help!

[onli]

More as a reference: My pubsubhubbub-tries are collected in http://board.s9y.org/viewtopic.php?p=10434268#p10434268. The last post is still accurate, it just needs a line-change and some testing, I just forgot it and saw no further interest.

I would in no way think about a button like this as a hard dependency - to the contrary, it is totally exchangeable and extendeable, if we do the core plugins as planned even updateable by spartacus.

But, concern noted. Let's wait a bit for more input. So far, I'm still for trying this out, as a default, with some of YLs changes.

[thh]

I think the subtome icon should be much less intrusive as it seems to be now.

I'm not sure if the conditional inclusion is working; in my test blog, it was displayed eveno though subtome was set to false in the plugin config.

See https://github.com/s9y/Serendipity/comm ... nt-6603101

[onli]

Ok. Seems like this needed cleaning up.

I just pushed a new update to the plugin. It features the default option I imagine, a smaller (and blue) button, and everything is more integfrated into the old structure. If the big img option is deacitvated (by deleting the path to the image), it should look like a normal list entry.

[yellowled]

If the big img option is deacitvated (by deleting the path to the image), it should look like a normal list entry.

While I appreciate to have this option, two things about it are not ideal IMO:

1. If the path to the big image is emptied and the plugin config is saved, the input field for it gets filled with the original path to the image again. That's confusing. If I delete the path to the image, the input field should stay empty.

2. If the big image is removed, the link text for the SubToMe link is “Feed” which is too generic. Why not just make it “SubToMe”? (This might simply need a lang constant which hasn't been added yet. If so, sorry for pointing it out again.)

YL

[onli]

Thanks YL, this helps!

1. is something I didn't think of. Maybe we have to introduce a null-value to set this to empty without setting it to "", as this will toggle the default. I will have to play with that a bit.

2. I didn't like subToMe as text, you convinced me above that this won't be understood. The idea of "Feed" was to change the shown title of the plugin to "Subscribe" and then show simply the link the feed as "Feed" below. I think this should work fine (if in combination with http://board.s9y.org/viewtopic.php?f=4&t=19968. if not, this maybe should be "RSS 2.0 feed" like before).
And indeed, thinking about this, the user shouldn't need to know that this is a subtome-button instead of the raw feed.

[yellowled]

And indeed, thinking about this, the user shouldn't need to know that this is a subtome-button instead of the raw feed.

ideally, the user should (always) know what's “behind” a link text. Personally, I think “Feed” is like those “Click here” link texts. I guess it doesn't have to be “SubToMe” (although I don't see why not). “Subscribe” would be a good alternative, I guess.

YL

[onli]

But isn't that the other way around? "Feed" describes exactly what is behind the link. Subscribe on the other hand is the action the user can do with that element - pretty much the same as "Click here".

But I agree that we should use subscribe in combination with that element. I just would rather use it for the title of the sidebar-plugin. Though, if we have only one element there, this could also be switched ("Feed" for the title of the plugin, "Subscribe" for the link), but I don't think we will arrive there (probably at least the comment feed will stay as an option).

[yellowled]

But isn't that the other way around? "Feed" describes exactly what is behind the link.

You're right, “Subscribe” alone is misleading as well, but “Feed” is too generic. “Feed” could be anything. And besides, the link is “wrapped” in the SubToMe service, so it's technically not a direct link to the feed any longer.

YL

[onli]

"Feed” could be anything.

Oh? I expected that this would be quite clear in the context of a blog, and with a "Subscribe" heading. But ok, let's make it more specific. What do you think of "Entry feed"? "RSS feed"?

And besides, the link is “wrapped” in the SubToMe service, so it's technically not a direct link to the feed any longer.

Technically, it still is a direct link, just with an onclick-header ;) (you are of course right, from users point of view)

[yellowled]

Oh? I expected that this would be quite clear in the context of a blog, and with a "Subscribe" heading.

A user's timeline on Twitter, for example, is sometimes referred to as a feed. If we want to label this according to what's behind the link, it should say “RSS 2.0 (Entries)”. We should also think about renaming those for the “normal” links emitted by that plugin (it says “RSS 2.0 Feed” there).

However, this IMO still isn't what's actually behind this link, and I really don't see why you're so set on avoiding to name SubToMe here. Yes, technically, the link might lead to the RSS 2.0 feed generated by s9y, but it's still wrapped in the SubToMe service. (And by the way, we're way overthinking this.)

YL

[onli]

(And by the way, we're way overthinking this.)

You're right. Subtome could be fine as well. Just wanted something that works even without that.

Will have another proposal in code the next days trying to sort that out, and to fix the other point as well.

[onli]

https://github.com/s9y/Serendipity/comm ... 6de226b704 should be better. Can you have a look? The image is also deactivable by isnerting "none" instead of a path, this just needs to be mentioned in the description.