search

exodusproject / spec

(Discussion of) specification of the procotol.
3 stars 0 forks source link

Resource abstraction #4

Open arturovm opened 8 years ago

arturovm commented 8 years ago

Segueing from #3, Resources should be accessible by the users who have permission to do so via any module. I was thinking that maybe we should create a classification mechanism to allow developers to operate with particular types of Resources, and Jonathan asked if we were back to post types.

I think post types are a powerful mechanism and we could maybe copy the concept: An extensible collection of machine-readable and machine-queryable schemas for Resources. Obviously calling them Resource Types instead.

What do you guys think? Are there limitations to this design?

bnb commented 8 years ago

Resources should be accessible by the users who have permission to do so via any module

This I like.

Post Types

Machine-readable is a must, I think. Problems with this is definitions - how and where will they be defined? Will a definition be sent when a post is sent? Defining it externally from content (any kind of information in Exodus) seems like a bad idea to me, because then we get silos and need for external hosting or information instead of Exodus's data being self-reliant.

Zatnosk commented 8 years ago

I'm thinking we could draw inspiration from HTTP, and have a set of headers at the start of each request/response. (We could even define our data-protocol to be structured like HTTP1.1 or HTTP2, i.e. same protocol, but different set of standard headers.) Having headers in front of every resource, would allow us to include metadata such as creation time, author, and especially resource type.

Resource types could be identified by a reverse domain name, and the server could be required to supply a definition/schema for any resource type it serves (through a special request). I'm not so certain about this, though. Would it ensure enough self-reliance?

arturovm commented 8 years ago

Yes! I like that idea. So riffing on that theme, how about using the IANA-defined Internet Media Types instead? The work is already there, and it's really broad. And since it's extensible, we could define types for specific things which are not covered by the standard registry, like posts.

This way, we'd avoid @cphungtinton97's concern about isolated, "proprietary" types, and for the most part, we'd also avoid the need for machine-readable schemas hosted in third-party servers.

–A.

On Jun 19, 2016, at 2:24 PM, Jonas notifications@github.com wrote:

I'm thinking we could draw inspiration from HTTP, and have a set of headers at the start of each request/response. (We could even define our data-protocol to be structured like HTTP1.1 or HTTP2, i.e. same protocol, but different set of standard headers.) Having headers in front of every resource, would allow us to include metadata such as creation time, author, and especially resource type.

Resource types could be identified by a reverse domain name, and the server could be required to supply a definition/schema for any resource type it serves (through a special request). I'm not so certain about this, though. Would it ensure enough self-reliance?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.