Names, Msgpad, The Future

Names Do you find it hard to name stuff? I recently named a component I created 'Brian', simply because I had to call it something. Some of the people at IBM seem to have a good naming convention going... "We named the prototype: Queso, spanish for cheese, because we are currently naming everything after the Mexican burrito place across the street in Cambridge, MA. " - http://torrez.us/archives/2006/07/17/471/ Msgpad As for msgpad, I've decided to cleave the architecture in half. WHAM! Right down the middle. One half is a data server speaking ATOM Publishing Protocol, and the other half is a rich web client using javascript, etc. For the last three months (and on/off before then) I have been irritated by the MVC architecture that is standard in web frameworks. For web "sites", MVC is perhaps fine. But for web "applications" it is not good enough. A web application relies on rich user interaction. This will involve substantial javascript. I'm not talking fade in/out and other scriptaculous flare, I'm talking about something like editing an imaging (cropping, painting, etc). The idea with the ATOM server is that you can create a collection of resources and perform SCRUD (search, create, read, update, delete) operations on them using standard HTTP (puts, posts, deletes, gets). A typical use case would be to HTTP GET an image resource, make modifications in the browser, and then PUT the modifications back on the server. The crux of the idea is that every "resource" (image in this case) has a URL that serves as a handle. So you could have something like http://beagles.com/image/12 which would refer to an image type resource with an ID of 12. Google Calendar are an example of what I'm shooting for. The Future In times like this, I'm happy to live in Australia, far away from the global "action". Provided we don't blow ourselves up, fall in to a depression due to peak oil or an over heating China, I think we're going to see a lot more web applications. The applications are going to share data, and that data will need to be standardised somehow. ATOM is a nicer way of doing this over custom interfaces. There's potential for applications to form some sort of infrastructure like the telco companies of the world. Lines of communications are shared and they charge to access each others networks. In the case of the Internet, I can easily see data shared between applications in a similar fashion (with user agreement of course). Perhaps more important than data, I can see web services shared between companies. Want chat facilities embedded in your application? No worries, just plug in msgpad. Don't know how to speak ATOM with the server? Not a problem, here's a line of javascript you can dump in your page, and here's the CSS styles you can modify. Well, you get the idea... Incidentally, if you would like to embed a rich chat application in your own software, please contact me :)

technorati tags:, ,

Blogged with Flock