Summer holidays are over, time for a new roadmap

As many of you many have noticed, things have stalled a bit over the summer on the master branches of openrasta and openwrap. While our amazing contributors are still sending pull requests and development has continued, as the owner of the master branches I’ve not been there to maintain the new packages, as I decided to take the summer slow and learn how torest.

Now that the summer is over, I’m glad to clarify the roadmap for OpenEverything frameworks:

  • OpenWrap 2.0 with ReSharper support and cached remote implementation is nearly done, but a lot of features planned for 2.0 will be rescheduled for future versions. I expect a release for this in the next two weeks.
  • OpenRasta 2.1 work is coming along nicely, with all the bug fixes that have been suggested, and some extension points that will be needed for the work on 3.0 to start. I expect that work to be completed by the end of September. I’ll also make OpenRasta available on NuGet, although it will auto-install OpenWrap in your solution.

We’re dropping .net 2.0 support, as it’s been out of the binaries for a while and no one has requested them back, so I’ll assume no one needs that anymore. Note that some work is going in this release that will let OpenRasta manage in-memory / caching automatically, so if your code depends on the request or response stream being seekalbe, I’d start making some changes now.

- OpenRasta 2.2 will be next, and again we’ll take any additional enhancements that don’t break binary compatibility. I’d like to continue taking those changes and start doing per-feature or per-bugfix releases.
- OpenRasta 3.0 is going to be where heavy rewriting is going to happen in parts of the API I don’t like, and we’ll take the luxury of redesigning and renaming / refactoring what needs to be (for example, IType et al will probably disappear and be replaced by a simpler model, the key/values binding model will be updated to provide additional information and extensibility points for those crazy people wanting a plug-in validation framework).
In order to guarantee that  your components using OpenRasta 2 will still work on 3, we’ll be type-redirecting the published extensibility interfaces that are changing into a 2.0-specific legacy API package. In other words, we’ll plug most of the existing contributors, codecs, interceptors, decorators and all other non-generic interfaces straight in the new API, using the same composition engine that will be used by OR 3.0 itself.  - OpenHttp and OpenWebFx are the two components that will provide the basis for OR 3. The former is an extension of the unified hosting environment OpenRasta already has been using for two years, and allows hosting across HttpListener, TCP, IISCore, asp.net and in-memory, based on an async pull mechanism (as opposed to, say, OWIN which is push based, one of the two reasons I’m not implementing OWIN myself). OpenWebFx is the building blocks of a web framework, aka provides the http pipeline model and a couple of building blocks that are core to OpenRasta (codecs, media types, content negotiation…). This will leave OpenRasta itself as a combination of many packages and a bit of custom code on top of it (mainly, the registration API). Code will be out when it’s out, I make no promises, but do expect to see beta versions running on the beta openwrap package repository by the end of the year.  - Everything else is already in the process of migrating to its own packages, so you can expect a first release of OpenContainer (the IoC type resolving compatibility layer) and associated releases to appear around the OR 2.2 timeframe. You can also expect a diagnostics package for OR 2.1 (pluggable of course, named openrasta-diagnostics), a 2.1-specific devtools package (that installs the templates to create projects and solutions thanks to OpenWrap project manipulation), a temporary openrasta-fluent package that contains the new and more compact registration API (which will be type redirected back in the 3.0 API as a replacement for the old syntax), a couple of codecs that will be maintained by us (openrasta-codecs-jsonnet for example, with support for anonymous types and dynamics), etc. Some of those packages (such as our support for Unity, StructureMap, Windsor and Ninject) will be looking for new owners as I start delegating a lot of the package releases to whoever wants to manage them.

This is the schedule for the end of the year, no guarantee implied, as any work I do for clients drives those two frameworks as a priority. If you’re interested in sponsoring some work on OpenEverything for your own needs, please do let me know, we can always figure something out.

Ads

One step closer still

One of the things that OpenWrap 2.0 will feature is dynamic loading and unloading of “solution plugins”, components that load up when you start working on a solution, and unload cleanly when you move to another solution.

One of the side-effects of implementing this is a very cool feature for ReSharper I’m just not ready to announce yet, but that will make sharing ReSharper plugins with your team so easy you’ll wonder how you ever lived without it.

So now this is what happens when you update a package your solution depends on.

Loading packages...
Loading package C:\demos\soladd2\wraps\_cache\openwrap-1.1.0.71250693
Loading package C:\demos\soladd2\wraps\_cache\SharpZipLib-0.86.0
Loading package C:\demos\soladd2\wraps\_cache\openfilesystem-1.0.0.61263243
Loading package C:\demos\soladd2\wraps\_cache\tdnet-framework-2.0.0.48555719
Loading package C:\demos\soladd2\wraps\_cache\Mono.Cecil-0.9.4.1
Solution plugins starting...
Starting plugin AssemblyReferenceNotificationsPlugin.
Starting plugin ReSharperLoaderPlugin.
Resharper Plugin Manager loaded (99.99.0.13133).
Solution opened ClassLibrary1
All solution plugins started.
ReSharper test runner starting.
Solution plugins stopping...
Stopping plugin AssemblyReferenceNotificationsPlugin.
Stopping plugin ReSharperLoaderPlugin.
Unloading Resharper Plugin Manager.
All solution plugins stopped.
Default scope change detected, restarting...
Loading packages...
Loading package C:\demos\soladd2\wraps\_cache\openwrap-1.1.0.71250880
Loading package C:\demos\soladd2\wraps\_cache\SharpZipLib-0.86.0
Loading package C:\demos\soladd2\wraps\_cache\openfilesystem-1.0.0.61263243
Loading package C:\demos\soladd2\wraps\_cache\tdnet-framework-2.0.0.48555719
Loading package C:\demos\soladd2\wraps\_cache\Mono.Cecil-0.9.4.1
Solution plugins starting...
Starting plugin AssemblyReferenceNotificationsPlugin.
Starting plugin ReSharperLoaderPlugin.
Resharper Plugin Manager loaded (99.99.0.13324).
Solution opened ClassLibrary1
All solution plugins started.
ReSharper test runner starting.

There’s a lot going on in there and I’ll be blogging about it soon. If you ever wondered how to build Visual Studio add-ins and still support live updates, then you may just have your answer very soon.

More next week….

Technorati Tags: openwrap

Ads

My colour scheme

People have asked before, after giving presentations, to share my theme. Yes, I commit the cardinal crime of refusing presenting on a white background, it hurts my brain too much.

So I introduce DarkSeb, a Dark blue derivative theme for VS. It’s optimized for the “color identifiers” and “highlight current line” options of ReSharper.

image

And you can download it on GitHub.

Ads