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

"extensions": ["…"] extension / registry #44

Open
prof-milki opened this issue Apr 9, 2021 · 2 comments
Open

"extensions": ["…"] extension / registry #44

prof-milki opened this issue Apr 9, 2021 · 2 comments

Comments

@prof-milki
Copy link

prof-milki commented Apr 9, 2021

The extension discussion / consolidation process appears slightly hamstrung by not having a way to communicate explicit support. Even if most are just proposals or singular implementations, there should be a semi-unique identifier for each. Thus you could at least document and survey them via …/micropub?q=config endpoints.

For example:

{
 "media-endpoint": "…",
 "syndicate-to": [],
 "post-types": [],
 "q": [],
 "extensions": ["q", "post-types", "post-types-h", "mp-slug", "http-link-rel-micropub", "bug-token-local-only"]
}

Now some of the names are purely decorative. You can tell that post-types and q are supported by merely looking at the other config properties. It gets more relevant when documenting optional features (post-types-h) within existing structures.

Registry:

This obviously ought to go into the wiki:

extension shorthand description status
post-types Supported vocabulary standard
mp-slug (command) Proposed URL slug stable
post-status (property) Draft publication stable
visibility (property) Ghost publication stable
q List of supported queries consensus
post-types-h Adds h-type in vocabulary list uncommon
http-link-rel-micropub Self-references per header ... (?) proposed
post-types-properties-list Allowed property names as list singular
post-types-properties-dict-input Prop support documented within post-types singular
bug-local-token-only Only supports same-server tokens common(?)
p-me One of the sent properties should be a me: reference fictional
http-content-location Server sends C-L for 201 response (bug) rejected

The names can be arbitrary. Though some common prefixes http-, mp- or bug- (for honesty points) will probably emerge. It doesn't seemt necessary to mark up commands or properties in a special way. Any shorthand would do.

Pros/Cons:

  • Adds a bit complexity. Naming things is hard.
  • Though this is likely to be just a development feature, which sort of obsoletes itself.
  • I wouldn't expect clients to cater too much to singular features/protocol deviations. Apart from looking for mp-* support initially.
  • This is more about accruing a statistic about where support is heading.
@jalcine
Copy link

jalcine commented Jul 16, 2021

I like this idea a lot. I do think that this should live in the Wiki which each extension shorthand as an link-able anchor on the page for searching as well.

@jalcine
Copy link

jalcine commented Aug 4, 2021

Scanning the issues, this looks like it could be an extension (heh) of what #7 was aiming to provide.

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