Oslo, ready for take off?

Question

Is it too early to start developing systems or part of systems with Oslo?

Answer 1

"Oslo" right now is in Community Technology Preview (CTP) state, and as of yet we have not announced any dates for the release of version 1. To answer the question in the title of your post, "Is Oslo ready for take off?" the answer is clearly no. Furthermore, the license terms of a CTP (which are displayed during setup) state the following:

• You may install and use any number of copies of the software [Oslo CTP] on your premises to design, develop, and test your programs for use with the software.
• You may not test the software in any live operating [i.e. production] environment unless Microsoft permits you to do so under another agreement.

This means that while you can use a CTP for evaluation and development, it cannot be deployed into a product environment: there are no "Oslo" redistributables at this point, which means that any machine utilizing the technology must have the CTP individually installed and are therefore subject to those same license terms.

Second, the license terms also state that anything can change in future releases, meaning no support for backwards compatibility. There are also features that just aren't in "Oslo" yet, so you may run into the need for capabilities that will be added later on.

So you can certainly begin to develop systems in anticipation of the version 1 release, and there's plenty you might do with the technologies in a non-production/non-resale manner (research, language development, etc.). We encourage that kind of usage, which is why we put out these CTPs. Again, we can pretty much guarantee that stuff is going to break between preview releases, so you have to plan for that.

If you have any more specific questions, let me know.

Answer 2

Could I use the Oslo CTP in a private code-generation tool, and deploy the generated code?  (i.e. would this fall under "a live operating environment"?)

Answer 3

Good question. I'm checking on it with our legal folks to make sure I get the right answer for you.

.Kraig

Answer 4

Sorry to have taken so long to get an answer for you; between myself being on vacation for a while and the holiday weekend here, things get a little behind!

Anyway, after discussing it with various higher-ups, it's OK to use "Oslo" as it exists in the code-generation scenario you mention. So long as you're not deploying any of the "Oslo" components or binaries themselves, you're welcome to use the "Oslo" tools as a productivity boost. That's a big part of what "Oslo's" about, after all!

Good luck with your project.

.Kraig

Answer 5

What about the medium term?

We will need to distribute our translators just like with Antlr; or are we wasting our time and the rug is being pulled under MGraph & MGrammar? (Don't care about the rest: MSchema, Quadrant etc.)

A negative answer would be just as much helpful.

Thanks in advance.

Answer 6

I highly doubt that MGraph and MGrammar would just disappear; they constitute too useful a system by themselves, as you know, and the whole effort around the M Specification Community means that it's a growing concern, not a shrinking one. The M toolchain can exist quite happily outside of the broader "Oslo" context.

If what you mean by "distributing" a translator involves deploying any "Oslo" components to a production environment (such as m.exe), then no, that's not an allowable scenario at this point under the license terms.

.Kraig 

Answer 7

Thanks, happy to hear that.

As you point out, Mgraph by itself is very useful outside of Oslo as a graph representation and manipulation library, even outside of MGrammar (it is about data); and MGrammar is just what we were looking for and was not available on any Microsoft platform (it is about language processing); I should certainly hope that there is no going back on MGraph or MGrammar; I don't personally prioritize MSchema, Quadrant, Repository etc. as high as Mg & Mgmr.

By distributing I mean the reality that we need to hold references to System.Dataflow.dll & Microsoft.M.dll; no need to distribute m.exe or any other tools; but if we cannot distribute these key dlls when Oslo is released and are restricted to just internally generate C# (or whatever) code for our applications, there is just no point in using Oslo.

Thanks & regards,
Ceyhun

Answer 8

By the time "Oslo" ships, I'm certain that your references to assemblies such as System.Dataflow.dll and Microsoft.M.dll will be supported, either via redistributable DLLs or via those assemblies being added to the .NET platform itself (because "Oslo" is positioned as adding modeling capabilities to the .NET platform). So at release time, yes, there will be a solution for you. You just can't distribute those DLLs today.

Hope that's clear now.

.Kraig

Answer 9

Yes it is.

Thanks.

Answer 10

To bad... I just now realised I couldn't deploy Oslo with the application I'm developing. Furthermore it was used only for parsing scripts in the DSL I've created with it.. It is so frustrating, I only needed to deploy System.Dataflow.dll. I'm feeling I have died on the beach.
I'll now have to get another way to parse scripts (probably using Regular Expressions) until there is a version of Oslo that I can use. By the way, in the license is left open the possibility of getting an agreement from Microsoft that would allow the use of it in production environment. What type of an agreement is this? Does it involves money or is it another type of an agreement?

José Tavares

Answer 11

Sorry about your frustration; such restrictions are an important part of the CTP process since it would be a nightmare to have many different pre-release versions of an assembly floating around in production environments.

I'll check about your question on getting an exception as I don't know those details offhand.

.Kraig

Answer 12

Thanks for checking it. There must be something since Sells just announced a tool by telerik for M, and I've seen some controls to use with m languages...

José Tavares

Answer 13

Different folks are releasing their own samples, for instance, as well as some previews of things they're working on. These things do not constitute "production environment" stuff because they're not yet commercial (i.e. for sale) products. All such things, however, that require components of the "Oslo" CTP must still require that the CTP itself be installed, since we don't allow redistribution of those components at this time. That's the real key: the CTP is not to be installed in production environments, so requiring it to run a sample or a preview automatically excludes such things from also being used in a production environment.

We have noticed that the Telerik piece you refer to does, in fact, include some of the CTP DLLs which they shouldn't be doing, and we're getting that corrected.

Everyone must remember that for as early as "Oslo" has been put out to the community, it's still under CTP status and it not a released product at this time. I know it's difficult to hold back because technologies like the "M" toolchain are so wonderfully useful, but there's still going to be plenty of churn as we move toward version 1 (I see breaking change emails every couple of days where just "M" is concerned).

.Kraig

Answer 14

Thanks for the clarification. I guess I'll just hope you guys release the first official version soon.