I opposed strongly against the naming conventions used in the $-systemMethods so I should be happy.

But facing such a backwards incompatibility in 2016.2 makes me very sad. We've planned several major new features in our application all using REST  and JSON to be released on 2016.1 very soon. Now we have to review a lot of code and try to decide what to do with them in order to be compatible with future releases. I don't like the suggested macro solution, but it might be the only viable way. We might even switch back to our own JSON implementation which we have used for years.

The most important other issue I opposed to is the interface of the Dynamic array, it is not compatible with the existing COS %Collection interface. Is there any change that will be 'fixed' too ?

Interesting article, but where have the pictures gone ?

I remember seeing a version which had them, was that another resource ?

Congratulations John !

You really deserved it.

For query parameters you'd use the syntax <url>?param=value, e.g. 

/appName/customers?lastName=Slagman&gender=M

In your <route> the url would be: 

<Route Url="/customers" Method="GET" ...

And in your method you'd use:

Set lastName=%request.Get("lastName")

We use an XSLT utility to merge the two Productions, where the existing 'Production' Propduction has prevalence.

Did you know that when you define a ClassQuery that secretly behind the scenes a ClassMethod is being generated that executes the query ?

For instance if you have a query

Query ByName(Name As %String) As %SQLQuery(CONTAINID = 1)
{
SELECT %ID,Address,City,Name FROM ClassQuery
 WHERE (Name %STARTSWITH :Name)
}

There will be a ClassMethod ByNameFunc(Name) which returns a %SQL.StatementResult object.

Even simpeler: it could be an option of the mapping settings. Then there is no need for this pseudo-namespace.

It would be handy if we would see and be able to check some version or build number.

If I look at the installed plugins, the all seem the have some sort of timestamp: 20151118, which doesn't look very up-to-date to me. Using the suggested link by Dmitry doesn't work for me: No Updates Found

As I understood, the Atelier separate download was 'initial', you need to use the update features of Atelier (Eclipse) to get the latest client version.

But i agree that upgrading Cache/Ensemble FT 2016.2 should include the Atelier latest version

I assume your interfaces are all part of a bigger application, AFAIK there is no way to span an Ensemble Production across namespaces and from a EIA/ESB point-of-view having separate (connected) productions running on a single Ensemble instance doesn't make much sense.

Your idea to have individual builds and deployments makes sense though, but that would be more stuff that a dedicated build/deployment tool should be able to do

Considering myself among the 'the older and more established users of InterSystems technologies' ;-) we've always used the setup where each developer has his/hers own development machine. How the 'sandbox' namespace is called is not relevant. We use Git to tie the stuff together (more and more automated). It is allowed, or even encouraged, to use different versions of Caché or (in our case) Ensemble, which sometimes results in code that is not compatible with the current Production version, but we detect that in our QA phase and that might trigger discussions wether to upgrade Production if a used incompatible feature is of great value.

Having a separate development sandbox leaves room for experimenting which you wouldn't have if every developer is working in the same namespace, where in my opninion 'not to step on each others toes' would be much too constraining.

It will probable the same when Atelier takes off, some of us will be using that while others will stick to Studio or even brew their own in MS Code. 

That's the point you make the decision based on values of elements or attributes within those elements, XSLTs XPath expressions make it very easy to address and 'extract' those.

XSLT in combination with %XML.XSLT.CallbackHandler is an excellent way to extract information from a (large) XML file.

We use it to perform XML Shredding and flattening on very large XML.

If you're controling the webservice 'on the other side',  the best way to handle this is to make it asynchronous, just returning a sort of Ack that the message is received.

Depending if you need information back or not the service can return a status back.

Also since the service seems to provide rather unrelated functionality, it might be a good idea to split the service up in different services.

The same security precautions would be for generator methods which can execute any code as well during compilation.

Does this mean there won't be a 2016.1 ?

If not what is the expected release period of 2016.2 ? The name suggests Q3 2016 ?

Bill, Luca,

Have you ever considered Caché as a container as opposed to in a container ?

Secure (sandboxed) small applications (let's call them MicroServices ;-)) easily deployable, replicable and synchronizable across multiple Caché instances.

I still find Docker containers a huge overkill (in terms of needed stack) if all you want to containerize are Caché applications.