Custom schema for posts

[jacobobryant]

We already support custom schema for sites. After #39 is closed, do the same for posts. See https://github.com/jacobobryant/platypub/blob/master/themes/default/custom-schema.edn. Grep for custom-schema.edn to see the places that sites' custom schema is already used and mirror that for posts.

[jeffp42ker]

What sort of relationship should we implement between post and site custom schema?

Can custom schema attributes remain optional, i.e. assigning no value means no key?

Should a post value override a site value, since it's more local?

"Navigation links" in particular seems like an attribute that should remain at the site level or somehow merge with post navigation links.

Should separate custom schema maps be maintained and override rules constructed for attributes they have in common?

[jacobobryant]

What sort of relationship should we implement between post and site custom schema?
...
Should a post value override a site value, since it's more local?

I was imagining they'd be separate; no need for post values to override site values. i.e. currently we have a :site/custom-config attribute for sites. We could add a :post/custom-config attribute.

I guess there could be overrides, but it would happen within the theme code. e.g. maybe a site has a custom attribute for author, but posts also have a custom author attribute. As the theme writer you'd probably make it so that posts use their own author value first but default to the site author if one isn't defined. But Platypub itself wouldn't need to be aware of that.

Can custom schema attributes remain optional, i.e. assigning no value means no key?

I think either way is fine. Looks like for :site/custom-config we still add the key put use an empty string for the value (https://github.com/jacobobryant/platypub/blob/master/src/com/platypub/feat/sites.clj#L34). We could have it remove the key altogether instead and make sure that themes don't break when their custom config values are nil. (I don't know off the top of my head if the default theme has problems with that currently--I don't think it does?)

Should separate custom schema maps be maintained and override rules constructed for attributes they have in common?

Originally my thought was that if a theme defines any new custom schema, it is the owner for those keys (and the keys should be namespaced accordingly, e.g. :com.platypub/primary-color etc.) With the current site custom config thing, I'd say if you wanted to make a new theme that reused the existing :com.platypub/* keys, you'd copy platypub's custom config and not make any changes. (of course at this point all custom config values are of type string, so it's not like there's much to override anyway.)

However I'm beginning to think that before we implement any post custom schema stuff, maybe we should figure out exactly how item types (#43) are going to work, and then implement item types + custom post schema all at once. Otherwise I'd be afraid of implementing something that we're just going to change anyway.

[jeffp42ker]

The event attributes I'm considering as additional item fields will include three of instant type.
Generally:
{
:event/uid :uuid
:event/summary :string
:event/description :string
:event/location :string
:event/dtstamp inst?
:event/dtstart inst?
:event/dtend inst?
:event/status [:enum :scheduled :cancelled :postponed]
},

The conflation this introduces to the current model is high.

[jeffp42ker]

The author attributes appear to be a good fit for customizing in posts. At the theme level perhaps they can be moved to a file like post-custom-schema.edn and the main author set in defaults.

[jacobobryant]

Sounds reasonable--I'm planning to put some thinkin' into a possible implementation this friday, so hopefully I'll have a concrete implementation we can poke holes in soon.