Before I attempt to put my own spin on what and why you would use REST; If you are interested at all on Software Architecture, then I highly recommend that you take the time to read Roy’s dissertation – maybe even twice. It is a tour-de-force of what Software Architecture is. And if you feel really brave read Rohit’s companion dissertation.

Why base your software architecture on REST?

The high-level answer: When you don’t “own” each component along the wire it is important that each component be allowed to evolve independently. What matters in this context is the ability to work with components at different levels of implementation. That means constraining the interface to a commonly agreed standard so every component along the wire can understand what it means to GET, PUT, POST, DELETE etc.

Secondly no matter how fast the wire becomes we are still constrained by the speed of light i.e. there will always be latency. To combat this you end up using a course grained Document-Centric mode of interaction – sending HTML/XML/JSON documents etc – instead of a fine grained Control-Centric mode. The latter is RPC the former REST.

To make sure that each component knows what is being talked about it needs to be identified. Hence URIs identify a Resource. Response meta-data describes the context of the document that was returned. [in REST terms the context of the Representation returned.]

A Resource can be thought of as an object that implements various interfaces. It is a concept, a notional software component that implements many interfaces. In REST those interfaces are identified by URIs.

Without constrained interfaces, a data-centric mode of interaction and identity, caches won’t work for example. This also means that Hypertext now becomes the engine of application state. Every component interface implements a state machine regardless of the underlining component technology, hence in REST URI become a way of making the application state explicit. Tim Ewald framed it nicely:

“The essence of REST is to make the states of the protocol explicit and addressible by URIs. The current state of the protocol state machine is represented by the URI you just operated on and the state representation you retrieved. You change state by operating on the URI of the state you’re moving to, making that your new state. A state’s representation includes the links (arcs in the graph) to the other states that you can move to from the current state. This is exactly how browser based apps work, and there is no reason that your app’s protocol can’t work that way too. (The ATOM Publishing protocol is the canonical example, though its easy to think that its about entities, not a state machine.)”

RPC (and therefore SOAP) rely on tool support to be vaguely usable. REST works because humans can do a wget and see what comes back. That reduces the coordination costs of building systems.

If you control all the components in the chain and you release them all at the same time and there is no latency issue to worry about, use a RPC style of interaction. Otherwise use REST. In today’s Web2.0 climate that means using a REST style, as a minimum, for externally exposed Resources via APIs.

An Architectural Style

REST is an Architectural Style in the true sense of Alexander’s patterns, compared to, the more prescriptive approach adopted by the Design Patterns movement, lead by the Gang of Four. SOAP is a XML language for specifying and constructing messages for a network protocol. The typical message exchange pattern is modelled after the RPC style. So just to confuse the matter SOAP can be compared more directly to HTTP; the latter being a Network API that attempts to conform to the REST style.

If REST is to be compared then it should be compared to RPC or SOA. Both are approaches to software architecture. SOAP is an implementation that can be used in either a Control-centric (RPC/SOA) style or a Document-centric (REST) style. It just happens than most uses of SOAP are RPCs.

“Dojo Offline is a free, open source toolkit that makes it easy for web applications to work offline. It consists of two pieces: a JavaScript library bundled with your web page and a small (~300K) cross-platform, cross-browser download that helps to cache your web application’s user-interface for use offline.”

The 300K download is actually a locally installed web proxy that makes the detection, caching and online/offline transitions seemless. Part of the approach is to define a framework for handling the connectivity so that it is as easy and transparently from an end-users’ perspective. This includes a Dojo UI Widget that detects the presences of the Offline Proxy, prompting the user to download and install it. Being only 300K makes this a very quick process. If the proxy is installed then the widget will indicate the “connected” status.

This checking of connectivity goes beyond local network connectivity, by sending pings out across the Internet, it actually determines if Internet connectivity is present. This avoids the trap of being locally connected but globally disconnected.

From a implementation perspective the local proxy will cache all those files (XHTML, CSS, Javascript) to ensure that the Web application will still operate even if started offline. Once online the Sync component of the toolkit kicks in, performing a transparent merge operation with the back-end. The reason it is transparent is to avoid confusing the user. Instead the approach is to perform the sync transparently but let the user view the audit log of what happened if they wish too. Most won’t.

The Offline toolkit extends the Dojo offline storage engine. A portable, browser and OS, storage engine. Basically if you are using Firefox 2.x, then the storage engine uses Firefox’s offline storage capability, otherwise it uses Flash as the storage engine. This functionality has been in Dojo for sometime, so is well baked.

At the Web 2.0 Expo, Brad Neuberg (the developer) gave a presentation on the Offline Toolkit; watch is his presentation for more details.

Having the capability to build web applications that are “connectivity” aware is a big boost to the acceptance of web applications. Ubiquitous connectivity is still a dream. The thing is that the way Web applications are designed and developed changes as a result. The MVC structure of your typical Web application now needs to push the entire MVC structure into the Javascript. Rock on PAC! Dojo is well suited for this architecture as it includes many features for neatly structuring the Javascript application and deploying just what is needed and it can incorporate Comet.

The general approach at the application layer can be summed up as: Partition your database around some key object in the system, typically a user. Replicate these partitions around your various database servers. Deploy your front-end on a web-farm and potentially factor out some application functionality to dedicated servers. Manage sessions separately either by creating a discrete service within the architecture or by resolving sessions to a particular database partition – basically push state down to a data-store where the application coordination happens. Then cache whatever you can. That’s it – well the devil is in the details.

Don MacAskill’s presentation at ETech07 details SmugMug’s architecture using Amazon’s S3 and experiments with EC2 and SQS. It contains a great lot of information about using Amazon’s Web Services. The utility model – or compute power on demand – of deploying services will become very prevalent over the next few years. While Amazon are the first movers, others will follow with potentially more powerful computing models.

All good. Basically they are all large grained approaches to leveraging concurrent execution using lots of boxes. Application design is just chopped up into a few tiers. It is easy to understand and at this point we can happily forget about concurrency because each component in the system is a big black box with synchronous calls between them.

Several things are happening that suggest our sequential synchronous existence may be over. Power consumption, Multi-core cpu’s, on-demand scaling as exemplified by Amazon’s EC2 service, transaction reliability and the rise of data mining; All make confronting scaling issues early on important for your application architecture.

The situation for CPU design and the implications for software design was clearly discussed, back in 2005, in a Dr Dobbs article by Herb Sutter. The Free Lunch is Over: A Fundamental Turn Towards Concurrency in Software. In the article Herb discusses the limitations of chip design and why this will lead to a focus on multi core design rather than increasing clock cycles on a single core. A key barrier to increasing the clock speed is power consumption. Heat is a by product of power consumption so power consumption isn’t related just to the operation of a machine but the cooling required to keep it operating. Power consumption is a major issue for Google and any company that runs data centers. Even my little server room at home should have air conditioning during the summer months! Server power consumption is one of the motivations given as justification for O’Reilly Media’s conference on energy innovation later this year.

While two or four core cpu architectures are now mainstream we are seeing an increase in the number of cores. An example demostrated recently is Intel’s 80-core research chip crunches 1 Tflop at 3.2 GHz

“Intel’s 80-core chip is basically a mainframe-on-a-chip-literally,” said McGregor. “It’s the equivalent of 80 blade processors plugged into a high-speed backplane, or 80 separate computers using a high-speed hardware interconnect.”

I suspect that given Moore’s Law we can expect some associated Law regarding the number of cores on a square inch wafer increasing exponentially over the coming years. No doubt there will be some correlation to Peak Oil issues and increasing awareness of Global Warming as the market impetus for more cores. If approaches to concurrency in software are any indication, I can easily imagine clock speeds decreasing. Chip designers would focus on throughput rather than outright performance. This would suggest the rise of commercial asynchronous chip designs. [Maybe they are already - I know nothing about current chip designs beyond their multi-coreness.] It would also fit with Clayton Christensen’s “law of conservation of modularity“.

Current software development techniques can only hide so much. Eventually we will need to utilise the multiple cores to maximise the benefit they provide. Multi-threading is notoriously difficult to do correctly so I don’t see that as a solution. Asynchronous event or message passing approaches provide a better way. Basically they model how hardware works and micro-kernel operating systems have been modelled in a similar fashion.

We have being doing this application composition stuff with messages for a while now (albeit synchronous in nature) with Unix pipes and the Web but these architectures are only just beginning to be appreciated beyond administration script-based coordination Unix pipes have been traditionally used for.

Google have raised awareness and appreciation with publication on internal toolkits like MapReduce, Chubby and BigTable.

One thing that surprises me about various presentations around scaling web applications is the lack of mention about message passing, specifically message queues or event buses. These are the staple tools when you want to scale and ensure data doesn’t get lost. Then again many of the consumer oriented services don’t need such reliability. The cost of losing a customers IM message, or comment post, or uploading of an image is minimal. An annoyance at worst. As web applications evolve into business applications losing data, due to scale demands, has real costs.

Web 1.0 – Centralised Them.
Web 2.0 – Distributed Us.
Web 3.0 – Decentralised Me

Hindsight: Web 1.0 turned into a broadcast medium. It was all about them. A case of industrial age thinking applied to a new landscape. Web 2.0, largely based on an analysis of what worked in Web1.0, is an alignment with TBL’s initial vision of the Web. The Web as connective tissue between us. Platform, participation and conversation. Really it is more than the Web. It is the Internet. It is new practices too. Ultimately it is about connectivity; applying constrains in the form of some sort-of agreed upon standards that make it easier to talk to one another. With new layers of connective wealth come new tools. In Web2.0’s case that allowed new forms of communication. With it associated ‘acceptable’ business models – hence the Google economy.

Web 1.0 was the first time to show the value of standards, Web 2.0 is teaching us how liberating standards can be. Web 3.0 will reflect on what worked in Web2.0. It will mean more constraints for better communication/connectivity. Improved connectivity will mean revised practice and new business models.

Therefore Web 3.0 must be about me! It’s about me when I don’t want to participate in the world. It’s about me when I want to have more control of my environment particularly who I let in. When my attention is stretched who/what do I pay attention to and who do I let pay attention to me. It is more effective communication for me!

When it is about me it means Web 3.0 must be about more semantics in information, but not just anything. Better communication comes from constraints in the vocabularies we use. Micro formats will lead here helping us to understand RDF and the Semantic Web. With more concern over my attention comes a need to manage the flow of information. This is about pushing and pulling information into a flow that accounts for time and context. Market based reputation models applied to information flows become important. Quality of Service (QOS) at the application and economic layer where agents monitor, discover, filter and direct flows on information for me to the devices and front-ends that I use. The very notion of application [Application is a very stand-alone PC world-view. Forget the Web, Desktop, Offline/Online arguments] disappears into a notion of components linked by information flows. Atom, the Atom API and semantics, particularly Micro formats initially, are the constraints that will make this happen. Atom features not because of technical merit but by virtue of it’s existing market deployment in a space that most EAI players won’t even consider a market opportunity. Hence Web based components start using Atom API as the dominate Web API – Feed remixing is indicative. Atom will supplant WS* SOA.

User centric identity takes hold. This extends the idea that everyone has an email address and mobile number, why not manage it for single sign-on and more. Universal Address-book anyone?

More Market based brokerage business models emerge, earning revenue on the ‘turn’, as we learn more about the true power of AdSense/Adword’s underling business model and realise there are close parallels to the worlds financial markets.

Reliable vocabularies, user identity and trusted [i.e. user controllable] reputation models, market based brokerage business models all become a necessity as the more decentralized event driven web becomes a reality.

Web 3.0 – a decentralized asynchronous me.

There were a few things I forgot to put into the above definition and from the comments a few things that need explanation. I’ll attempt to expand on the above in latter posts as I’m a little stuck for time.

What I left off is the relationship to the physical world; “the Internet of Things” with 2D Bar Codes, RFID etc. and Just-in-time just-about-one-to-one manufacturing that is partly represented by what Threadless and others are doing. I’ll also need to clarify what I mean by Them, Us, Me. And why Web 3.0 cannot be classified as “Read / Write / Execute.”

Some comments past on to me ask how is this different from what Web2.0 is about? At a technology level it really isn’t, the technology is already here. From a cultural and hence practice level it is. As we starting seeing more value in using things like Atom, Meta-Data, Open-Data and feed remixing etc, then how we use the Internet and our connected devices will change. That is what, at the core, is the basis of Web2.0 – changing usage and practice.

From a podcast with Jon Udell, Roy describes Waka thus.

Waka is a binary token based replacement protocol for HTTP. The goal is to create a language independent mechanism for exchanging data oriented messages using the ReST architectural style – the principals and design.

An application protocol that is efficient as any custom protocol yet generally applicable like HTTP. The difference is that we get rid of HTTP syntax, make it possible to interleave meta-data and data in independent streams/frames. Doing this in a way that is efficient as possible without being entirely generic i.e. Waka is not attempting to replace TCP. This means Waka would be suitable to application integration inside the firewall and well as outside.

Why name it Waka? Waka is the Aotearoa (New Zealand) Māori name for Canoe still used for ceremonial purposes. It is one of the few four-letter words suitable for a protocol name. And Roy is part Māori.

From the last substantial presentation Roy gave about Waka the following can be gleaned.

Deployment

Deployable within an HTTP connection via the HTTP/1.1 Upgrade header field with a defined mapping to HTTP/1.1 proxies.

Syntax

A uniform syntax regardless of the message type and direction that also allows for padding for 32/64 bit alignment. There is a discussion in Chapter 6 of Roy’s dissertation covering uniform syntax and numerous discussions about the short-comings of layered encodings and MIME.

Messages are self-descriptive using explicit typing for message structure and fields. An indication of mandate and scope of the fields.

Association of meta-data to control, resource and representation. Allows for Premature termination of request or response.

To be more efficient the protocol will use tokens for all standard elements where a URI reference can be used in place of any token. Macros (client-defined syntax short-hand) can be established per connection. Meta-data delivery can be interleaved with data.

New Request Semantics

RENDER: display/print/speak this representation.

MONITOR: set up a subscription to be notified of resource state changes. Notification are sent to a resource specified as part of the request. Another name commonly used for these semantics is WATCH.

Authoring Method: DAV simplified and by that I would assume removal of the DAV property methods. Elimination of non-resource identifiers and reintroduction of PATCH.

Request control data: request identifier to support request pipelining removing the head-of-line bottleneck in HTTP. A Transaction identifier, a URI, meaning transactions can be treated as resources. And relative priority – relative to requests in a connections pipeline.

New Response Semantics

Self-descriptive binding to the request by echoing the request id, method and target URI. This basically enables an asynchronous transport.

Cache key explicitly described; caches no longer need to save request fields or guess about Vary information.

Unsolicited Responses for cache invalidation messages and multicast event notices.

As someone who works on large scale online services for a living, Yahoo! Pipes seems like a scary proposition.

Basically the service is likely to have hit the twin sisters of scaling large systems, CPU and I/O bounds.The nature and flexibility that Yahoo! Pipes provides: User defined queries over changing data streams that are activated every time a pipe is “pulled” will create a heavy load. Dare continues.

It combines providing a service that is known for causing scale issues due to heavy I/O requirements (i.e. serving RSS feeds) with one that is known for scaling issues due to heavy CPU and I/O requirements (i.e. user-defined queries over rapidly changing data). I suspect that this combination of features makes Yahoo! Pipes resistant to popular caching techniques especially if the screenshot below is any indication of the amount of flexibility [and thus processing power required] that is given to users in creating queries.

This has always been an issue if you consider a centralised event routing infrastructure. I suspect it is made worse by the “pull” nature of feeds. Even if if-modified headers or etags are used in the HTTP request. To determine if a user-defined feed has changed it would require processing the whole chain effectively adding a whole lot of processing over head. This is however a naive way of approaching the problem. An internal event architecture and caching are applicable. The caching is just different to the way content caching currently works. However the answer, I suspect, is not to centralise. The general infrastructure represented by Yahoo! Pipes should be deployed by millions. I have my own router for IP traffic so why not have my own router for application data traffic?

]]> http://www.outofrhythm.com/2007/02/09/scaling-yahoo-pipes/feed/ 0 http://www.outofrhythm.com/2007/02/09/yahoo-pipes-a-cloud-based-feed-router/ http://www.outofrhythm.com/2007/02/09/yahoo-pipes-a-cloud-based-feed-router/#comments Thu, 08 Feb 2007 23:26:32 +0000 Robert http://www.outofrhythm.com/2007/02/09/yahoo-pipes-a-cloud-based-feed-router/ Yahoo Pipes was released yesterday (last night NZ Time). What Yahoo Pipes represents is the next stage in using the Web as a platform. That is: RSS and Atom are becoming the connective tissue of the web and web applications the components. This was the basis of my Talk at Kiwi Foo – “Replacing my Wife with Atom.*” I commented I was surprised this [general routing infrastructure for Atom, not the replacement of my Wife] had not been done yet, after all the ideas of routing and remixing feeds have been discussed for a long time in the early history of RSS. Before that if you consider RSS/ATOM and the infrastructure around it as a Universal Event Bus. As Jeremy Zawodny states “For far too long now RSS has been used in ways that don’t really tap its true potential.” Well now Yahoo is making a start in the right direction.

Unfortunately I can’t get in, just getting “Our Pipes are Clogged!” – missed opportunity or what? Well it shows, to some degree that at least, the info junkies want this sort of thing. As a result I can’t really comment too much on the service itself, but I can comment on the underlining ideas – this was after all the motivation for re-entering the blogsphere.

[Tim O'Reilly has a good write-up as does ReadWriteWeb and Anil Dash. While Brady Forrest looks a little closer. ]

The basis of the talk I gave at Kiwi Foo was this:

Atom and the Atom publishing protocol will disrupt the way ‘network’ applications are integrated and become the way Internet scale Pub+Sub and routable applications architectures will evolve…Therefore make your Web API’s atom based to make integration easier – Look Ma no code!

While to some degree the arguments apply to RSS, ATOM [IMHO] has the advantage in the longer term. The arguments are not new. Rohit Khare has been thinking about this stuff for a long time. He gave a talk about SOAP routing at ECON 2002. I just applied similar arguments to ATOM but tried to include the human component – conceptually feeds are more human friendly than SOAP ever will be. That observation then naturally leads into a Disruptive Technology argument w.r.t. EAI. Just take a look at the dabbleDB demo that Avi Bryant put together at FOO last year, or RSSBus for examples. (there are several other examples that I’ll leave for now.)

An observation I attempted to justify was: prior technologies have attempted to implement Internet Scale Pub+Sub but failed not because the technologies weren’t up to it (they may not have been) but that as a broader community we still haven’t grokked what the Web as a platform really means. As a result we haven’t understood what integrating applications beyond the Point-2-Point mashup type actually involves. Oddly enough though we are use to solving these integration issues at the network-level. Just look at the Internet and TCP/IP. The same principles of message (packet) based approaches apply in the Enterprise as any EAI vendor will tell you. ATOM is approaching the EAI issue from the grass-roots up. Unlike SOAP that was top down even though it professed not to be. More importantly for this sort of service composition to really take off Atom and the Web needs a “joe average” programming model.

Yahoo Pipes is a giant leap in that direction for the Web even though we have been programming the Web, for human consumption, for sometime now. Every time you add a feed URL to a feed reader or personalised home page you are connecting disparate web services together, you are programming. Labview has been doing this sort of thing for a long time. Lego RoboLab and the Lego Robotics programming environment, Microsoft Robotics Studio Visual programming are other great examples. Ben Goodger recently pointed me to another example on OSX, Automator.

Does this mean the programming model for the Web platform is a visual wiring diagram. Why not? Nor does it have to be provided as a cloud based service like Pipes. Since Pipes produces feeds these can then be glued to an instance of Pipes (RSSBus/Automator) running inside my firewall, on my desktop, or in my Browser making the offline and online divide seamless – portable ‘backend’ widgets for the Web (more on this later). Aside from all this, Pipes adds an interesting twist to information personalisation.
* [in case you are wondering the title of my talk refers to a user scenario managing and filtering many information sources and notifying me of things that are important at a given time or place using the most appropriate delivery. A job my partner, Lynne, currently does to some extent and Gmail does for my email.]

]]> http://www.outofrhythm.com/2007/02/09/yahoo-pipes-a-cloud-based-feed-router/feed/ 0 http://www.outofrhythm.com/2007/02/05/recovering-from-kiwi-foo/ http://www.outofrhythm.com/2007/02/05/recovering-from-kiwi-foo/#comments Mon, 05 Feb 2007 03:57:59 +0000 Robert http://www.outofrhythm.com/2007/02/06/recovering-from-kiwi-foo/ It’s over. I’m shattered. And it was absolutely fantastic. Lack of sleep is however has taken a toll. Kiwi Foo (a.k.a Baa Camp), an O’Reilly Media spin-off unconference organised by Nat Torkington was held in Warkworth over the weekend. The photo-stream over at flickr captures the activities.

Attended by a mixed bag of individuals from geeks, user experience designers, artists generally – we’re all artists in some way – business bods, government; you get the picture. The one shared interest was the emerging technology space, how it is changing our society and making sure that we are doing the changing. It was the cross section of interesting individuals, the interactions, the sharing of perspectives that made the event very special from my point-of-view. I’ve taken away a lot of tacit knowledge I doubt I would have obtained elsewhere – Thanks Nat and Jenine. Also if it wasn’t for the Great Coffee that Russell procured I doubt I could have operated on so little sleep.

Friday evening started with a powhiri that I caught the tail end of. A few formalities of the administration and group introduction type followed. Then the establishment of the schedule for the next few days. In the FOO tradition the schedule is not predetermined but constructed adhoc on the first evening. Participants made a mad rush to large sheets of paper with day and time slots hanging from the Mahurangi College staff room walls. Filling out their particular topic. This was all done a couple of hours before the first session. I managed to get a reasonable time on Saturday afternoon to put my case for Atom based Web APIs to the test [more on this in later posts].

The first formal session I attended, along with many others, was a discussion (and it was a discussion) on broadband issues and policy with David Cunliffe the Communications and Technology Minister. I have to say I was impressed with his understanding of the issues and his willingness to listen and take on what was being raised by the audience.

Not being a ‘networking’ wonk, nor someone who has been following local issues, I didn’t realise how bad the current situation actually is. Especially with regards to peering and the robustness of our backbone. Basically the market hasn’t provided so now the issue is being addressed at the first level: unbundling the local loop. Though that is just the beginning. The point was clearly made there has been massive under investment in the network and unbundling is a great, if belated, start to getting things on track again. However as the network is upgraded policies have to be adopted to ensure that enough space and power is placed in the boxes at street level. This is required ensure third-parties can put their equipment in and to enable peering at the street level. It was clearly articulated by several in the audicence the economic impact the lack of peering has had and how it extended beyond bandwidth issues right up to day-to-day Internet usage. Rod Dury declared the need as the “Internet Efficiency Policy.” Peering is a really big issue that needs to be sorted and David declared “from tonight peering is now a primary issue.” Of course the huge round of applause, with a few hoots, followed such a definitive statement. The next morning I had a follow-up conversation with Andy Linton that clarified some issues from the night before that I had not understood.

Another round of sessions followed but at 9:30pm I decided to socialise and partake in the fruits of the more “interactive” sessions: quadraphonic music and body illumination – if that is what you can call it. Both very cool. I particularly liked the quadraphonic sound arrangement that blasted from four car stereos parked around the school netball courts. Unfortunately I cannot remember the name of the artist.

Saturday started early. I decided to stay in the Whare Nui and despite the cacophony of sleepers’ vocals I had a good four hours of sleep. Up, bright eyed ready for great breakfast discussion.

The first session I attended was Tim Norton giving a description of his trials and tribulations with starting and funding technology businesses. The discussions contributed further “stories” and perspectives from others on both-sides: investors and business start-ups. I always find the in-person “war stories” really helpful as they lend a personal touch to an individuals experience that I just don’t get from other sources other than your own experience. Following this I attended sessions on Rapid Web application development that discussed various languages, frameworks, patterns and approaches to application composition. Flex, Jiffy, Django, Pylons and Rails where all discussed in some way. I also attended sessions on User Experience Design, Copyright Amendment Bill, Ambient Signifiers, User Stories and a demo of Xero. I really wish there was two of me so I could have attend numerous sessions running in parallel.

Saturday night went for a while. After a lot of socialising and meeting new people I end-up playing Werewolf until 4:30am. The game is a stable at O’Reilly gigs but I had never played it before. It was great fun and a fantastic way to meet others. Having started totally green and being identified for what I was – a Werewolf – I ending up being the evil participant four times in a row. At least I learned the game fast – orchestrating a complete clean up of the Werewolves in the final early morning game.

I attended only a single session on Sunday. This was not planned. Instead I ended up talking to Ian Hay (from Orange) and Don Christie for most of the morning about mobile technologies and applications. A fantastic discussion. The final session I attended was on the One Laptop Per Child project it’s aims, issues and expected time frames. Chris DiBona had brought a prototype with him so every one had a good look at the hardware and the sugar GUI. After that I managed to have some interesting conversations with Robert O’Callahan and Ben Goodger both working on Firefox about offline storage , application composition with routing and directions of Firefox. Basically I had many interesting discussions throughout the camp.
Anyway it was great fun. I was absolutely stuffed but stoked to have attended.

]]> http://www.outofrhythm.com/2007/02/05/recovering-from-kiwi-foo/feed/ 0 http://www.outofrhythm.com/2007/01/30/waka-apache-lab-established/ http://www.outofrhythm.com/2007/01/30/waka-apache-lab-established/#comments Tue, 30 Jan 2007 05:14:43 +0000 Robert http://www.outofrhythm.com/2007/01/30/waka-apache-lab-established/ A couple of weeks ago Roy Fielding established an Apache lab for the development of Waka and related improvements to other specifications. From the DOAP:

The Web Architecture Lab is a work area for specifying and experimenting with the interrelated shared agreements (protocols) that make the World Wide Web a happy place. The goal is to produce a central storage for Web protocol evolution, including both existing Web protocols and new ones, that Apache developers can refer to, comment on, prototype alternatives, and provide examples and test cases. A secondary goal is to experiment with tools for integrating public commentary with the specification process.

Nothing in the lab at the moment but Roy has been discussing Waka recently breaking a long silence after throwing a tempting morsel at ApacheCon2002. As Mark Nottingham has stated:

Is WAKA still vaporspec? Totally. Does it still have to overcome the inertia of HTTP by proving at least an order of magnitude improvement (which HTTPNG and others failed to do)? Yes. Still, Roy has a pretty good track record, and I’d put my money on him (especially when backed
up by the ASF) over a bunch of vendors trying to sell “platform” any day.

The Apache Lab was set up to allow failure. I for one am very interested in playing with Waka using Yaws.

A little more info in Roy’s Lab proposal.

]]> http://www.outofrhythm.com/2007/01/30/waka-apache-lab-established/feed/ 0