Unable to find working OWIN hosting example without Gate

[Kevin Thiart]

Hi

I'm looking for a working example where Kayak is used as an OWIN host.
Do I need Owin.Gate for this or is there a simple way to do this
directly?

The code example on the kayakhttp.com site doesn't compile at all:
http://kayakhttp.com/start

Seeing as Kayak supports OWIN natively, I thought it would be roughly
the same as running a WSGI app on a WSGI server, which is usually just
a single method call.

Anyway, does anyone know where I can find a simple example without
using Gate?

Thanks!

--

Kevin Thiart
@kevinthiart

[Benjamin van der Veen]

Short answer: use Gate. http://kayakhttp.com/start is out-dated.

[Kevin Thiart]

Thank you for the reply.

I was hoping for something as simple as all the Python WSGI servers
with regards to getting up and running.

For example, starting gevent's async WSGI server:

from gevent.wsgi import WSGIServer
address = "localhost", 8080
server = WSGIServer(address, application)

Where application is the WSGI method implementation like so:

def application(environ, start_response):
start_response("200 OK", [("Content-Type", "text/html;
charset=utf-8")])
return ["Hello, World!"]


Shouldn't there be a similar OWIN server in the Kayak project with
sane defaults?
If such a server is implemented in the Gate project, doesn't it make
sense to move it to the Kayak project instead, seeing as all it's
doing is setting up an OWIN environment?

I'm entirely new to the .NET OWIN/Gate/Kayak environment so excuse my
ignorance, I'm just trying to get a feel for all the components and
their purposes.

This tweet by Steven Robbins, for example, states that Nancy does not
require Gate to host on Kayak: http://www.twitter.com/Grumpydev/status/160346390227206144
I'm sure he expects the framework consumer to do some coding to get
the Kayak server up and running in this case, but should this be the
norm?

I guess what I'm asking is, what's the long answer?

--

Kevin Thiart
@kevinthiart



On Jan 24, 8:24 pm, Benjamin van der Veen <b...@bvanderveen.com>
wrote:
> Short answer: use Gate.http://kayakhttp.com/startis out-dated.

[Benjamin van der Veen]

Because OWIN doesn't declare any concrete types (it just describes a pattern) you'll have to write some code to 'materialize' your stack into concrete types. Gate will do this job for you.

If you don't want to use Gate, you'll have to do some of what Gate does to glue Nancy to Kayak. Check out Gate.Owin, and Gate.Kayak. Nancy provides an Owin adapter in Nancy.Hosting.Owin I believe. 

Basically you'll be replicating those three packages.

[Benjamin van der Veen]

On Tue, Jan 24, 2012 at 11:05 AM, Kevin Thiart <kevin...@gmail.com> wrote:

Shouldn't there be a similar OWIN server in the Kayak project with
sane defaults?
If such a server is implemented in the Gate project, doesn't it make
sense to move it to the Kayak project instead, seeing as all it's
doing is setting up an OWIN environment?

Maybe, but because OWIN doesn't provide concrete types, and none of the languages in question are dynamic (like Python or Ruby), both Kayak and a hypothetical OWIN-compliant user project will have to agree on some set of concrete types which 'materialize' the OWIN interface. Gate ships Gate.Owin.dll for this purpose. To me it makes some sense for the Gate project to ship Gate.Kayak so it can be kept in sync with Gate.Owin.

[Louis DeJardin]

I agree that makes a lot of sense. It would also be very consistent (naming, discoverability, etc) esp as some host handlers don't exist outside of gate. e.g. Gate.Hosts.HttpListener, Gate.Hosts.AspNet.

(Sorry, can't reply at bottom of thread from phone. :)
--
Louis - sent from mobile

---

From: Benjamin van der Veen
Sent: 1/24/2012 1:52 PM
To: kayak...@googlegroups.com
Subject: Re: [Kayak] Re: Unable to find working OWIN hosting example without Gate

[Kevin Thiart]

On Jan 24, 11:52 pm, Benjamin van der Veen <b...@bvanderveen.com>
wrote:

I can see why you would want to use Gate.Owin for the delegates just
to keep the code readable, but to me it feels like the loss in
flexibility isn't worth it. An alternative is to use using clauses to
assign aliases to the OWIN funcs/actions whenever you need to declare
them.

The idea is that, at application boundaries, only the built-in funcs/
actions are used in method signatures.
This allows non-Gate apps to use the Owin standard and be hosted on
Kayak with minimal effort and with no extra dependencies.
If Gate itself adhered to the Owin spec, there would be no problem to
host Gate itself on Kayak, just as you would host a normal Owin app,
by passing in the app delegate (or Action).

I created a gist in case you want to have a look: https://gist.github.com/1673393

The important file to look at is OwinHttpRequestDelegate.cs, which I
adapted from the Gate project.
In Program.cs you can see that I'm passing Nancy's OWIN method to the
server directly and it is working.
This is based on Draft 5 of the OWIN spec.

The idea is that Gate (and all other Owin apps) should follow a
similar process if they want to be hosted on Kayak.
In this solution Gate would be reduced to a Middleware framework only,
which I feel is a step in the right direction.
Web framework developers can then decide whether they want to support
Gate or not, but they really should support OWIN directly (as Nancy
does).
Gate should allow any OWIN-compliant app to be added as middleware, as
a workaround for frameworks that don't support Gate directly.

This is just my 2c as an outsider getting into the projects right now.

Let me know what you think.

Regards

--

Kevin Thiart
@kevinthiart

[Kevin Thiart]

On Jan 25, 1:25 am, Kevin Thiart <kevinthi...@gmail.com> wrote:
> The idea is that Gate (and all other Owin apps) should follow a
> similar process if they want to be hosted on Kayak.
> In this solution Gate would be reduced to a Middleware framework only,
> which I feel is a step in the right direction.
> Web framework developers can then decide whether they want to support
> Gate or not, but they really should support OWIN directly (as Nancy
> does).

Just to make sure this isn't lost, I feel this is the main point:

In my solution, from Kayak's point of view, Gate is just another OWIN-
compliant application and Gate's role is similar to Connect or Rack.

So, you should be able to mix/match middleware frameworks as they
should export a method with the standard OWIN signature just like all
other OWIN apps.

Then the OwinServer is implemented by Kayak, and is the only (or at
least the recommended) way to host ANY Owin app, whether it be a Gate-
like middleware stack or just a plain web framework like Nancy.

I'm sorry for replying to myself. I hope I didn't break ALL mailing
list etiquette!

[Louis DeJardin]

Yep, I agree with that. In fact - check out the Gate.Owin.IAppBuilder
interface. It's the *only* actual type information in the spec
assembly, the rest are delegates. I think it

https://github.com/owin/gate/blob/master/src/Main/Gate.Owin/IAppBuilder.cs

When you call .Use<TApp> to pipe in a middleware or framework - the
TApp lets you use the signature that piece is implemented in. Exactly
so you can have middleware or frameworks that aren't compiled against
Gate.

When you call Build<TApp> that also lets you say which TApp signature
is returned. If a web server implements the purely delegate
specification that's how you get the right signature to hand to it.

In the end - all this takes is an implementation of IAppBuilder that
understands how to mediate between the different signatures.
Gate.Builder.dll has one, but again that's a component anyone can
implement. None of the web servers, frameworks, middleware, or web app
"startup" takes a hard dependency on Gate.Builder.dll.