Time for a new Notes/ Domino support model

I’m pretty happy with FP10: great that with we now have up-to-date Eclipse/ Java/ OSGi version. Despite some obvious glitches it works reasonably well for me. But if you read the blogs and follow Twitter: a lot of people are having issues. The current ‘gold’ version would have been a great beta (2) and with a couple of fixes a great release.

I can confirm that I also have most of the issues described in this blog post (and more). I also can/ really want to elaborate on them by providing more info/ screenshots just to make FP10 better.

​But… although I appreciate IBM (ArnazR) asking for more info in one of the more recent comments I don’t think that is the place. I also support software and absolutely hate it when people introduces new issues in a comments section.

​Creating PMR’s is way too much overhead. It is mentioned that a PMR exists for most issues. Can I simply add more info with just a line of text? Add a screenshot in under a minute? I don’t think so. Since I’m a consultant/ business partner and not a customer, I can’t even create PMR’s (seriously?). Don’t want to bother one of my customers for it neither.

Wouldn’t it be great if we had a simple way to log the issue we’re having with FP10? Just have a look at the Github issues section for inspiration. ​The delivery model for Notes/ Domino has changed in light of what the rest of the world is doing. I think it’s time the support model follows.

PS. For ArnazR: have a look at the screenshot. I would also say that this help screen looks ‘curious’).

Fun with Domino, AngularJS and CORS (not really)

For a mobile app I’m currently working on (more on that soon) I’m using Domino Access Services. After fixing the issue with the number of entries returned by a view entry service, I quickly ran into other issues.

I’m using a frontend build with Angular that’s running on a different domain name. So I have to add CORS headers (Cross Origin Resource Sharing). That’s easy: create a response document for the Internet Site in the Domino Directory and add an Access-Control-Allow-Origin header with a value of *. That worked Ok. For GET requests.

If you try to make a POST request, the default CORS behavior is to do a so called preflight request (before it sends the POST) in which the browser asks the target server what options it supports. It does this by sending an OPTIONS request. And that failed.

I first checked in the internet site if the OPTIONS method is allowed at all (tab ‘Configuration’ -> ‘Allowed methods’). It was, but I got an error that the Access-Control-Allow-Origin header wasn’t present, so I wasn’t allowed to make the request. That should have been taken care of by the website rule I created. Luckily I found a comment from Mark Barton here: turns out that the HTTP response code for OPTION calls is 204. If you think hard you might remember that you need to set response codes in the web site rule. In mine that only had 200 (Ok) and 206 (Partial Content) in it. I added 204 and… the OPTION request came through. I then ran into the next issue.

According to this the Content-Type request header is required for a POST request and needs to be set to ‘application/json‘. If you want to do that cross domain, the target server needs to allow you to set it. So I had to add another CORS header to the internet site: Access-Control-Allow-Headers: Content-Type.

All set now? Almost… When a new document is created, it responds with a 201 response code so I needed to add that to the internet site rule too.

And finally (for this part): the 201 response is sent without any content: it returns a response header named ‘Location’ that contains the location of the newly created document. Its value looks like this: http:///.nsf/api/data/documents/unid/.

To be able to read that I needed to add an argument to my success callback function (‘headers’) and use a call to headers(‘Location’) to read that header. Correct, but… remember that we’re working on different domains? By default response headers aren’t exposed to the originating domain, so here goes another response header in the web site rule: Access-Control-Expose-Headers: Location.

Can’t wait to see what CORS issues I’ll run into next (and I’m running out of web site rule response headers 🙁 – wonder if there’s a hack for that without installing a proxy and keep using the standard DAS).

This is what my website rule now looks like:


Debugging and designing at the BLUG 2013

I got back yesterday from an excellent 2 days in Leuven where I spoke at the BLUG 2013 (where the B as of this year stands for BeNeLux). This was actually my first visit to the event and I enjoyed every bit of it. The location was impressive: the “Grand Béguinage of Leuven“, a former community for unmarried, semi-religious women (the Béguine), dates back to the 13th century and is on the UNESCO World Heritage list.


Theo Heselmans did an amazing job in organizing the event and spoiled us with lots of Belgian chocolate. The attendance was again higher than last year and I heard that the BLUG is now the worlds largest LUG.


I did 2 sessions at the event: one semi-non-technical on design frameworks together with Martin Vereecken, Matt White and Mark Myers. Read the slides if you want to know how that relates to the missionary position 🙂

I did a second session on my own titled “Stop (de)bugging me!”. It was the last session of the event but still very well attended. I talked about the (SSJS and Java) debuggers in Notes 9 and my XPage Debug Toolbar.

See you hopefully next year in Breda (but probably sooner)!