There's a working group that just started up called the Thin Server Architecture Working Group (ok, it's just three folks that are getting together to discuss things, but it's a start). It looks like it's going to be a higher level discussion than related W3C activities (which are more focused on standards discussions). InfoQ has a good one page summary of what's out there for the working group today (which isn't much).

Here's my issue though... my current role is all about the delivery of a Rich Internet Application (RIA), and I have some fundamental issues with the standards and implementations today:

Storage of the "View" - The Thin Server Architecture Working Group is all about the idea of pushing the interface logic to the client. That's very good... but something needs to provide that logic to the client (hint: the server). They need to be sure to consider that part of the architectural models in their work.

Current Client Rendering Performance - HTML clients have some serious performance limitations today. DOM manipulation seems to have been considered a secondary performance goal until recently. Flash and Silverlight are certainly able to handle the visual aspects of the presentation effeciently, and they both offer opportunities for fairly effecient display logic to be imbedded, but I'd like to see the browsers step up their DOM handling efforts.

Developer Optimization - I know that many, many developers and architects look at the MVC model as being superior to the "everything in one block of code" model (I made that one up, but you know what I mean). That's absolutely true, but one belefit of the "everything in one block of code" model is initial development (not maintenance development) can be performed as a stream of thought. Because of this, many younger or less experienced developers will start to learn some very bad habits as soon as they start coding for the web. Tools for RIA development need to help with the seperation of logic layers (not necessarily the MVC model), and at the same time feel natural to code.

Standards and working groups are very important, but the most important part of any architecture, specification or design pattern is how they get implemented in the real world.

Labels: ajax, design patterns, process, web 2.0

AT&T has decided to take on a browser project called Pogo. Take a look at the demo over on the pogo site, and you can seen an interview with AT&T's David Grantz that Rob Scoble recorded. Rob's posting talks about AT&T entering the browser wars, but, according to TechCrunch, it's really based on Mozilla.

Erick, over at TechCrunch has a pretty good review, but one thing that he doesn't mention is the similarity to the visualizations in Windows Vista. I'm in agreement with Erick, it looks pretty... but why do I need that over my current interface. Again, do we really need another Mozilla flavored browser?

Labels: browsers, user interface

Back in August, we bought an old house in West Philly. Our best guess is that the house was constructed sometime between 1910 and 1915. It's a great old house, but has been abused over its life. While I'm sure that the original occupants were quite caring for the building, it seems like there has been a whole line of owners that did things "just good enough" to suit their needs. Over the years, that's become the biggest issue for us to deal with.

The house is three stories, with a basement and an attic. Since there's only two of us in the house (not counting the two cats), we think we have plenty of room to move around as we work.

Our first "full" renovation is the second floor middle bedroom. While the demolition work has been in progress for a few months now, I took two solid days this weekend to complete the “gut job” of the room.

You can see some great shots of the work here: Home Improvement Photos on Flickr
 

"Remodeled" rooms aren't always what they seem.

I thought that some special attention was worth while for this photo. A recent remodel of the bathroom led to some interesting results. As you can see in the photo, the new ceiling of the bathroom is attached to a new framing structure that sits about a foot and a half below the original ceiling. I guess it would make sense if you needed a cavity for electrical, mechanical or plumbing access, but it looks like it was just done that way in an attempt to be lazy. They set the new framing up about 8 feet from the floor, which you would expect to make the drywall process easier. The problem is that they didn't bother leveling the new ceiling, so it's visibly uneven from the inside of the bathroom. Even better? The work they did to make the drywall installation easier was negated by the fact that it wasn't leveled... they had to cut drywall to fit into a gap between the top of the 8 foot boards and the ceiling board.

I know there's going to be a ton of interesting decisions to laugh at as we go through the house, but this one may survive to be in the top 10.

Labels: personal