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 Properties #8

Open
dshanske opened this issue Dec 5, 2018 · 10 comments

Comments

@dshanske
Copy link
Member

commented Dec 5, 2018

Separated from #1.

Suggest that the config query return a properties element that notes which experimental properties the endpoint supports so the client can choose to hide unsupported ones

@EdwardHinkle

This comment has been minimized.

Copy link

commented Apr 15, 2019

I think this is definitely needed, not just for experimental properties but also for official ones. Because if Micropub were to become an Evergreen Spec like @aaronpk was thinking through a bit in chat the other day, we would need a way to define what parts people support since you might have older, unsupported endpoints at some point.

@gRegorLove

This comment has been minimized.

Copy link
Member

commented Apr 16, 2019

I'm interested in this in conjunction with #11. I'm adding visibility options to indiebookclub. I think it's important that IBC can tell if the mp server supports "private" or "unlisted" before presenting those options in the UI.

@grantcodes

This comment has been minimized.

Copy link

commented Apr 16, 2019

So I think there are at least 2 ways we would need to show full support for a property:

  1. The basic property is supported and accepts any value, e.g. things like summary and category can accept pretty much anything, but would be nice to know if they are supported
  2. A property that accepts a value from a set list of values, eg the visibility example that supports "private", "unlisted", "public" etc..

But because microformats is pretty fluid it becomes quite complicated when there are some fields that should accept multiple values (mp-syndicate-to), and some that should only accept single values (visibility), and some that could be from a list but allow new values (category).

There is already the prior art of the category query #5 and syndicate-to that are both fairly different already.

In an ideal world there would be a way to define support for any existing property that would also work with any future or custom property too, this could potentially allow micropub clients to be future proof and display a ui for any property.

@EdwardHinkle

This comment has been minimized.

Copy link

commented Apr 16, 2019

Hmmm interesting @grantcodes that’s definitely something to think through

@EdwardHinkle

This comment has been minimized.

Copy link

commented Apr 16, 2019

So initially brainstorming this: you definitely don't want to simplify the syndicate-to object because that is needed. I also don't know that you would want to complicate the category array by making the strings be objects, because then you're just adding complexity turning all the category strings into an object like { uid: categoryName }

So instead, I'm wondering if there are two known value types of properties: objects and strings. A string is a simple base-line and if you need to control anything else about it other than having it be a simple string it becomes a standard object.

I think, as you said, you also need to define some behaviors around a property, so I'm roughly suggesting something like this:

properties: {
  "visibility": {
   "new-values": false,
    "max-values": 1,
    "value-type": "string",
    "default": "private", 
    "options": [
      "public",
      "private",
      "unlisted"
    ]
  },
  "category": {
    "new-values": true,
    "max-values": 0, // 0 = unlimited
    "value-type": "string",
    "default": null, // Or this could be undefined
    "options": [
      // this is an array of strings of previous categories
    ]
  },
  "syndicate-to": {
    "new-values": false,
    "max-values": 0,
    "value-type": "object",
    "default": null,
    "options": [
      {
        "uid": "uid of object",
        "name": "display name of object"
      },
      {
        "uid": "twitter-service",
        "name": "Twitter Username"
      },
     {
        "uid": "github-service",
        "name": "GitHub Username"
      },
    ]
  }
}

There are some immediate potential issues with this direction that need to be taken into consideration, but it's something we can iterate on. For certain things like categories, there can be a LOT of values, thus it may be better to instead of returning an array of values, to provide some indicator that the user has to send a different query for the given options, maybe it's by leaving out the options attribute of the property object.

In which case:

  • no options attribute means you have to query the values in a separate query request
  • an empty options array means no values present
  • an options array with content means you have all existing content

NOTE: This would alter behavior of syndicate-to values, so modern Micropub clients would first have to check if the properties object exists, if so they would use that, and if not, they would need to look in the standard location for syndicate-to values.

EDIT: Based on the conversation by @grantcodes in #11 (comment), I have added a default attribute to the brainstorm above so that a client knows what value it should default to. If a property shouldn't have a default value we can either set default to null OR just not include that attribute, I'm fine either way

@EdwardHinkle

This comment has been minimized.

Copy link

commented Apr 16, 2019

This GitHub issue is going to be refocused on the original two issues:

  1. Hiding properties in a client that aren't supported by a server
  2. Providing pre-defined options and defaults for those supported properties

The other conversations in this issue around supporting new properties, etc are moving to this new issue: #21 which is about helping clients to add support for properties that they don't know about or don't support already

@EdwardHinkle

This comment has been minimized.

Copy link

commented Jun 18, 2019

Has anyone done any server work to implement this at a basic level? @dshanske @gRegorLove @grantcodes

I'm planning on adding some basic support to my server that essentially provides something like:

properties: [
  {
    "name": "visibility"
    "default": "private", 
    "options": [
      "public",
      "private",
      "unlisted",
      "protected"
    ]
  },
  {
    "name": "category"
  },
  {
    "name": "syndicate-to"
  }
}

This is a simple array with objects that MUST contain a name, and the name MUST match the property name that will be included in the Micropub request. Also, you'll notice the server MAY return a default value and/or a list of options. Since category and syndicate-to's options list can be long, on my server I'm opting out of returning those and instead it has to be fetched separately using their query endpoints. I'll report back after I've implemented this both on my server and in Chronicler and let you all know how it turned out for me.

@dshanske

This comment has been minimized.

Copy link
Member Author

commented Jun 18, 2019

I am willing to. I only do the properties, not their values yet.

@EdwardHinkle

This comment has been minimized.

Copy link

commented Jun 18, 2019

You do currently include the available properties? What does your current return look like for this Endpoint?

@dshanske

This comment has been minimized.

Copy link
Member Author

commented Jun 18, 2019

Properties as a single level array. But no one is consuming it

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