@EdwardHinkle Sounds great! I can implement it at any time on Micro.blog, although first I wonder if anyone has feedback on the JSON key names.
One thing to note is these are all properties of the
h-entry vocabulary, whereas other kinds of posts support totally different properties. Things like
h-review where they are completely different things. Continuing down this path it would make sense to scope these properties to note that they are part of the
The other question is how many of the supported properties would need to be defined? If not all of them, (e.g.
published) why these ones in particular?
Is it because these correspond with post types? If that's the case, then maybe this should be somehow tied to the Post Type Discovery spec which spells out what properties map to what kinds of posts.
In that case, it may make more sense to have the server advertise which of these post types it supports, and then clients would look at the spec to know which properties to send to create those posts.
This episode marks a full year that I’ve been creating weekly audio summaries of the IndieWeb newsletter! Thank you for listening!
I’d love any feedback that you have. Also, if you’d take a moment to leave a rating and a review wherever you get your podcasts, that’d be 💯!
Clients should have a way to tap in to some sort of streaming API to get updates from the server in realtime.
I've had good luck with the EventSource API on both the client and server side of it. We should define a list of event types that map to the different Microsub actions, so that there's a way for the server to push new events to the client. Things like:
It doesn’t return the Microformats JSON, it converts it to its jf2 format first.
It might be worth opening an issue on jf2 to see if they want to keep an explicit
name property. Their “author” syntax says it “consists of a name” and more, but that’s not marked as a MUST. For a jf2feed on the other hand
name is a SHOULD.
The real question is, do you see any reasons for postponing this change because of your use of a mf2 parser as a service? I think not?
Documenting from yesterday’s chat, because nobody could remember this and I can’t find it elsewhere:
So I think the (as of now) latest proposed spec change would be:
p-nameMUST NOT be implied if there are any explicit
e-*properties, or any nested microformats.
Currently all mf2 items have a name property, because of implied name. If we change this, some code using the parsers could fail if it assumes a name is present.
Here too I will just document an answer given in chat, this time by @aaronpk:
may just mean it has to be released as a major version number [of the parsers]
Assuming something like semver is being used, any major version bump should signify possible API changes to the user. I too don’t think that would be an issue.
There might be an issue if someone is using parsers-as-a-service, e.g. always getting their mf2 parser output from
php.microformats.io. But I don’t think anyone ever advertised their online parsers as a service?