You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
The text was updated successfully, but these errors were encountered:
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.
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:
Now some of the names are purely decorative. You can tell that
post-types
andq
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:
post-types
mp-slug
post-status
visibility
q
post-types-h
http-link-rel-micropub
post-types-properties-list
post-types-properties-dict-input
bug-local-token-only
p-me
http-content-location
The names can be arbitrary. Though some common prefixes
http-
,mp-
orbug-
(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:
mp-*
support initially.The text was updated successfully, but these errors were encountered: