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 to*rest*.

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.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Pedro Felix

    Could you clarify the “async pull mechanism” in opposition to the OWIN’s push model?
    By pull do you mean that on the response the “handler” returns a stream to the OpenHttp, that then pulls the content from this stream? What advantages do you identity in this model?

    • http://codebetter.com/sebastienlambla/ Sebastien Lambla

      The OWin model is based on data being pushed as it gets received, with some mechanism to tell the host to stop sending data. It makes implementation harder as it tries to model IObservable. OpenHttp is based on a read / write schedule decided by the app rather than by the host, as I want to rely on the fact that threads are cheap, thread context switch is expensive, most processing is quick and the TCP stack already has a naggle algorithm to suspend receiving data until there’s someone to process it. It makes the delegate nicer to work with.

      The implementation of streams is an orthogonal concern. We get data when the end app (or one app in the chain) is scheduling a read, we write data whenever we get a callback saying the app is ready to write. Streams are built on top of that as chainable adapters implementing async and sync with one thread wait, as most codecs in the OR world are synchronous anyway for the most part (although, I am cooking something around xml for that too, but that’s way too early to talk about it).

  • antimonio

    OpenContainer, StructureMap, Windsor, SimpleIOC…

    WTF???

    • http://codebetter.com/sebastienlambla/ Sebastien Lambla

      OpenContainer is not there to be an IoC container but to be an adapter on top of other containers to provide a uniform way to build object graphs. By default, each IoC container has its own conventions, and in a package-managed composition-based world this would make developing code for OpenRasta close to impossible. So we have an adaptation layer that more or less turns any IoC container in something that looks and smell like castle windsor :)

  • Anonymous

    Will the OpenRasta NuGet package install OpenWrap for a specific purpose, or is it just to encourage general uptake of OpenWrap?

    • Sebastien Lambla

      The future of OpenRasta is completely tied to OpenWrap, so going forward it will be the only supported scenario of usage. This is both because all the VS integration work is going to be based on OpenWrap functionality, the next big version is going to be dependent at runtime on OpenWrap for composition, and because I want to only support that scenario. Uptake of OpenWrap is just a side-effect rather than a driver. That said, it’s OSS, if people don’t like how things are packaged they can build their own dlls.

    • http://codebetter.com/sebastienlambla/ Sebastien Lambla

      Two reasons, the first is that OpenRasta is going to rely more and more on OpenWrap for its functionality, and OpenWrap has features that cannot be replicated in other package managers. The second one is that I don’t want to support multiple delivery mechanisms, it’s too much work and we don’t have the resources to support that. As a nice side-effect, it does encourage adoption so that’s an added benefit. That said, it’s OSS so if people just want the dlls they can compile them themselves. :)