How will this differ / relate to the Hypermedia project?

[glennblock]

I almost forgot about this but several months ago I attended API craft, where a new effort was formed: https://github.com/the-hypermedia-project/charter which seems to be attacking the same problem though in a broader sense across all platforms. It has also done quite a bit of work rationalizing the necessary components of hypermedia systems.

Were you guys aware of this? Any thoughts on who this effort differs? Is it that this is .NET and .NET only?

[JakeGinnivan]

I didn't know about this!

If it gives us the concepts and the models for specifying hypermedia in a generic way, then maybe this project becomes an implementation of that charter. We could even move it into their org (if they were interested).

No point reinventing the wheel in the .net space, and if the concepts behind the library are already documented then even better!

[glennblock]

I am part of the org and was supposed to be carrying the .NET mantle for the project (though progress has been slow).

There are python and ruby examples in the repo and a .NET one is needed. As I said, its broader in scope. It introduces a media-type agnostic contracts for expressing a hypermedia message and then contracts for generating to an actual format.

[wis3guy]

I just read through their md files, but wonder if this is actually the same thing we are trying to do. I thought our goal was to build a set of libraries that enable .NET developers to build and consume hypermedia driven api's, whilst retaining the format specific strong points. At the same time, i feel that their goal is to abstract away all differences.

@glennblock That is what you are trying to do in that project, right?

[glennblock]

Geoffrey yes I think you are right. This is about creating a set of abstractions that allow you to use any format, without your code caring. I am still skeptical that this is worth doing, but i am reserving judgment. Basically it introduces a meta model for hypermedia that lets you express all the elements and then does mapping later. As media types vary so much, I am having a hard time believing this can work...BUT....I am willing to be proved wrong.

I brought this up because I saw mention of abstracting away the specific formats in one of the threads here.

On Wed Nov 26 2014 at 12:27:12 AM Geoffrey Braaf notifications@github.com wrote:

I just read through their md files, but wonder if this is actually the same thing we are trying to do. I thought our goal was to build a set of libraries that enable .NET developers to build and consume hypermedia driven api's, whilst retaining the format specific strong points. At the same time, i feel that their goal is to abstract away all differences.

@glennblock https://github.com/glennblock That is what you are trying to do in that project, right?

— Reply to this email directly or view it on GitHub https://github.com/DotNetHypermedia/DotNetHypermedia/issues/11#issuecomment-64529366 .

[wis3guy]

@glennblock I totally share your skepticism ... but would love to see that work. @jakeginnivan, @glennblock I think for us, that is not what we should strive for with this project. Let's stick with conscious developer decisions per format. That is not to say, i do not think these should be made inside my controller per se.

Ciao, Geoffrey

Geoffrey Braaf | +31655793290 Freelance .NET Software Architect & Passionate Developer | http://wis3guy.net Findsi: find-as-i | http://www.findsi.com

On Wed, Nov 26, 2014 at 6:03 PM, Glenn Block notifications@github.com wrote:

Geoffrey yes I think you are right. This is about creating a set of abstractions that allow you to use any format, without your code caring. I am still skeptical that this is worth doing, but i am reserving judgment. Basically it introduces a meta model for hypermedia that lets you express all the elements and then does mapping later. As media types vary so much, I am having a hard time believing this can work...BUT....I am willing to be proved wrong.

I brought this up because I saw mention of abstracting away the specific formats in one of the threads here.

On Wed Nov 26 2014 at 12:27:12 AM Geoffrey Braaf notifications@github.com

wrote:

I just read through their md files, but wonder if this is actually the same thing we are trying to do. I thought our goal was to build a set of libraries that enable .NET developers to build and consume hypermedia driven api's, whilst retaining the format specific strong points. At the same time, i feel that their goal is to abstract away all differences.

@glennblock https://github.com/glennblock That is what you are trying to do in that project, right?

— Reply to this email directly or view it on GitHub < https://github.com/DotNetHypermedia/DotNetHypermedia/issues/11#issuecomment-64529366>

.

— Reply to this email directly or view it on GitHub https://github.com/DotNetHypermedia/DotNetHypermedia/issues/11#issuecomment-64677561 .

[JakeGinnivan]

@wis3guy So plan is to rescope this to one Hal library which can be plugged into multiple frameworks. That seems like a great first step and is very achievable.

If we can take ideas and terminology from the Hypermedia project then we may be in a position to spike supporting multiple formats.

I will bring this up in the Jabbr room and see what everyone thinks tomorrow.

[glennblock]

Let scope it to CJ and HAL. I am happy to help on the CJ side. Actually I think the goal should be to come up with some generic infra for supporting hypermedia on OWIN servers, with upper level support in Nancy and Web API (where necessary). Ideally we'll have a sample that illustrates both.

On Wed Nov 26 2014 at 9:17:08 AM Jake Ginnivan notifications@github.com wrote:

@wis3guy https://github.com/wis3guy So plan is to rescope this to one Hal library which can be plugged into multiple frameworks. That seems like a great first step and is very achievable.

If we can take ideas and terminology from the Hypermedia project then we may be in a position to spike supporting multiple formats.

I will bring this up in the Jabbr room and see what everyone thinks tomorrow.

— Reply to this email directly or view it on GitHub https://github.com/DotNetHypermedia/DotNetHypermedia/issues/11#issuecomment-64679717 .

[wis3guy]

Sounds like a plan!

Ciao, Geoffrey

Geoffrey Braaf | +31655793290 Freelance .NET Software Architect & Passionate Developer | http://wis3guy.net Findsi: find-as-i | http://www.findsi.com

On Thu, Nov 27, 2014 at 1:50 AM, Glenn Block notifications@github.com wrote:

Let scope it to CJ and HAL. I am happy to help on the CJ side. Actually I think the goal should be to come up with some generic infra for supporting hypermedia on OWIN servers, with upper level support in Nancy and Web API (where necessary). Ideally we'll have a sample that illustrates both.

On Wed Nov 26 2014 at 9:17:08 AM Jake Ginnivan notifications@github.com wrote:

@wis3guy https://github.com/wis3guy So plan is to rescope this to one Hal library which can be plugged into multiple frameworks. That seems like a great first step and is very achievable.

If we can take ideas and terminology from the Hypermedia project then we may be in a position to spike supporting multiple formats.

I will bring this up in the Jabbr room and see what everyone thinks tomorrow.

— Reply to this email directly or view it on GitHub < https://github.com/DotNetHypermedia/DotNetHypermedia/issues/11#issuecomment-64679717>

.

— Reply to this email directly or view it on GitHub https://github.com/DotNetHypermedia/DotNetHypermedia/issues/11#issuecomment-64731597 .

[JakeGinnivan]

Ill get readme updated tonight with the scope/initial goals as well as links to hypermedia project and resources which have been linked so far