Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problems with "hubs" feature #136

Open
JKingweb opened this issue Mar 5, 2020 · 1 comment
Open

Problems with "hubs" feature #136

JKingweb opened this issue Mar 5, 2020 · 1 comment

Comments

@JKingweb
Copy link

JKingweb commented Mar 5, 2020

There's a few problems I see with the hubs feature. Below are some points for discussion:

  1. The hub types are ill-defined. The spec suggests ("such as") "WebSub and "rssCloud" without marking these up as sample text, so it's not evident these are to be taken literally as string values i.e. "rssCloud" and "WebSub"
  2. Even if the types are taken literally, capitalization is inconsistent. I realize this is because that's how the schemes refer to themselves, but it gives authors of future hub schemes no guide on how a future type should be named
  3. Using this for rssCloud is impractical because rssCloud is actually three related schemes using SOAP, XML-RPC, or application/x-www-form-urlencoded payloads. Though clients can do HEAD requests to figure out which payload(s) the endpoint will accept, RSS technology isn't exactly known for its robustness; I doubt any rssCloud clients (assuming any still exist?) actually do this.
  4. The structure of a hub object has no formal description, unlike every other object
@andrewshell
Copy link

These are my very non-authoritative opinions as the author of an implementation of a rssCloud server. I think these problems can be solved with a little extra documentation. Feel free to ignore me 😄

  1. I think it's fine that these values are not pre-defined. It should be up to the publisher and the subscriber to know what they want to support.
  2. If there is no specification about capitalization I'd treat the type field as a case insensitive string so "rssCloud" or "rsscloud" or "RssCloud" would all be the same.
  3. It's not really an issue for rssCloud because you're just specifying where to subscribe to notifications so you'd do http://rpc.rsscloud.io:5337/pleaseNotify or xmlrpc://rpc.rsscloud.io:5337/RPC2;rssCloud.pleaseNotify. As far as I know there are no implementations that currently support SOAP. Neither Dave's original rssCloud.root or my node server support it.
  4. It looks like the spec says "Each object has a type and url, both of which are required." If you want the fields described further that's fine but I can't imagine they would be anything other than strings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants