Ionrock Dot Org

Last night in going through some Atom Publishing Protocol code, there was a discussion regarding whether or not the base URL could change when an entry is created. The bigger issue though was my misunderstanding of the RFC terminology. I thought SHOULD meant, "it probably should have this detail, but it is not required." What it really means is that, "it should have this detail in order to comply with this spec!" This means I have some work to do.

In Bright Content more and more functionality uses the WSGI interface, which means almost anything built in Bright Content should be usable in other WSGI applications. This is really the promise of middleware, a application anyone else can use. I know there are cases where middleware will be cooking data and passing along some application specific environ variables, but the vast majority of the time implementing small functional pieces as middleware makes a ton of sense due to the reuse.

The other great thing about middleware is it can pass off responding to the request to the next piece of middleware. It is rare that a no-op type action is that beneficial, but in this case it means that the one request can be used by many different middleware applications to get things done. For example, in the Atom Publishing Protocol, you could make a bit of middleware that sits before the APP middleware and updates indexes when a PUT, POST or DELETE request is made. You could then make a validation piece of middleware as well to check that the entries getting added to the APP implementation store are valid and correct. In a general sense, any application can be extended because every application uses the WSGI interface.

I am probably a little late in the game realizing the benefits of this model. This doesn't bother me except for the fact that I haven't been programming functionally longer. I realize as well that it allows design patterns seen in XSL, which might be another reason I like it.