Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existing HTTP PUT method only allows a complete replacement of a document. This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource.

That's pretty great news, even though it will probably take some time before you can actually gain much of a benefit from it. Until now, there were two options of dealing with resource creation (and update, for that matter):

• Use a POST to create a new resource when you want the server to determine the URI of the new resource
• Use a PUT to do a full update of a resource (or create if it's not there already)

Sometimes, though, what you're looking for is a partial update. You have a bunch of different choices: You can design overlapping resources so that one of them reflects the part you're interested in, and do a PUT on that; or you can use POST, which is so unrestricted it can essentially mean anything.

With PATCH, you have a standardized protocol-level verb that expresses the intent of a partial update. That's nice, but its success depends on two factors:

• The availability of standardized patch formats that can be re-used independently of the application
• The support for the verb in terms of infrastructure, specifically intermediaries and programming toolkits

In any case, I will definitely start advocating its use for the purpose it's been intended to support, even if this means going with home-grown patch formats for some time: It's still better than POST, and using some sort of x-http-method-override-style workaround should work nicely if needed.

Kudos to James Snell for investing the time and energy to take this up.

But how would the fundamental experience of the device suffer if Apple shipped a dev environment with the iPad, just like one used to be part of every home computer (incl. the Apple II)? Is that really an inconceivable proposition? Or heck, it could be a $20 download on the App Store for all I care. That’s no hurdle for a teenager, not even a big one for a preteen. Why must the iPad require a dev licence and a Mac to write code for? (Obviously: because that makes Apple a lot of money.)

Anybody can build a development environment for the iPad/iPhone, this seems to be just a matter of enough commercial interest or enough open source enthusiasts to combine their forces. The real problem is the fact that the only way to get software onto an iPad is through the AppStore. I don't even believe it should be Apple who address the development environment aspect; I'm pretty sure that there'd be a great option for somebody else to build an awesome environment, perhaps based on a modern dynamic language, and this could be hosted on any platform to produce applications for the iPad. But you wouldn't be able to install the development environment itself to the iPad, as the AppStore approval policy explicitly forbids installation of any sort of interpreter, nor could you install applications built with it unless they go through the AppStore.

Apple's reasons for insisting on the AppStore as the only delivery method are understandable from a commercial point of view, at least for now. But ultimately, they'll harm both the users and Apple itself – which makes me pretty sure this will change – who knows, maybe even the first generation of the iPad OS will allow the user to install applications via some other means than the AppStore. My guess is that Apple will wait until they have a very firm position, similar to the way the dropped DRM from iTunes music once they no longer had to rely on it.

Until then, at least there's the set of interpreters built into Mobile Safari …

One line of reasoning that I don't really buy into, though, is the one related to "tinkering". As Alex Payne writes:

The thing that bothers me most about the iPad is this: if I had an iPad rather than a real computer as a kid, I’d never be a programmer today. I’d never have had the ability to run whatever stupid, potentially harmful, hugely educational programs I could download or write. I wouldn’t have been able to fire up ResEdit and edit out the Mac startup sound so I could tinker on the computer at all hours without waking my parents. The iPad may be a boon to traditional eduction, insofar as it allows for multimedia textbooks and such, but in its current form, it’s a detriment to the sort of hacker culture that has propelled the digital economy.

I have some sympathy for these feelings because I have similar personal experience. But the whole things smells a little like complaining about not being able to tinker with your car anymore. The level of detailed fiddling you can do with any sort of device that becomes mainstream has been going down steadily – while my grandfather probably could have repaired a mild engine damage without too many problems, I'm pretty sure not too many people do this anymore today. I believe it's fine to be able to tinker on a totally different level, even if it's in the form of Web apps that run locally. The hypothetical development environment on the iPad – can you imagine what kind of Scratch one could build? – would be more than enough of a compensation from my point of view.

The feeling I understand not at all, though, is the one expressed by Tim Bray:

It’s probably a pretty sweet tool for consuming media, even given the unfortunate 4:3 aspect ratio. And consuming media is obviously a big deal for a whole lot of people.

For creative people, this device is nothing.

Given the fact that I expect there to be millions of people who'll use an iPad to write, and paint, and sketch, using a multitude of applications built for the purpose, I beg to disagree.

Call for Papers

The First International Workshop on RESTful Design (WS-REST 2010) aims to provide a forum for discussion and dissemination of research on the emerging resource-oriented style of Web service design.

Background

Over the past few years, several discussions between advocates of the two major architectural styles for designing and implementing Web services (the RPC/ESB-oriented approach and the resource-oriented approach) have been mainly held outside of the research and academic community, within dedicated mailing lists, forums and practitioner communities. The RESTful approach to Web services has also received a significant amount of attention from industry as indicated by the numerous technical books being published on the topic.

This first edition of WS-REST, co-located with the WWW2010 conference, aims at providing an academic forum for discussing current emerging research topics centered around the application of REST, as well as advanced application scenarios for building large scale distributed systems.

In addition to presentations on novel applications of RESTful Web services technologies, the workshop program will also include discussions on the limits of the applicability of the REST architectural style, as well as recent advances in research that aim at tackling new problems that may require to extend the basic REST architectural style. The organizers are seeking novel and original, high quality paper submissions on research contributions focusing on the following topics:

• Applications of the REST architectural style to novel domains
• Design Patterns and Anti-Patterns for RESTful services
• RESTful service composition
• Inverted REST (REST for push events)
• Integration of Pub/Sub with REST
• Performance and QoS Evaluations of RESTful services
• REST compliant transaction models
• Mashups
• Frameworks and toolkits for RESTful service implementations
• Frameworks and toolkits for RESTful service consumption
• Modeling RESTful services
• Resource Design and Granularity
• Evolution of RESTful services
• Versioning and Extension of REST APIs
• HTTP extensions and replacements
• REST compliant protocols beyond HTTP
• Multi-Protocol REST (REST architectures across protocols)

All workshop papers are peer-reviewed and accepted papers will be published as part of the ACM Digital Library. Two kinds of contributions are sought: short position papers (not to exceed 4 pages in ACM style format) describing particular challenges or experiences relevant to the scope of the workshop, and full research papers (not to exceed 8 pages in the ACM style format) describing novel solutions to relevant problems. Technology demonstrations are particularly welcome, and we encourage authors to focus on "lessons learned" rather than describing an implementation.

Papers must be submitted electronically in PDF format. Submit at the WS-REST 2010 EasyChair installation.

Important Dates

• Submission deadline: February 8, 2010, 23.59 Hawaii time
• Notification of acceptance: March 1, 2010
• Camera-ready versions of accepted papers: March 14, 2010
• WS-REST 2010 Workshop: April 26, 2010

Program Committee Chairs

• Cesare Pautasso, Faculty of Informatics, USI Lugano, Switzerland
• Erik Wilde, School of Information, UC Berkeley, USA
• Alexandros Marinos, Faculty of Engineering & Physical Sciences, University of Surrey, UK

Program Committee

• Rosa Alarcon, Pontificia Universidad Catolica de Chile
• Subbu Allamaraju, Yahoo Inc., USA
• Tim Bray, Sun Microsystems, USA
• Bill Burke, Red Hat, USA
• Benjamin Carlyle, Australia
• Stuart Charlton, Elastra, USA
• Joe Gregorio, Google, USA
• Michael Hausenblas, DERI, Ireland
• Rohit Khare, 4K Associates, USA
• Frank Leymann, University of Stuttgart, Germany
• Mark Nottingham, Yahoo Inc., Australia
• Aristotle Pagaltzis, Germany
• Ian Robinson, Thoughtworks, USA
• Richard Taylor, UC Irvine, USA
• Stefan Tilkov, innoQ, Germany
• Steve Vinoski, Verivue, USA
• Jim Webber, Thoughtworks, USA
• Olaf Zimmermann, IBM Zurich Research Lab, Switzerland

Contact

WS-REST Web site: http://ws-rest.org/
WS-REST Email: chairs@ws-rest.org

I strongly believe that building your own software is an essential ingredient for a successful, information-centric company such as a bank, an insurance company, or even a telco. I think it’s an excellent idea to use commodity services in all areas where you don’t have, nor want to have, any competitive advantages. But you should build something on your own if you want to innovate.

I also wrote that while it’s pretty fashionable to deride the claims that enterprise software is “inherently more complex” than much of the Web stuff, it is in fact true sometimes. One of the reasons is the absurd complexity of laws in some countries, and the rate in which more and more complexity is added to them. If you’re in a regulated business, this tends to create a huge amount of complexity you simply can’t escape from (unless you change the laws, or rather the whole legislative and political process, of course).

Another source of complexity is the business side, coming up with more and more complex product requirements. In many Web companies, there’s no difference between the business and technology decision makers – perfect “business/IT alignment”. This simply isn’t true in most large businesses. As a tech person, you have a choice of quitting or adapting to it …

I still agree that many of the practices, technologies and tools used on the Web can be put to excellent use within the enterprise. But even if you are given free choice of weapons in terms of tools and methodology, the typical constraints can ruin your day pretty soon.

Anyway, while I see some issues with Tim’s post, I still think there’s a lot of truth in it. Given that I spend most of my time in enterprise contexts, I strongly believe putting more of the Web into the enterprise is an excellent idea.

For many years, I have been searching for what I call the "holy grail of concurrent programming." I have been looking for a set of abstractions as powerful as classes and objects which describes activities and their coordination. Just as was the case for the medieval quest for the holy grail, I am not alone. Many other researchers are searching for this. I remember that at the time when I started doing my Ph.D. in 1996, I was talking to Doug Lea about this subject; and he urged me to continue this line of thought. My thesis subject ended up going down another path, but the issue has persisted at the back of my mind, ready to jump up whenever I experienced new evidence that might guide me.

For the last couple of years I have been pursuing these issues more persistently; as chief editor of the JAOO and QCon conferences I have invited speakers that have something related to this on their hearts and mind, and the last six months - since working more intensively with the Erlang programming language - they have started to grow into a more consistent picture.

So here is a little essay and some ramblings on some of the things I have found out so far.

Excellent stuff.

Am 18./19. Februar findet in einem schönen Hotel in der Mitte Deutschlands (Details folgen :-)) eine zweitätige kleine Unconference (Open Space) rund um DSLs statt. Die Idee ist: miteinander reden, philosophieren, diskutieren, demonstrieren, coden, voneinander lernen - rund um DSLs, intern und extern. Also Dinge wie: Scala, Groovy, Ruby, Eclipse, MPS, Parser, etc.
Das ganze ist keine Schulung, jeder Teilnehmer muss etwas beitragen!

Wir organisieren das gemeinsam ohne kommerziellen Hintergedanken, d.h. die Kosten werden geteilt (wer mit 200-250 Euro pro Person kalkuliert, liegt wahrscheinlich nicht falsch).

Bei Interesse an einer Teilnahme bitte eine kurze Mail mit einem Beitragsvorschlag per E-Mail an Markus oder mich, Rückfragen gerne auch hier in den Kommentaren.

I understand where Tim comes from, and I fully admit that even after playing with Lisp, Scheme and Clojure for quite some time, I'm still not sure whether this is really an issue. I would only feel qualified to really comment on it once I have used it on a real project with some complexity. But what I found interesting is the example Tim gives:

(apply merge-with +
  (pmap count-lines
    (partition-all *batch-size*
      (line-seq (reader filename)))))

I find this particular example to be extremely readable if you read it from the inside out - the reader function presumably returns a reader for the file named filename; line-seq returns a (lazy) sequence of the lines in the file, partition-all cuts this into segments (using *batch-size* as the, well, batch size), pmap maps the function count-lines over the result in parallel, returning a list of maps; finally, merge-with + combines all of the values for the same keys in the map by adding them. (Obviously the source code is much more understandable than my prose version.)

I agree there is a ton of Lisp code out there that's intimidating, but I don't see this as a good example. Let's invent a language with similar expressiveness, but more traditional syntax:

apply(mergeWith(plus),
  pmap(countLines, 
    partitionAll(BATCH_SIZE,
     lineSeq(reader(filename)))));

I can't see how this would be easier to read. It's not the syntax (at least not in this case) that might be a problem if you're not used to it, it's the style of using nested function invocations – which I believe is something you get used to really quickly if using any kind of language that supports functional idioms.

So I'll try to update this place a little more often, even though the Web is probably littered with blogs that end up having famous last meta-entries like this one …

• [Don has promised not to tweet. That's a good start.]
• Interesting similarities btw/ M and MPS
• M is a language for data - one of the most interesting places of data is a sequence of Unicode code points
• Great support for text processing perceived as critical
• Example: extract some data from text - tweets
• Intellipad - default environment for writing grammar files, this is where tool support shows up first, then in Visual Studio

• M code for a language definition (a function from text to something else, declaratively specified):

  module QCon
  {
      language Simple
      {
          syntax Main = empty;
      }
  }
  

• Main is the rule that is the entry point

• Open file in three-pane (or rather, four-pane) mode
• Show source file, grammar, show output - empty file yields Main []
• Amanda makes a great assistant ;-)
• Non-empty file produces errors
• Change "empty" to "any" - file with a single character works, more than that produces errors; change to any+, validates again

• Simple language for interpreting tweets:

  module QCon
  {
      language Simple
      {
          syntax Main = Tweet;
          syntax Tweet = Content*;
          syntax Content
              = RawText
              | Handle
              | HashTag;
          token RawText = (any - ("#"|"@"))+
          token Handle = "@" Name;
          token HashTag = "#" Name;
          token Name = (any - ("@|"#"|" ""))+;
      }
  }
  

• regular expressions at the token layer, context-free grammar at the syntax level

• Amanda: "Only crap languages make you define something before you have to use it"
• Discussion betwen Josh, Amanda, Don about whether or not the grammar is correct
• Good point about interactive grammar development using the three-pane editor
• Pattern names used to display data in a structured way
• Adding @Classification["Keyword"] syntax-colors the source
• M is structurally typed
• M consists of lists and records
• Generating the right-hand side:
• Intellipad crashes! [Boom!] :-)
• The spec for M is licensed under the Microsoft OSP (which makes people as happy as they can be working with Microsoft)
• Javascript-based implementation of parts of the language; subset of the three-pane mode
• Toolchain is written in C#, parser written in M, more and more compilers written in M

• Intellipad crashes! Again! [Boom!] :-)

  module QCon
  {
      language Simple
      {
          syntax Main = v:Tweet => v;
          syntax Tweet = v:Content* => v;
          syntax Content
              = v:RawText => v
              | v:Handle => v
              | v:HashTag => v;
          token RawText = (any - ("#"|"@"))+
          token Handle = "@" v:Name => v;
          token HashTag = "#" v:Name => v;
          token Name = (any - ("@|"#"|" ""))+;
      }
  }
  

• bubbles up the actual content, result is just a list of the strings extracted

  module QCon
  {
      language Simple
      {
          syntax Main = v:Tweet => v;
          syntax Tweet = v:Content* => v;
          syntax Content
              = v:RawText => v
              | v:Handle => v
              | v:HashTag => v;
          token RawText = v:(any - ("#"|"@"))+ => { Kind => "RawText", Text => v }
          token Handle = "@" v:Name => { Kind => "Handle", Name => v };
          token HashTag = "#" v:Name => { Kind => "HashTag", Topic => v };
          token Name = (any - ("@|"#"|" ""))+;
      }
  }
  

• Question from Josh: Isn't this mixing lexing and production rules? Don: Goal is to have no difference, but it can be pulled out

• Next: Consuming stuff
• Using TDD to Don's tweets
• VS project includes language grammar defined earlier
• Amanda: Can one debug a grammar? Don: Answered later
• M runtime can be hosted inside a C# program
• Recently stopped internally to use .NET 3.5/VS 2008, now exclusively on .NET 4 and VS 2010
• Language defintion is included in the program binary

• Showing off some

  var language = Language.load(/* MImage */ typeof(Program).Assembly, "QCon", "Simple"); // yields runtime that can parse a program
  dynamic result = language.ParseString(input);
  bool hasHashTag = false;
  foreach (var content in result)
  {
      hasHashTag = content.Kind == "HashTag";
      if (hasHashTag)
          break;
  }
  AssertEqual(true, hashHashTag);
  

• Demo is actually working

• Change AssertEqual to Assert.IsTrue to get around exception thrown
• Question from Ian Robinson: Q. Can LINQ be used to walk the result? A. Not yet, as dyamic and LINQ don't mix yet
• Not going to write any more C# types, has written all that are in him ;-)

• "This will fail!"

  var language = Language.load(/* MImage */ typeof(Program).Assembly, "QCon", "Simple"); // yields runtime that can parse a program
  dynamic result = language.ParseString(input);
  var query = (from content in ((IEnumerable)result).OfType<dynamic>()
              where content.Kind == "HashTag"
              select content).Any();
  Assert.IsTrue(query);
  

• It failed indeed.

• "This talk is not about integration of two features I don't work on"
• M is optionally typed, structurally typed
• optional typing: syntax Bob = any* : Integer32 => 42;
• only partially plumbed in the current version

• Example for structural typing (not really working yet):

  module Ola 
  {
      type HashTagRec = 
      { 
          Kind : Text where value == "HashTag";
          Topic : Text;
      }
  }
  

• Rudimentary grammar debugging: set breakpoints in input source text; 4th pane shows up, shows matching stack

• Syntactical and semantical editing support
• Semantics relies on hooks that are not there yet
• M is built using an M Grammar
• Language completion for M is built using C#
• Ambiguators for GLR need to be written in C#
• One of the metrics used to evaluate the language: XML. There is a grammar for XML, briefly demoed.
• MPS guys have a different religion – Microsoft believes people have a text editor they love
• <?magnum PI?> :-)
• Comment from Martin Fowler: Main difference to classic tools such as ANTLR is the dynamic - no code generation needed
• Comment from Ola Bini: Didn't see the type-checking and debugging before – now he's impressed

• A DSL is a computer programming language of limited expressiveness focused on a particular domain
• PHP originally started out as a DSL, but is no more
• SQL is an excellent example of a DSL
• Ant as an example of focus on a particular domain
• 2 flavors of DSLs internal and external
• An internal DSL is a kind of API
• Expressiveness matters more than the implementation details
• methods in a DSL make little sense out of context
• Example: fluid interface as DSL, calendar.add("dentist").from(fourPM).to(fivePM).at("123 N Southwest Ave");
• Example of something that hides intent in lots of ceremony
• be declarative, be accepting
• every API is a conversation - with yourself, your team members, your business
• Patterns for internal DSLs
• method chaining | type transmogrification
• Explanation of fluid interface pattern using the Calendar example
• Example: Mocha, Ruby mocking framework as another example
• the finishing problem: what's the final thing that gets returned?
• nested closures | semantic model
• a lot of times, a DSL is an interface to a library, but there should be an underlying model

• Awsymandias: DSL to describe Amazon EC2 environments

  stack = define ... do |s| s.instance :db, :instance_type => "m1.large" end stack.launch

• (classical model of using ruby class methods and blocks)

• definition should != domain model
• high-level DSL should be separate from the domain model [I very much agree; much of it is due to the tricks you have to do to get something that reads nicely]
• keep domain model clean
• literal extension | string polishing
• monkey patching and converting something that's nearly code to actual code
• Groovy example of a simple DSL, similar to what you'd do with Hpricot
• digression: shows how to re-open classes in Ruby, using things like 5.seconds
• shotgun approach to opening classes
• Groovy's category support enables clean addition of methods to classes
• [Didn't know Groovy has some kind of extension method support, pretty neat]
• literal extension | method chaining
• Example: jQuery uses Javascripts prototype model to add functions to objects as needed to support fluid method chains
• method chaining andChaining andChaining
• example: Ioke
• DSL for Starbuck's weird combinations
• ispec is the coolest spec framework ever
• a DSL is an API, a language, a conversation
• be declarative
• know your audience
• use fluent interfaces, message chains
• nested function | closure
• audience comment: Showing a complex API that's simplified misses the point, which is about having domain experts understand the language [I disagree, the domain expert in this example might be someone who understands the simplified code, but not the convoluted mess it's become]
• Martin Fowler: both DSLs for programmers and non-programmers are useful
• Q. Another useful pattern: natural language interpretation, Cucumber as an example
• Q. Real world use? A. Often used in high-level functional test specs

• Cloud computing changing the game between development and operations
• Suggested design goals for cloud computing
• Integrated approach to application design, development and operations
• Tennis match going on between the dev and ops side
• Performance, scale and availability of design and operational decisions
• You usually can't just tell the platform to scale your app
• The offerings of commercial companies are mostly the result of buying companies that cover either operations or development
• How can agile practices be applied to operations?
• (Nice quote "Mimicking the illusion of working software by building a lot of documents")
• Development values what is built; operations values what does not happen
• Automated build, test, integration - what's the test environment in operations?
• Not really test, rather planning and rehearsal
• Autonomous teams – in operations, there's always a lot of legacy dependencies, need for situational awareness
• Continuous integration - in operations, what's the source code?
• Examples: Why can't two servers communicate? security, server configuration, network configuration, firewall …
• Example: What do I need to scale out? Easy, simply start up more machines … no, not really: impacts on other systems, e.g. security systems, load balancers, monitoring, CMDB, service desk. Architectural issues: stateful or stateless nodes, repartitioning; limiting the scale out
• Example: What is the authorative reality? What's the different between the current state and the one I want
• In operations, transitional states matter a lot more than in development
• What we have now: on demand provisioning of commodity infrastructure and constrained applications
• What we still need to consider: configuration as data and as code; collaboration on design, development and operations
• What funds a project is usually very different form what funds operations
• IT complexity is overwhelming - not sure whether this is accidental or inherent complexity
• Little tooling for collaboration in operations
• Integrated view of operations and design: Different planes – management plane, cloud control plane, application plane
• All of the vendors are working on building a platform for controlling cloud resources
• Key question: what's the source code?
• Bottom-up approach (based on scripts, recipes, runbooks)
• Chef: DSL for describing infrastructure
• Puppet used by Google to standardize all OS X desktops
• Trying to use Maven in operations
• Top-down (modeled viewpoints, enterprise architecture, configuration models)
• UML profiles, MS uses Oslo to describe different viewpoint models
• Configuration models: W3C SML - now it's been standardized, nobody's using it
• Model-driven Collaborative Application Design
• "All modeling is programming, all programming is debugging" (Neil Gunther)
• Chef is very popular because it's easy; Puppet is declarative, which makes it hard to debug
• Analogy: SQL query plan; tools could derive a plan from a declaratively specified model
• Accounting barriers to Agile operations
• Capex vs. Opex is only partially addressed in reality, as HW is only part of the cost
• Promising approach: Time-driven activity-based costing; activity-based costing is an approach used to make consultants rich in the 80s, but in combination with time-driven seems useful
• How to arrive at an integrated approach:
• distributed, autonomous descriptions of the complete configuration
• document-based description as the basis for collaboration
• The way to enable collaboration of autonomous owners is to link configuration pieces via hyperlinks [he is a REST guy, after all]
• Model-driven approach because something is needed that's both data and code
• Problem with data: hard to debug
• Problem with code: hard to see what's in it
• Mentions Lisp as data is code/code is data example – it's been done before

• Elastra approach: "Elastic Modeling Languages" (Open Source licensing): EMML, ECML, EDML - doesn't expect these to become standards, but part of the debate

• Q. Applicable to private clouds? A. Very much so.

• Q. There's a trend of expanding Continuous Integration to Continous Deployment. Does this apply? A. Modeling is not a conflict to an agile approach, small changes could be in production, no need to do things in a monolithic way. Both exist and need to co-exist.
• Q. (rather a comment) one can start with a DSL, validate it, check dependencies etc. – bottom up is not a conflict A. A textual DSL is just a model.
• Q. Would "structure" be a better term than model? A. That would only part of it. "Model" has many connotations people don't like, which is why people start using DSL
• Q. Connection of OSS/Telco experience? A. One example is Erlang and Mnesia showing up as a technology in the Cloud space.
• Q. Are there new technologies in the security space? A. Federated ID technologies getting some tractions, e.g. Azure using WS-Federation, SAML and OAuth are both growing. Directories still primary way.
• Q. Is there a directory in the cloud? A. Concept of "virtual identity" instead, e.g. OpenID. SAML can be used with some Google apps, some Salesforce.com apps
• Q. As an alternative to complex tooling, can co-locating/integrating developers and operations people help? A. Two approaches: Let's not do ops, let's just have developers do operations. Not good, usually a different value system. Second: Co-locate them and create autonomous teams. Good approach, larger Web shops do this - still a shared service team. Classic scaling problem: lots of interdependencies between teams. Tooling can help. Sometimes you even have to separate teams due to regulatory reasons.