Latest concrete thinking on Jasper

[Jeremy D. Miller]

If you missed it, "Jasper" is the working codename for complete reboot of FubuMVC on the new ASP.Net vNext runtime. I haven't done much yet, but I started a new GitHub project at  JasperDotNet/jasper. All I'm doing right now is fleshing out the README with high level plans.

				JasperDotNet/jasper jasper - Next generation application development framework for .Net
				View on github.com	Preview by Yahoo

I was in Salt Lake City last week and had quite a few conversations with Corey about the possible directions we could take, with the official goal being a pathway to moving our newest, fasted moving big project to the new ASP.Net vNext runtime next year. Roughly speaking, we have two possibilities:

1. Port FubuMVC to the new runtime and call it 3.0. Try to change as few API's as possible. I'd probably try to collapse Bottles back into FubuMVC.Core if I do this. Not sure if I'd bother with FubuCore.

2. Get a move on and build the core elements of Jasper fast

I would very, very strongly prefer to do #2, but pragmatism and prudence suggest that #1 is what we should do (at least at first).

That being said, here's the latest thinking on Jasper:

• Go ahead and take a dependency on MVC 6. Use the pieces of it that are usable. Try to be a value added, modular replacement for things Jasper would do better than MVC rather than a complete replacement. This is a very different angle than I was taking a couple months ago, but Corey made a good case for doing this. I think we'd be smart to stay closer to the mainstream this time. I think we could at least allow you to use MVC6 actions and IActionResult kinda things within Jasper chains to make adopting and transitioning to Jasper much easier than it was going from ASP.Net MVC to FubuMVC.
  
• The core things that Jasper should provide right away are a better routing module (MVC's is very inefficient for the way we used it in fubumvc), a close analogue to FubuMVC's BehaviorGraph model so you can use policies and conventions to assemble middleware per route, and a way to alternatively use FubuMVC style "Endpoint" methods without the silly IActionResult stuff.
• Corey & I don't entirely agree with this, but my thought is to use a content negotiation model very close to what FubuMVC 2 has. We can *delegate* to pieces of MVC6 codes within our conneg infrastructure however. 

One of the things Corey suggested was to try to use MVC6's implementation wherever that's not disadvantageous. I somewhat amended that to saying we could use pieces of MVC6 like the "IBuilder" interface upfront to get going faster, but replace that later with a different "composer" module based on Roslyn metaprogramming.

Roughly speaking, if I am able to start working on Jasper next month, my plan of attack is:

1.  Seed the code, get comfortable with the new runtime, try to get an auto test setup going w/ Fixie
   
2. Build the new routing module based on the Trie runtime
3. Adapt the existing FubuMVC BehaviorGraph/BehaviorChain model to assembly nested OWIN handlers. Maybe delegate to MVC6's IBuilder in the first iteration
4. Adapt the FubuMVC 2 conneg model
5. Rebuild the default conventions from FubuMVC2 into the new bootstrapping, but use Roslyn metadata instead of type scanning (maybe)

I'm still not sure that anything real will happen, but I still wanted to push this out this week to see what y'all think.

 

Jeremy D. Miller
The Shade Tree Developer
jeremy...@yahoo.com

[Corey Kaylor]

I might also add that anywhere we are adding value to extend or replace existing aspmvc capabilities we demonstrate that value before we commit to maintaining it and seriously evaluate that it's something we want to maintain for the long term. If not, we favor OOTB instead.

For example, I really don't want to maintain separate view engines anymore. The first topic that will come up if we aren't is "yeah but I don't want them to scan for changes at runtime when we already know the views on startup". I agree with that statement in theory, but we should be able to demonstrate that we get real performance benefit by creating an optimized shim that we have to maintain down the road. For this example, aspnet caches view location already so would our enhancements gain us much in the end? Maybe not, but something measurable makes it seem less of "they're dumb, we're smart" and more objective. Possibly these concepts would be better incorporated into aspnet itself if we really feel like it's value is enough to justify the longer term maintenance of what we're building.

Another example, static middleware *I* think makes zero sense to maintain if there is an OWIN middleware that meets our needs. If one doesn't meet our needs, but only needs slight improvements I would vote we contribute those changes there to avoid the longer term maintenance implications.

--
You received this message because you are subscribed to the Google Groups "FubuMVC Development Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fubumvc-deve...@googlegroups.com.
To post to this group, send email to fubumv...@googlegroups.com.
Visit this group at http://groups.google.com/group/fubumvc-devel.
For more options, visit https://groups.google.com/d/optout.

[Corey Kaylor]

Also "a way to alternatively use FubuMVC style "Endpoint" methods without the silly IActionResult stuff." is something that mostly works OOTB as well.

[Dru Sellers]

color me 'intrigued' - staying closer to MVC 6 is a plus for larger adoption. Especially, if you can 'slowly' bring parts of Jasper into MVC to get a better value.

[Adam Schröder]

This sounds like a great idea, and kind of where my library schostack.web takes its roots by adding

 - HtmlConventions (hooked up to the form's target input model)

 - AttributeRouting

 - Urls based on 'In Model' for controller

 - Razor loop helpers

to Asp.net MVC now.

Would be happy to help out should this get going.