Why "Oslo"?
Since we started disclosing details about “Oslo” at PDC, I have had an opportunity to talk with tons of customers & partners about it.
One of the questions that I often get is “Why “Oslo”?”, although it is often stated as “Why are you building it?” or “What is the value proposition? or “Why should I care?”
For v1, it is all about developer productivity. We have an internal goal that we call “10x”. At the end of the day, we will judge “Oslo” to be a success if a developer is 10x more productive with “Oslo” than with their current set of tools. We think about metrics like LOC, time to develop, etc.
If you want the clearest example of this, watch my PDC talk starting at 58:23.
We will be rolling out details about the different developer “domains” (Web, Services and Databases) that we will be supporting as soon as we can.
If all you care about is how “Oslo” is going to help you write your .Net LOB/Web application just ignore everything — literally everything — until 58:23 of my talk.
If you are an ISV, particularly one that has an architecture like Sharepoint or Dynamics, the value of “Oslo” should be hyper-clear. Talking with customers like this at PDC, they certainly got it. They can focus directly on their problem domain and leverage “Oslo” to help them do it.
“Oslo” is a journey and we want to make it with the community — that is the reason that we are engaging as early as we are. We have the basic ideas of the platform flushed out and now we are layering on the domains — particularly the developer domains — to see what we need to do to make this approach hit our goal of 10x.
[...] Doug Purdy makes the case for Oslo [...]
New and Notable 278 - Sam Gentile If (DeveloperTask==Communication && OS==Windows)
9 Nov 08 at 02:25
“10x more productive with Oslo than with their current set of tools” to do what? Having read a fair share of the Oslo documentation available right now I still miss a real world example. The web-service demo in your video is nice, but does not show the work necessary to develop the web-service DSL itself.
Regards, tamberg
tamberg
9 Nov 08 at 13:18
@tamberg
To write an .net application.
We are giving you mservice, mweb, etc.
You can, of course, write your own DSL, but we think that that will be the province of mainly ISVs and people that write frameworks today.
metadouglasp
9 Nov 08 at 17:23
@metadouglasp
Thanks for the quick answer. So while MGrammar makes writing and parsing a DSL much easier I guess it’s still not trivial to close the gap between the parse tree of a DSL “document” (accessible from within .NET through System.Dataflow.dll) and a working .NET application or application framework. Or did I get something wrong?
Regards,
tamberg
tamberg
9 Nov 08 at 18:56
@tamberg
You will be able to close the gap fairly easily.
If your framework uses XAML or has a XAML friendly OM, we will have DSL -> XML/XAML in the box.
That said, going off the MGraph directly is not that hard — even I can do it.
metadouglasp
9 Nov 08 at 19:28
One thing that I find confusing with Oslo is that so far the discussion has mainly focussed on (as you put it) developer domains but some of the examples have strayed into business problem domains.
These (business) problem domain examples have so far been pretty unsatisfactory as they’ve shown anemic domain models (no behavior, all about data) which (I presume) would then be operated on by external workflow/services/rules. Is that the way you see Oslo handling business focussed models/DSLs in the future?
Note: I haven’t tried out Oslo yet so I’m only going on videos/blog entries.
Colin Jack
9 Nov 08 at 20:16
@colin jack
there are three layers here.
the first is the “oslo” layer where you model any domain.
you could, of course, choose to model your business at this layer — in fact that is what we are doing — our business domain is the construction of applications.
we think a lot of ISVs and framework authors will model at this layer — as this is their business domain.
the second are the developer domains where a .Net developer will model applications.
It is at this layer, that most business domains for enterprises, etc. will be modeled.
This will be inclusive of behavior, etc. — as we are modeling behavior for you to use (WF, etc.).
that is a key point to get across — behavior is just another model — it is not something special in the system.
i hope that helps.
metadouglasp
9 Nov 08 at 20:26
Wow, now that is a fast response thanks!
Yeah it helps and definitely isn’t something I’d gotten from the other content I’d read.
Just to be clear though, and I accept that since I don’t know fully understand Oslo this may be a naive question, are there going to be limits on how/where we express the behavior in the models in the second layer? In particular in a normal OO domain model behavior takes many forms and is spread throughout the model and I’m hoping Oslo will still support this approach.
Basically I’m hoping that at this level we don’t end up with a Customer “entity” in a model where that entity has no behavior and is operated on by WF/rules. Might not be a realistic issue with Oslo but it was my main worry when I looked at the examples out there (been there done that…).
Colin Jack
9 Nov 08 at 20:34
[...] I wrote my Why “Oslo”? post, I really wanted to drive the simplest story about value of “Oslo” to mainstream [...]
Good observations about “Oslo” from David Ing « Douglas Purdy
10 Nov 08 at 07:03
Thinking more about it I’m guessing a reply to my point would be “stop thinking in the old way, this is a major shift”. Guess I need to try out Oslo myself.
Colin Jack
10 Nov 08 at 10:34
[...] Why “Oslo”? [...]
Oslo – It’s a Floor Wax and a Dessert Topping… « POP Coder
14 Nov 08 at 17:31
[...] Why “Oslo”? [...]
WMOC#26 - Microsoft PDC Roundup - Service Endpoint
21 Nov 08 at 06:00
[...] Doug Purdy makes the case for Oslo [...]
New and Notable 278 : Sam Gentile's Blog
30 Nov 08 at 18:43
[...] Why "Oslo"? [...]
Oslo – It’s a Floor Wax and a Dessert Topping… | popcoder.com
2 Jan 09 at 05:04
[...] nuestra intención es tener un contacto directo y continuo con la comunidad, compartir nuestra visión, escuchar vuestras opiniones y ver hasta qué punto sois capaces de elevar el potencial de [...]
Más ejemplos usando Oslo: Galería de ejemplos de MGrammar - Motivos de un ensamblado
23 Feb 09 at 06:55
[...] nuestra intención es tener un contacto directo y continuo con la comunidad, compartir nuestra visión, escuchar vuestras opiniones y ver hasta qué punto sois capaces de elevar el potencial de [...]
Más ejemplos usando Oslo: Galería de ejemplos de MGrammar - Miemblogs
23 Feb 09 at 07:54