Home
saw two posts today that encouraged me greatly. both posts put forward ways to build a reliable, HTTP-compliant distributed authentication pattern that works for both humans and non-humans alike.
foaf+ssl: a first implementation contains a functioning example of how to combine FOAF and SSL into a working distributed authentication pattern. kinda complicated right now, but interesting.
reports on emerging efforts to riase OAuth to a working group within IETF in order to raise it to a general use pattern. this has some interesting possibilities, too.
both cases offer ways to make third-party authentication safe, reliable, and - hopefully - common. and that's a good thing.
this post is not a bad read. i'm not a big fan of Django, but that's not really the issue here. instead, Jacob Kaplan-Moss details some advice vis-a-vis implementing REST by way of pointing out common 'bad practice.' i recognize most all of them from my own code at one time or another. how about you?
The basic mechanisms shown here form the conceptual foundation of caching in HTTP — not to mention the Cache architectural constraint as defined by REST. There’s more to it, of course: a cache’s behavior can be further constrained with additional Cache-Control directives, and the Vary header narrows a response’s cache suitability based on headers of subsequent requests. For a more thorough look at HTTP caching, I suggest Mark Nottingham’s excellent Caching Tutorial for Web Authors and Webmasters. Paul James’s HTTP Caching is also quite good and bit shorter. And, of course, the relevant sections of RFC 2616 are highly recommended.
i posted a new SDS demo this weekend. it's a small one, but fun.
my focus on this demo was to exercise the features of SDS that make it possible to host binary files. so i built a site that hosts about 200 photos (plus another 400 thumbnail and preview files). it also holds javascript, stylesheets, and source code files for online use. all pretty cool - and simple.
one of my goals was to reduce the number of files that must be hosted locally (with my own web server). to that end, the only files hosted locally for this demo are an XSLT file, a C# DLL and the web.config file. so all the images, scripts, stylsheets, and even view-able source code files are all in SDS. and i kinda like it that way. it's easy to update the files to SDS and then call them directly from my web app.
in fact, hosting these files on the web makes it really easy to test out a version of the web server on my local workstation, too. i can rebuild my DLL and/or modify my XSL transform and then run it right there. it can reach SDS to pull the rest of the files just fine. once debugging is done, i upgrade the production box by copying just the DLL and XSLT file. really simple. really fast.
next i'll concentrate on the second reason i built the demo - to show that using an anonymous proxy in front of SDS authenticated servers does not automatically mean you get slow performance. even in cases where the app does mostly binary file services (like this photo demo). and it worked out pretty well on that front, too. but that will have to wait for another post.
after spending quite a bit of time poking around w/ cool new stuff, i'm now about to refocus on a personal project i started about a year ago - exyus. like much of my work, it's aimed at building REST-compliant web applications that scale well.
i've been using this codebase to build a handful of personal projects and test apps. all doing pretty well. however, as i get back into the framework code behind the system, i am struck by how many lines of code there are. esp. since i was quite proud several months ago that i cut out so much code! yeah, it's all relative. and i can see i have some more work to do.
lucky for me, i have a couple folks who will 'assist' me in my work: and . technically, they don't know me - i just have the latest edition of their book: Framework Design Guidelines. and it's a good book, too. so, while i pour over the text, i keep jumping back into my code the check, re-check and modify. hopefully, this will be done by the end of the year. if that happens, i suspect i'll have a pretty solid framework for building REST-like apps.
so i have more work to do. so i can end up w/ less code. and build better apps.