Putting the pieces together

[Christopher Stevenson]

There's been some discussion on whether or not to merge projects (Frank, HyperF, Dyfrig, & Taliesin) into one whole, or keep them as separate projects. Would it be worth while to maintain a "FSharp.Webstack" project that puts together the pieces in a standard way? (Or perhaps  "FSharp.Webstack.Core", "FSharp.Webstack.REST", "FSharp.Webstack.Signalr" etc?)

 

[Adam Granicz]

I would say that the requirement for something under FSharp.* would be widespread use first - you can't delegate a project into the "community recommended" status until it is fully mature, field tested, and proven by the community.  The requirement for being under Webstack.* would similarly need it to be a full web stack, e.g. reaching from client to server and covering most if not all aspects along the way.

WebSharper attempted to give a full web stack implementation but we never implemented an actual web server entirely and many of the server-side intricacies were filled by Ryan's and others' excellent libraries.  We have instead established that sitelets can be embedded in OWIN/WebAPI containers and Ryan I believe has started to adapt Frank to enable constructing sitelets. These and a couple other integration points around client-side DOM would be an awesome future work for this group to establish, leading to a full F# web stack at last!

Let Ryan or myself know where you would like to contribute, I for sure have a ton of work that I could share with able volunteers.

Thanks!

Adam.

On Sun, Oct 5, 2014 at 10:06 AM, Christopher Stevenson <cjsteve...@gmail.com> wrote:

There's been some discussion on whether or not to merge projects (Frank, HyperF, Dyfrig, & Taliesin) into one whole, or keep them as separate projects. Would it be worth while to maintain a "FSharp.Webstack" project that puts together the pieces in a standard way? (Or perhaps  "FSharp.Webstack.Core", "FSharp.Webstack.REST", "FSharp.Webstack.Signalr" etc?)

 

--
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.

--
Adam Granicz, IntelliFactory
www.intellifactory.com

[Christopher Stevenson]

I agree with your take on the state of things. I'd love to help out where I can. Where would be a good place to start?

I have a few years of Asp.Net MVC experience, mainly in C# (but a smattering in VB.Net) following some standard OO patterns (DI, N-Tier, MVC, decorator), and I'm slowly working on a for fun project in F# using WebSharper. (A Japanese Mahjong game eventually, but I'm building some useful web tools first). I think OWIN/Katana is interesting, but I'm waiting for vNext before going to deep into it for 'normal' projects--MVC 5 seems a rather Frankenstein-ish approach to integrating OWIN. 

I'm a little past the "knowing enough to be dangerous" phase of JavaScript, and learning F# and practicing functional programming helped a lot with understanding how JavaScript functions fit together.

I don't have any experience creating frameworks--it'll be something I'll learn by doing, I imagine. (I'm reminded of an Aristotle quote: 'For the things we have to learn before we can do them,
 we learn by doing them.')

[Ryan Riley]

On Sunday, October 5, 2014 1:06:15 AM UTC-7, Christopher Stevenson wrote:

There's been some discussion on whether or not to merge projects (Frank, HyperF, Dyfrig, & Taliesin) into one whole, or keep them as separate projects. Would it be worth while to maintain a "FSharp.Webstack" project that puts together the pieces in a standard way? (Or perhaps  "FSharp.Webstack.Core", "FSharp.Webstack.REST", "FSharp.Webstack.Signalr" etc?) 

Thanks for the suggestion! I don't think these namespaces would be best for frameworks but rather utilities for working with existing web platforms in .NET. Things like FSharp.Web.Mvc, FSharp.Web.Http, and FSharp.Net.Http would make sense, though I don't know what would really be needed. Most of ASP.NET works well with F# already, just perhaps not with the opinions many F# devs would prefer. 

Dyfrig is turning into a lightweight stack, and I plan to get many of the other pieces working with it when it is more fully developed. I don't really want to go with "FSharp.*" for Dyfrig, etc.

[Ryan Riley]

On Sunday, October 5, 2014 6:51:02 AM UTC-7, Adam Granicz wrote:

Ryan I believe has started to adapt Frank to enable constructing sitelets.

I started and got distracted. :) I'm currently planning to do this with Dyfrig, potentially as a replacement for the WebSharper.WebApi library. OWIN has a closer mapping to System.Web's types, and you don't really need to piggyback on Web API to do self hosting this way.