Each mini-site includes the event details, a map to the location and photos that were taken there. You can see an example of this with the The Carson Workshops Summit.
Nothing new in that perhaps. What is unique about Eventsites is that it uses no server-logic and stores no data of its own.
Eventsites is simply a client to other web-services.
Clients on a componentised web
In the last post we looked at the potential that might be realised by componentising today's vertically-integrated web applications.
We also questioned what new applications might start to appear when fundamental functionality such as content management or authentication is available directly via web-services?
The coal face
In order to explore the theory we need to test it. The best way to test it is to build something from it.
The challenge was to build a dynamic website that let users both add and view data but stored no data of its own.
The result was Eventsites.
Eventsites uses EVDB for authentication and data storage, Google Maps for mapping and Flickr for photos. All the interface logic is done using AJAX in the browser.
Standing on the shoulders of giants
By using these third-party services we give ourselves the power to offer users extremely rich functionality whilst doing very little of the legwork in-house.
Not only do we save redeveloping existing functionality but we also benefit from what the other sites already offer.
Creating an event with Eventsites also creates a page on Eventful whilst photos on Eventsites are of course also viewable from Flickr.
Browser power
Scaling a traditional application from 10,000 users to a million is an intensive and expensive task. Servers become server-farms and databases spawn masters and slaves.
There is an irony in this though since not only does each user bring extra demands, they also bring an extra computer. 
Every website visitor uses a browser and almost all of those browsers can execute Javascript, Java and Flash. Why not take advantage of this?
Since the heavy-lifting of Eventsites is done by EVDB, Google and Flickr, we can afford to do something unique with it.
By outsourcing all of our secure logic, we can afford to move the interface logic from the server and into the browser.
Desktop applications via the browser
By doing this, we have in essence created a desktop application that simply happens to be delivered via the web.
Web-services provide storage and all secure-logic, the browser powers the execution of the remaining interface logic and the server simply delivers flat files of code, CSS and XHTML.
Security and identity and cross-domain XHR
Taking such an extreme approach to mashing throws a floodlight on several issues including cross-domain AJAX, identity and security. In so doing, it becomes clear that all three have a number of serious problems.
However, it also becomes clear that with only a few small tweaks, some of these problems could easily be neutralised and that their disappearance might open the gates to a new and more powerful web-architecture.
3 comments:
Nice to see you here and thanks again for your kind comments.
There are two sets of problems at play here - identity and permissions. Identity is as you know, the confirmation of each party (server and client) being who they say they are and permissions is the the ability of each party to operate on the other party.
On the server-side, both identity and permissions are pretty well sewn up. If I send a request to Flickr.com I can be as certain as dammit that Flickr is the company that's going to receive my request and also that it's not going to be able to do more than it should do.
Flickr can be pretty certain that as long as they've written their code well, I'm only going to be able to do the operations I'm allowed to do on their data. I'm not going to be able to drop tables or change their homepage unless they specifically allow me to.
On the clientside however, neither of these problems are solved. As you rightly highlighted, the identity of a client is still a huge problem, possibly the biggest problem on the internet today. Am I who I say I am and how do I inform you of it?
However in addition to the outward-bound identity problem, there is also an inward-bound permissions problem. Given that I am who I say I am and you are who you say you are, I should be able to control how much of my person (DOM) you have access to.
Doing business together shouldn't automatically give you access to everything that I own. Unfortunately that is exactly the way things work today.
I haven't even begun to attack the identity issue (although it's huge) and am almost certainly not qualified to do so, the only thing I've so far tried to highlight is the permissions problem. I strongly believe that although it's less immediately obvious it's still extremely significant.
http://appPad.com