SMashups - PART I

SMashups - PART I
SMashups: Scalable, Server-less, Social Mashups for Web 2.0
Introduction
------------
Maturing is the age of Web 2.0.
With it, comes mashups 2.0.

why the term SMashups? in this case, the S actually has three meanings, Social, Scalable, and Serverless। that's right, it's about developing a new web service that resides direclty on the client, through a social network, without needing a mashup server. almost any application / mashup would benefit from considering this approach. and i anticipate that in the very near future, there will be a FLOOD of new development along these lines, as mashup developers begin to realize how few resources it takes to build these SMashups.

i know i'm not the only one working on these systems, but i'm hoping to at least join the growing chorus of advocates with this article, and to contribute to the growing body of information to support ongoing development efforts in this new digital frontier (seems every decade we have a new digital frontier)। so to many of you, the methods i am suggesting are probably already quite familiar. you probably even have some better ways of doing things programmatically, or tools that you already use. for many others, however, this is something entirely new. regardless, i'm confident that we'll be seeing a mass exodus from Mashups to SMashups, so that last half of this year will be truly interesting to watch unfold as the industry giants align for the full impact of Web 2.0.

Because there is so much information to present, I decided to release this article in six parts:

part i) introduction
part ii) getting out of the sandbox
part iii) restoring context : building a simple opensocial xmlhttprequest object
part iv) the proper use of servers (cloud computing and the mashup developer)
part v) more client-side goodies (container cache, application cache, and durable remote storage)
part vi) what does it all mean? putting it all together

this is part i, the introduction, where i just try to layout what will communicate। i will publish each part within 1--2 weeks of each other, and quicker if possible. in fact, i'm really hoping that others will contribute great ideas and help me get the dialogue going so as to adjust the writing of future sections based upon the feedback from the community regarding previous sections. by the last section, i hope to put all the pieces together and demonstrate not only what cool technologies we have available, right under our noses, but also how to profit from this knowledge and to build a better internet for the future while we profit.

in part ii, i'll discuss how we get out of the sandbox, and how gadget technologies and social networks have provided a much-needed resource that allows mashup developers to escape the sandbox, liberating us to create applications that run entirely on the client, eliminating the need for a mashup server (i।e. bottleneck).

in part iii, we'll investigate an issue specific to makerequest, regarding context। it's not a major developmental breakthrough, technically speaking, but there is one special trick we HAVE to be aware of when using makerequest, something we never had to worry about with xmlhttprequests--context. we'll build our own very simple xmlhttprequest object, based upon makerequest, to explain how we can handle make-request, and how to use this raw power to our advantage.

in part iv, i'll try to layout what i believe to be the best way to use servers। granted, we don't necessarily 'need' servers to support SMashups, but we do find through analysis that having a server can provide simple benefits that allow us to build new models for fun and profit. we'll talk about how to get services started for free, issues related to scalability, maintainability, and all the other 'abilities' i have time to address.

in part v), we'll look at technologies such as persistent storage in opensocial, google gears, and developing our own caching systems to make applications that are much more responsive, and even distributing info storage among many clients for batch submission and processing in the cloud।

finally, by part vi, we'll work to integrate all of the pieces together to discuss new opportunities in the world--both as they exist today, and where they will be in the future.
Welcome, the SMashup!

now there's one last thing to consider। when i google 'smashup' or 'smashups' there are ABSOLUTELY NO google adds attached to those words :) -- ok, i just checked, and amazon does have one add up for 'smashups', related to a music band. also, in my search i found some instances where newbie developers had improperly referred to mashups as smashups, but overall, the concepts of smashups haven't yet taken root in mainstream.

therefore, i'm publishing this article in the attempt to improve the dialogue concerning these new technologies, and hopefully to learn more about what others are doing in this area.
happy coding,

nolybab praetorius
END OF PART I

see part II here