mdhughes
https://micro.blog/mdhughes
•
permalink
@manton Which makes replies problematic, since they're only hosted on m.b right now. I need a way to have my replies end up on my site, permanently.
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 💯!
I’d say the single most important lesson to take away here, for a technology project at least, is that interoperability is key.
- Assume that no matter how amazing your new tech is, people are going to adopt it slowly.
- Give your early adopters every chance you can to use your offering together with the existing tools that they will continue to need in order to work with people who haven’t caught up yet.
- And if you’re building a communication tool, make it as simple as possible for others to build compatible tools, because they will expand the network of people your users can communicate with to populations you haven’t thought of and probably don’t understand.
Zegnat
https://github.com/Zegnat
•
Feb 16
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?
Nope, wasn't intending to hold things up, just wanted to put that there for the record.
I agree with the current proposal of having p-* and e-* and h-* stop the implied name.
Zegnat
https://github.com/Zegnat
•
Feb 16
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-name MUST NOT be implied if there are any explicit p-* or 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?
I (and likely others) use xray.p3k.io as a service, so I will have to consider what to do in that case. It doesn't return the Microformats JSON, it converts it to its jf2 format first. I may just return an empty string for name if there is no mf2 name property.
