Independent Submission Marko Oikarinen Request for Comments: 79O6 Sysart Oy Category: Informational 1 April 2016 The Hypertext Transfer Protocol Status Code 462 (Out For Lunch) Abstract This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when a human-backed server resource is unavailable as a consequence of said human participating in a process of consuming nutritional substances. Status of This Memo This Internet-Draft is not submitted. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 1, 2017. Copyright Notice Copyright (c) 2016 The persons identified as the document authors. No rights reserved. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 2 3. 462 Out For Lunch . . . . . . . . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. International Considerations . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Appendix A. Acknowledgements . . . . . . . . . . . . . . . . 6 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when a server operation internally utilizes a resource implemented in flesh and bone and said resource is currently having lunch or is in a post-lunch RESTful state, therefore unable to provide the required resource, thus forcing the server to deny access to the resource or to a set of resources which includes the requested resource. This status code can be used to provide transparency in circumstances where service availability may affect client operations. This transparency may be beneficial to end users. 2. Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "APRIL", "FOOL", and "DESSERT" in this document are to be interpreted as described in [RFC2119]. 3. 462 Out For Lunch This status code indicates that the server is denying access to the resource as a consequence of a required human dependency having lunch. This status code is not to be confused with status code "461 Out To Lunch" which has to do with server behavior under the influence of cosmic rays when financial considerations have made the administrator decide against investing in error-correcting (ECC) server random access memory. A human backed resource may be manifested in ways including but not limited to: a senior dead-tree archive manager, a microfilm squinter, an adidas conveyor, a ticket pusher or a ticket dodger or a Just-In-Time (JIT) backend feature developer. 4. Security Considerations Server resources addressed with the "coffee:" URI scheme as specified in RFC2324 MUST NOT return status code 462, as a HTCPCP/1.0 (Hyper Text Coffee Pot Control Protocol) device is expected to be autonomous and not utilize humans in its implementation. Such HTTP responses are to be considered potentially malicious. Clients cannot rely upon the use of the 462 status code. It is possible that certain resources utilized by the server might wish to avoid transparency, and not disclose that they have left the premises in order to dine at the local gentlemen's club. 5. International Considerations The use of the 462 status code implies temporary unavailability of the resource named in the request. It is expected that a later request for the resource may succeed if the resource has recovered from the digestive condition. When an attempt to access a resource fails with status 462, it is to be expected that the recovery time of the server is highly locale dependent. In a worst case scenario the situation might involve a six course meal with DESSERT and a post-nourishment RESTful period also known as a siesta. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2324] L. Masinter, "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)", RFC 2324, 1 April 1998, . 7. Appendix A. Acknowledgements This document was inspired by RFC 7725 by Tim Bray and borrows some phrases from it with minor adaptations. 8. Author's Address Marko Oikarinen Twitter: @whoman4says Blog: https://scribblelayer.com/ Employer: http://sysart.fi/
I type the program arguments into an Excel sheet. I write a short description of what I am trying to accomplish. I send the description and the Excel sheet to a person that has access rights to the ticketing system. Repeat three times. The next day she reads my emails and submits the three tickets.
The three tickets get assigned to three persons in a country where work used to be cheaper than here. They type the program arguments from the Excel sheet into the scripts that will run the programs. They mark the tickets resolved. Corporate metrics show exemplary ticket handling response times.
Next week another ticket gets resolved and a tester gets access rights to the system. She runs a test case for my use case. It doesn’t work. I request access to the log files from the server admin. Next day I have the logs and find out that the second script failed to trigger the third script due to file access rights. No problem, that is easy to fix.
I write a short description of what I am trying to accomplish. I send the description with an Excel sheet to a person that has access rights to the ticketing system. I realize that this is state of the art in Enterprise DevOps in 2016.
In the fall of 2010 we at Sysart organized a small conference at Helsinki and Oulu. Daniel Wellner and I did our presentation on how to keep the domain model unambiguous. Jimmy Nilsson was the featured guest and talked about building a domain model.
In his presentation Jimmy said something that caught my ear: “The user should be able to save invalid data“. The concept is explained in chapter 7 of his book Applying Domain-Driven Design and Patterns. The book says: “All States, Even When in Error, Should be Savable”. The idea is simple but not widely applied – when a user cannot complete all the required information the application should still allow saving the partial work he or she has done.
The concept stuck in my mind. Every now and then a situation comes up where this idea seems to fit. Think of a doctor entering a diagnosis into a patient care application. A diagnosis entry form might contain a dozen fields. It would seem useful that the doctor could enter just the most important data while with the patient, save the entry and complete it later. But applications tend to be too eager and demand everything to be completely valid on first save.
Then I stumbled upon StaffPad. StaffPad is an application for writing music. Writing music. Not typing, not mousing around. Writing music the old-fashioned way, with a pen. As a songwriter I was immediately intrigued. Could this application make notating random ideas into a computer feasible for me? I always preferred pen and paper because I disliked the input methods in all the music applications I tried.
The pen works really well for entering notes, rests and other symbols. But what happens when StaffPad does not recognise your writing? It applies Jimmy’s advice and saves the unrecognized strokes as part of the page. If you print the score, the mystery symbols are not discarded, they get printed too. A human can read and play the scribbles assuming your handwriting is legible. The only thing StaffPad cannot do is play the notes because the meaning of the unrecognized strokes is a mystery to the application.
This is good, but StaffPad takes it a step further. Sometimes the user wants to express something that can not be codified in the domain model. Western musical notation has a huge amount of symbols and it is not feasible to implement all of them in an application. StaffPad has a clever way around this problem: an extra layer (think Photoshop layers) on top of the notation where you can draw whatever you like. A scribble layer. You can jot down obscure electric guitar performance symbols or draw a picture of your favorite game character. The layer is domain-aware – it intelligently attaches to bars, and is formatted into each musicians parts on printouts.
Is this idea of a separate unstructured layer placed on top of the model presentation useful in other applications? I sure would like to annotate source code with small drawings in my IDE and have them follow the source anywhere it goes. Do you know applications that implement a similar idea?
- Sysart Hotspot
- Do you trust your domain objects? (M.Oikarinen, D.Wellner)
- Jimmy Nilsson / Applying Domain-Driven Design and Patterns
This is part two in the adventure where I’m experimenting with using my DAW on a tablet with only a touch interface. See here for part one: Samplitude on a tablet – part I
I believe I have found the most productive combination of toolbar buttons. I have also updated the Thinkpad tablet to Windows 10 and everything still works smoothly.
This is the set of toolbar buttons I settled on. These actions are optimized for recording and arranging song ideas, not mixing. There are 18 buttons:
- toggle drawmode – shows/hides track control panes
- show/hide track editor – edit a single tracks properties, access to plugins
- show/hide mixer
- group objects
- ungroup objects
- toggle snap
- split object
- remove range
- lock all audio – Prevents accidental moving of objects. With a keyboard I use shortcuts to toggle the Lock/Unlock state of individual objects. With touch it is easier to have a single global lock.
- cut – Normally I ctrl+drag objects to copy them but cut/copy/paste works better with touch.
- toggle metronome
The Windows task bar is back at the bottom of the screen and hidden. Swiping up from the bottom shows the task bar and gives access to the touch keyboard.
If you use multiple time signatures like I often do, I recommend setting the project time signature to 1/4 or 1/8 and NOT adding any signature changes. This makes it easier to move song sections and parts around.
Samplitude Pro X2 was recently on sale for a ridiculously low price so I decided to grab a second copy. My studio DAW has Samplitude tied to a dongle for historical reasons so it was nice to get a dongle-free license for mobile use.
So… I’m wondering if Samplitude would be usable on a Windows tablet? I don’t like using a computer for songwriting and demoing, there is enough mousing and typing during the day already. Could a tablet provide a more organic and fun experience somewhat like a 4-track cassette portastudio back in the day?
Inspired by surfaceproaudio.com I decided to try it. I’ve installed Samplitude Pro X2 and ASIO4ALL on a Thinkpad Helix tablet and I’m in the middle of figuring out the workflow and settings that make this possible. Touch only – no keyboard and no mouse! This is a work in progress but so far things look very promising!
To maximize the space for manipulating audio, I have removed all the visual elements that are not absolutely essential. The Windows 8.1 task bar I’ve moved to the left side of the screen to free some vertical space. The onscreen keyboard is accessible from the task bar all the time. Naming tracks and saving files still requires some typing. I’m trying to fit the frequently used actions on a single toolbar so I’ve removed the toolbar at the bottom. Samplitude has a Big Toolbar option which makes the icons just the right size for touch.
The toolbars can be customized to contain exactly the buttons you need. There is a default palette of commonly used toolbar actions. In addition, any action that can be found in the menus can be added to the toolbar with the custom button. This kind of customization is essential for usability in any software.
The arrangement (VIP) window supports touch gestures. I can scroll the timeline, pinch-zoom, marquee-select objects, select a range, move the play cursor – all without buttons.
There are some essential actions still missing from my toolbar. I can select and split objects but have no way to delete or mute them… doh! I guess I’ll remove the zoom and navigation buttons to make room for those.
We were freshly into production with this system that had a lot of moving parts. The whole system consisted of several big monolithic applications and half a dozen newer microservice-style services integrated into a “living organism”.
A user was not getting the results she expected. We investigated the problem and found out that a service we were calling was not returning some of the data we were interested in. In particular, data older than three months was not seen by us. A support person for the service said: ‘you should use wide search if you want to see the older items’. But wait – we were using wide search, always had been!
I double-checked the code and sure enough, it did say widesearch=”true”. Strange. So I blew the dust off the API spec and found this: widesearch=”1|0”. Yikes, the value should be a number! And I had coded this, totally my bad. I guess I’ve grown too used to using true and false for boolean values in XML. We were a month into production when we found out we were not using wide search. Never had been!
Why did we not get an error when we called the service with bad parameters? 1 and 0 look like numbers to me, but the service had been happily accepting the string “true” all along. I decided to run a little experiment against the service in the test environment:
<request key="..." widesearch=”anything goes?” /> → <response>OK ...valid search results...</response>.
Okay, so it seems there is no validation of the parameter whatsoever. The code probably reads something like this:
Why did we not find this bug during testing? This integration point was hammered a lot because during the project there were a lot of version updates on both sides of the API fence. Before going into production, the integration was in use for at least half a year in the testing environment. Somehow we just managed to not hit the three-month limit. For us ‘widesearch’ was just a mandatory constant we had to set in the API, not a thing that would be interesting to test.
Now, imagine that the service actually checked that the parameters in the API call have correct data types. We would have found our bug on day one of testing. Actually earlier – the first time we tried to call the test service. Silently choosing a default when the input is garbage does a big disservice to making the whole system robust.
When computers talk to computers it is better to be strict in the protocol. Problems get flushed out way quicker.
In his excellent talk on DDD & Microservices Eric Evans had a slide that said “Not all of a large system will be well designed”. Yes, that does match my experience with software systems very well. However, I originally misread the sentence as “Not all large systems will be designed”. I think the misread version sounds true too. I can certainly state with confidence that “not all large systems were designed”. That is because they just happened 🙂