Collaboration Planning

[Ryan Riley]

We have to start somewhere, so I'll propose a starting point for us to start working together. As I mentioned before, I don't hold many of these points tightly, so please feel free to push back or offer different options.

1. Embrace OWIN
   I'm a management committee member, so I'm biased. The signatures are functional and very simple. Dyfrig and Taliesin already support it while still providing support for System.Net.Http types. This would also keep us plugged into an existing ecosystem of components while we build out our own.
2. Naming
   I'm not married to the name Frank. It's been out there awhile and in a book, but it's also intended to be a lightweight project. As evidenced by the history of Frank, I'm completely on board with the direction of HyperF; I just never completed that journey. I'm happy to EOL it and work on HyperF or start migrating HyperF into Frank. Just to throw something out there, I'll propose using Frank as the name.
3. Number of libraries
   As noted above, I have three projects: Dyfrig, Taliesin, and Frank. I don't imagine anyone using these independently, so they could be merged together. I created them separately b/c I like composition of smaller parts. I'd prefer to keep them separate, but I'm open to merging them all together. If I had to pick one of the names, I'd actually prefer Taliesin, the Welsh bard.
4. Type provider
   I have no preference for format, though I do care a lot about providing both client and server boilerplate, as well as generating this from a spec/documentation format that can be used by non-devs. Taliesin is my attempt at stubbing out the underlying pieces of the type provider, and I'm currently investigating how to transform this into a client as well as a server model.

Please comment on any or all these thoughts, and let's get cracking. I'm really excited to be working with you!

Ryan

[Ryan Riley]

I should also note that while creating our own types could be useful, I really like the System.Net.Http types. Hopac looks interesting and appears to have a good model for adapting Tasks.

[James D'Angelo]

I am totally on board with OWIN. I think it is silly to be married to IIS-only technology especially when there are plenty of opportunities for cross-platform use. While not focusing on OWIN might speed things up in the short term, I think it will be a hinderance later on. As for naming, I think Frank is fine but I'm not married to any of the names in use since I'm a newcomer to the party. Coming from the Fix/Simple.Web side of the world, I'm personally fine with smaller-grained pieces that can be composed, but I wonder if those shouldn't be in the same solution and then break them out into different NuGet packages so they can be combined at that level. I assume the reason most of us want to do this work is to lower the barrier to entry for others and I think lowering complexity by keeping the pieces together and offering an opinionated solution would help with meeting that goal. As for the type provider, I am pretty new to them, myself, but really excited to dig into them. I agree that it would be interesting to have a server- and client-side type provider that could help cut out a lot of the boilerplate. I do wonder what a client-side type provider might look like, though, and am excited to see what others are thinking around this. I can't wait to get going! 

[Dave Thomas]

Oooh I'll have to take a peek at that stuff, sounds interesting the progress ® gets being made. 

--
You received this message because you are subscribed to the Google Groups "F# Web Stack" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-stack-fs...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Leo Gorodinski]

1. I think sticking with System.Net.Http at least initially is good. I'm not very familiar with OWIN so I can't comment on that, but it looks like it provides some great back ends. What are some of the downsides of using it?

2, 3. We might as well stick with Frank since is far more complete. One question I have is about the scope. Initially, HyperF was similar to scope to Frank, but the became closer to perhaps something like https://github.com/twitter/finagle together with https://github.com/scalaz/scalaz-stream (which aren't HTTP specific). Do you see this also being incorporated into Frank perhaps as separate projects?

4. We have a type provider that Dmitry created here at Jet which we will open-source once it is more complete. I'll ask him to join in on the discussion to see what he thinks.

[Dmitry Sevastianov]

I am new in the world of web development, so my contribution on 1,2 and 3 is rather limited for now.

1. I had only brief encounter with OWIN from Web API angle (http://www.asp.net/web-api/overview/hosting-aspnet-web-api/use-owin-to-self-host-web-api) but I tend to agree with James. At least for some of the use cases, like faceless APIs it seems to be a viable solution.

2,3. Frank might not be very SEO-friendly :) but frankly, I don't have strong opinion on that. Taliesin sounds great though.

4. So far we have very simple generative type provider for JSON schema. As it's based on Json.Net, it supports only parts of draft 3. I guess we will see how work on Json Schema will progress, so far there are talks of draft 5, no final version in sight. Newton King apparently decided to refrain from adding additional support in Json.Net until it becomes clear if this one is going to stick.

Also, We are looking at RAML as a REST API descriptor format, so far it seems to be the most user-friendly of all. 

[Ryan Riley]

On Friday, June 13, 2014 6:03:53 AM UTC-7, eulerfx wrote:

1. I think sticking with System.Net.Http at least initially is good. I'm not very familiar with OWIN so I can't comment on that, but it looks like it provides some great back ends. What are some of the downsides of using it?

Look at the SystemNetHttpAdapter in Dyfrig. The biggest challenges with OWIN is that it is essentially dynamic and mutable. I would really like to find a way around this to use persistent and/or immutable data structures once you reach the Dyfrig boundaries. Mutability is also a problem for System.Net.Http types. Also, neither will work well with pattern matching without using active patterns.

 

2, 3. We might as well stick with Frank since is far more complete. One question I have is about the scope. Initially, HyperF was similar to scope to Frank, but the became closer to perhaps something like https://github.com/twitter/finagle together with https://github.com/scalaz/scalaz-stream (which aren't HTTP specific). Do you see this also being incorporated into Frank perhaps as separate projects?

I can go either way with respect to integrating into Frank or creating separate libraries. I prefer the latter as, especially in the case of HyperF, many of those features could make good libraries usable in other contexts. Is it possible to refactor the HTTP-specific pieces out of HyperF into Frank while leaving the rest as HyperF?

[Ryan Riley]

On Friday, June 13, 2014 6:03:53 AM UTC-7, eulerfx wrote:

2, 3. We might as well stick with Frank since is far more complete. One question I have is about the scope. Initially, HyperF was similar to scope to Frank, but the became closer to perhaps something like https://github.com/twitter/finagle together with https://github.com/scalaz/scalaz-stream (which aren't HTTP specific). Do you see this also being incorporated into Frank perhaps as separate projects?

In addition, are Dyfrig or Taliesin better targets for integration than Frank? Frank really could become a combinator library. It has a mechanism to tie into System.Web.Routing, but I much prefer now to use Taliesin for this purpose. Dyfrig should eventually solve a lot of the type problems with OWIN and System.Net.Http types, so that seems the most likely/best choice. Of course, Dyfrig and Taliesin could potentially just merge.

[Leo Gorodinski]

Yes that would work. The HTTP specific stuff in HyperF is a couple of modules. In this case, Frank would have a dependency on HyperF. IIRC, the HttpApplication in Frank is Service<HttpRequestMessage, HttpResponseMessage> in HyperF.

--

[Leo Gorodinski]

Also, concerns such as conneg, formatting, auth etc would go through HyperF Filter https://github.com/eulerfx/HyperF/blob/master/HyperF/Service.fs#L5

[Ryan Riley]

Absolutely. I really like those abstractions. I never arrived at them before but tried several other things that didn’t work very well. The abstractions you have clearly specify the intent. I’m very excited to see this move forward.

[Ryan Riley]

Thinking further on this topic, I'm beginning to think I'll focus Frank as a combinator library or move the combinators into HyperF. I'm finding Dyfrig and Taliesin more fruitful areas of further development. Also, the name Frank derives from Sinatra, and Frank no longer resembles Sinatra in any way. Finally, while it might make sense to split up HyperF a bit to make some components usable in other areas, I don't think that is necessary.

Let's try a different tactic: make sure that our libraries work well together. This should be reasonably simple since all support the System.Net.Http types. Thoughts on this approach?

[Ryan Riley]

On Sunday, July 13, 2014 11:01:18 PM UTC-5, Ryan Riley wrote:

Thinking further on this topic, I'm beginning to think I'll focus Frank as a combinator library or move the combinators into HyperF. I'm finding Dyfrig and Taliesin more fruitful areas of further development. Also, the name Frank derives from Sinatra, and Frank no longer resembles Sinatra in any way. Finally, while it might make sense to split up HyperF a bit to make some components usable in other areas, I don't think that is necessary.

Let's try a different tactic: make sure that our libraries work well together. This should be reasonably simple since all support the System.Net.Http types. Thoughts on this approach?

James, as someone who wants to build a combinator library, what are your thoughts on this revised collaboration approach? How do you see Frank or its combinators evolving? Do you like the current set? Should perhaps rethink the approach for creating combinators in light of HyperF's model, especially its filters? 

[James D'Angelo]

Sorry for the late response--been a busy week. I like the combinators you have in Frank, personally. Before really digging into them much more, I think it would be interesting to see how the Taliesin/HyperF merger works. To me, the combinators are the basic API entry point into the libraries. If there is a set that are missing, I don't mind helping out with that. But, that's just my two cents. I'm open to suggestions and some direction to focus my energy (even if it's not on the combinators). I think everybody else with an existing project has plenty to do, so I'm available to help out wherever it is needed.

[Ryan Riley]

On Wednesday, July 16, 2014 10:56:35 PM UTC-5, James D'Angelo wrote:

Sorry for the late response--been a busy week. I like the combinators you have in Frank, personally. Before really digging into them much more, I think it would be interesting to see how the Taliesin/HyperF merger works. To me, the combinators are the basic API entry point into the libraries. If there is a set that are missing, I don't mind helping out with that. But, that's just my two cents. I'm open to suggestions and some direction to focus my energy (even if it's not on the combinators). I think everybody else with an existing project has plenty to do, so I'm available to help out wherever it is needed.

I'm glad you find those combinators useful. One sore spot for me is that I used the ReaderBuilder from F#x to create the combinators for headers. That just seems wrong because the goal is to add headers to the collection. Tomas' update monad may be a better approach, though neither is ultimately immutable. I've thought about refactoring that a bit, but I'm still uncertain as to a better approach. Do you have any thoughts there?

Also, I've wanted to add to Frank combinators for creating HttpRequestMessages and Active Patterns for handing common HTTP workflows. You can find a good sample of some of these workflows in webmachine. What do you think? Does that sound interesting to you? Regardless of the other work, I think this is one of the most important aspects still missing in the F# space. Also, the above are simply the ideas I've had about doing this work. If you have other thoughts, I'd love to hear them.

Cheers!

Ryan 

[James D'Angelo]

I will definite do some more reading around the update monad. Specifically, the paper Tomas links to, and see how to bring it into what is going on here. I do agree that the update monad would probably be a better fit since we're looking at immutably mutating some data and passing it around.  =)

Active patterns could definitely be interesting here. What patterns do you have that come to mind? I can picture clearly what would work on the client

let (|Success|InternalServer|etc|) response =

   match response.StatusCode with

   | code when code >= 200 && code < 300 -> Success...

but do have a feeling that they could be quite useful on the server-side. If you have a specific area to start out in, I'd love to start exploring it. Active patterns are one of my main attractions to F#.

Jim

[Ryan Riley]

I just updated the welcome message with a proposed list of tasks. Please review and provide feedback here. It's just a proposal to get things moving a little more.

Cheers!

Ryan