updated my food log app

i updated the foodlog app to look/feel similar to the runlog app i updated last week. it now has a slicker public side and a bit smarter editing experience. they bos support html content for the notes section and i'm starting to use things like anchors and image tags to spruce up the content - looking nice.



i want to run it a bit longer here on my workstation iis edition before packing it up for the public server. but i suspect the public server will happen before the end of the month. 



in the meantime, i am starting to plan out a simple blog app. the first pass will have entries and categories. i'm considering a blog roll and comments, but i might use an available service for those (get to test my ajax/rss chops!).  anyway, the app will be a bit more complex than the 'log' apps i'm using today. just the right step up in my process for building rest-ian apps.



on another front, i've stopped working on the http auth side of things. while basic-auth is working, i have no ssl cert to guard my transactions. i also haven't implemented digest auth. that is probably what i should focus on next. i also want to tighten up the session and cookie services baked into the framework. finally, the user accounts and url auth data is currently stored in xml files. that will need to be moved to a db relatively soon, too.



it's looking good and solid - i like it!

moved exyus runtime to root folder

made another big step today in rolling out a working version of exyus - moving it to the root folder of a server.



actually, a sub folder. but the point is that the app no longer runs under the asp.net debug server. i implemented some isap rewrite rules, modified the xsl and scripts and now all runs fine as a standard iis-hosted app. it's all about the configs now.



i tweaked my running log app to use a bit of javascript (running.js) and a clean css file (running.css). i need to do the same with the food log app. once that's done, both apps will be fully functional and stand-alone.



next, i need to package up the two apps and post them to my public-facing server that uses sql server (not the express flavor i have here).  at that point, the release will be complete - a fully functional rest-ian lightweight web framework.



once the thing is hosted publicly, i just need to start designing and implementing other rest-ian web apps. my next target - a blog app. then i can test my rss/atom output skills, too!

implemented a new 'app' in about two hours

had a good time this weekend. i implemented a second simple http/rest web app in about two hours. this time, instead of my jogging log, i created a simple weight loss log.  while it was really  simple (just one table with a handful of inputs) it was important to me to create a new app from scratch to test out the rest-server pattern io've been working on for the last month or so.



and it went well. i did do a lot of copy and paste (one reason it went so fast). that means i might be able to factor in some of the copy-paste into the base class. but i want to make sure not to 'over-engineer' things. i implemented the xml data uri, then a simple xhtml list/detail pattern for public viewing. setting up the security was a bit tricky at first (forgot some of my details for setting up secure urls and granting user permissions), but it fell into place once i dusted of the ideas. currently the security is all done via XML files, but i can see how doing this in a db would make things smoother.



finally, i also updated the running app by cleaning up the uri pattern and refreshing the public pages. it took tiny bit of work to update the XSLT and a bit of trundling the javascript client code. but it's all good.



i'm having some fun here. my next target? posting all this stuff to a public server instead of just on my workstation.

side track into client ui

i've been spending the last several days (at work) putting together some web 2.0 ui pages. this is focus on a POX (plain old xml) back end and ajax-inated javascript browser front end.  been kind fun, actually.



in the process, i've decided to build a small (but useful) DOM-friendly collection of ui components. i'm focusing on the following:

- tree control

- table (sort-able, filter-able, page-able)

- tabs

- menu (fly out and drop-down)

- modal dialog

- collapser (toggle page sections open/closed)

- auto-suggest (ala google, et al)



i also want to settle on a calendar and dhtml editor, but have not found anything i like yet.



also, i've worked up a basic 'behind-the-scenes' set of javascript libraries to make my life easier:

- dom helper (base from dean edwards)

- mozxpath (nice cross-browser xpath against xml docs)

- ajax library (built on the one from ajax patterns wiki)

- data library (found a decent one i need to work on)



so that's a nice set to starat with, eh?



so far, i've done enough work with the ajax, and mozxpath to know they work great. i like dean edward's base2, but it's a bit early to tell if this will last.



i also posted a clean modal dialog and auto-suggest set in my googlecode space.  i plan on posting the other parts as they get exercised (or exorcised, as the case may be<g>).



fwiw, i still have work to do on the server-side rest library. but that might wait a week or so as i get through this client stuff.

wrapping up http caching

after pouring over the http 1.1 docs and a number of other articles and books, i'm pretty sure i have the basic caching pattern down:



PUBLIC CACHING

to reduce traffic, use expiration caching (expires for 1.0 and cache-control for 1.1) to tell public caches to serve requests without talking to the origin server.



to reduce bandwidth, use validation caching (last-modified for 1.0 and etags for 1.1) to tell public caches to use conditional gets to the origin server who can return a 304 instead of returning a full copy of the resource.



so this is all cool. i have this built into the ws-loop now. if you are doing a GET and the class generating the resource has max-age, etags, and/or last-modified set, caching headers will be sent with the response. and whenever a class is handling a GET, it will check for if-not-modified and if-none-match and return 304 if the resource has not changed.



LOCAL CACHING

so that's the public side of things. under the hood, the ws-loop is creating a local copy (on disk) of the requested resource and using that to serve up to clients as long as the file-date is not stale (based on max-age).  so, while the class still has to respond (no direct file delivery here), it will still deliver a disk copy of the resource for as long as it is directed. that's cool.



GZIP/DEFLATE

now the only other item that could be intersting would be gzip and deflate.  i need to look into how to implement that for dynamic resources (when supported) using the .net 2.0 compression classes.



CLEAN-UP

once that's done, i have some housekeeping to do with the ws-loop. cleaning up naming, some constants, implementing the ws-loop at the server root using isapi rewriter, etc.



once the clean up is done, some other niceties like moving the user/auth work into the db instead of xml and maybe making caching an external config insteado code work would be good. then it's back to building REST-ian apps in general.

implemented basic caching for the rest server tonight

after adding a simple write-to-file routine for the GETs in my REST server, i also implemented support for ETag, Last-Modified, and Cache-Control max-age headers.



now, when a resource is generated, if the max-age is over zero, the results are written to disk and caching headers (etag, last-modified, and max-age) are written to the client.



in addition, when a GET is received at the server, the routine can check for If-None-Match (for etags) and Use-If-Not-Modified (for last-modified) request headers and, if possible simply return 304 instead of regenerating the request.



none of this is marked public yet. i still want to work on some details of the cache-control header including things like must revalidate, freshness, and no-cache directives for cookie-d requests, etc.



still, the server is getting more robust and generating cache-able content. and that's good!

beat a perf challenge today

last night i added support for xhtml strict doctypes in my html outputs from the rest server project. i immediately saw a serious perf cost to doing this - wow!  it bugged me all night long and it was only this am when i finally had the time to work through the problem.



turns out that the cost is not in the transforming of the xml into xthml via xsl where the cost was - it was in reconstituting the output of my transformation from a string pile back into a new xml document (long story on all that...).



anyway, since i need to output the final product (xml, string, strong object type) as a serialized string pile to the browser, i just added some smarts to the base class that handles the http response to all for more than just an xml document or C# type. now it handles a string pile, too.



*big* improvement! now i know i'm able to generate strict xhtml and i still have solid performance.



next for me is to implement a local caching pattern that allows for support of public caching servers. it's all about the GET this weekend!