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

Query for supported vocabulary #1

Open
aaronpk opened this issue Feb 20, 2018 · 13 comments

Comments

@aaronpk
Copy link
Member

commented Feb 20, 2018

Let's continue the discussion from https://github.com/EdwardHinkle/indigenous-ios/issues/120 over here.

@aaronpk aaronpk added this to Current Issues in Query for Supported Vocabulary Feb 20, 2018

@manton

This comment has been minimized.

Copy link

commented Feb 20, 2018

@aaronpk I'm glad you mentioned Post Type Discovery, because to me that is the part to focus on. It seems too complicated to require spelling out every property, like category or photo. If an endpoint doesn't support accepting a category on a new post, no harm done.

What can we borrow from the Post Type Discovery spec that will help here? At the very least it seems like the Microformats class names should be consistent.

In my example (https://indieweb.org/Micropub-brainstorming#Query_for_supported_vocabulary) I included what I view as the common actions from an app like Indigenous: like-of, repost-of, and bookmark-of, but bookmarks aren't actually mentioned in Post Type Discovery. I wonder if they should be, or are they not different enough from a regular post to list separately?

@aaronpk

This comment has been minimized.

Copy link
Member Author

commented Feb 20, 2018

Interesting, I didn't actually realize bookmark wasn't in Post Type Discovery. It looks like it was mentioned under "Other Types Under Consideration" before it was moved to the W3C repo. Now the W3C note links to the Kinds of Posts section on the IndieWeb wiki for that.

The way we were adding things to the list of types in the algorithm was roughly based on how well-established the markup was in the wild. I am kind of surprised bookmarks didn't make that cut, but oh well.

The one potential confusion here is that post types are not the same as h-* types, e.g. there is no h-reply because you use the in-reply-to property on h-entry to create a reply post. I think that just means we need to be explicit about what to call this. To build on your previous example, this could be a solution:

{
  "post-types": [
    {
      "type": "note",
      "name": "Note"
    },
    {
      "type": "article",
      "name": "Blog Post"
    },
    {
      "type": "photo",
      "name": "Photo"
    },
    {
      "type": "video",
      "name": "Video"
    },
    {
      "type": "reply",
      "name": "Reply"
    },
    {
      "type": "like",
      "name": "Like"
    },
    {
      "type": "repost",
      "name": "Repost"
    },
    {
      "type": "rsvp",
      "name": "RSVP"
    },
    {
      "type": "bookmark",
      "name": "Bookmark"
    }
  ]
}

Clients should assume that if it's not in the list, then the server doesn't support it? Of course there needs to be some sensible behavior for servers that don't return this info at all.

Would it make sense to omit note from this list since that's kind of a baseline? Or keep it in the list because it allows the client to customize the name of the button still?

@EdwardHinkle

This comment has been minimized.

Copy link

commented Feb 20, 2018

I think if no post-types array is returned, the app should default to supporting everything. By adding a post-types array, the server is saying, “I want to improve the UI by only including support for specific post types”. At that point, that means having note in the array is important because if the user only wants to support notes, they need to have an array with just a note.

(Originally published at: https://eddiehinkle.com/2018/02/20/8/reply/)

@manton

This comment has been minimized.

Copy link

commented Feb 20, 2018

That looks good to me. If a server doesn't return post-types, or if it's an empty list, a client should just do whatever default behavior it thinks makes sense. For example, it should send a Like with fallback text.

As a client developer I think I'd view the list as a suggestion. As @EdwardHinkle says, it's a way to improve the UI, but if a certain app always wants to include support for creating notes regardless of what the server says, I think that's fine too. I can imagine a specialized app that is only for creating RSVPs that should still feel free to send them even if the server omits RSVP from the list.

@EdwardHinkle

This comment has been minimized.

Copy link

commented Feb 20, 2018

Yep, exactly. Or a specialized app like Teacup that sends ate and drank posts. Those should still go through regardless.

As you said, @manton, it's more of a suggestion but especially a suggestion for generalized Micropub application, as opposed to specialized.

@aaronpk

This comment has been minimized.

Copy link
Member Author

commented Feb 20, 2018

That makes sense, and also fits nicely with the idea of this as an extension rather than part of the base spec.

@manton

This comment has been minimized.

Copy link

commented Feb 20, 2018

Added a few post types to Micro.blog's q=config if @EdwardHinkle or anyone wants to play with it.

@aaronpk

This comment has been minimized.

Copy link
Member Author

commented Aug 9, 2018

As of a few weeks ago, Quill now supports this extension. If the server returns a list of supported vocabulary, Quill disables the links to any interfaces that use unsupported vocabularies. This should help reduce the confusion when micro.blog users use Quill, since now they won't end up on an interface that fails to make a micro.blog post.

@EdwardHinkle

This comment has been minimized.

Copy link

commented Aug 9, 2018

I added support for this into my website, Quill worked great! Now I have something to test Indigenous with.

I also created a section for this on the extensions page: https://indieweb.org/Micropub-extensions#Query_for_Supported_Vocabulary so it's easier to find and where it brings together all the software that supports this extension.

@swentel

This comment has been minimized.

Copy link

commented Sep 19, 2018

I've added support for this in the drupal indieweb module to return the supported post-types. Indigenous for Android is next.

@dshanske

This comment has been minimized.

Copy link
Member

commented Nov 27, 2018

I would like to add to this proposal querying for properties like visibility in order to know whether the client should display an option for it.

@dshanske

This comment has been minimized.

Copy link
Member

commented Nov 27, 2018

Would that be 'properties' in the config query?

@dshanske

This comment has been minimized.

Copy link
Member

commented Nov 27, 2018

Also, would suggest config return a q array noting what expanded queries it will accept for the same reason.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
5 participants
You can’t perform that action at this time.