Sneak-O-Scope - Version 3 - Now on Google App Engine

Hey,

After a week of slogging and fighting with python, Django and webop, I was finally able to host Sneak-O-Scope on Google App Engine. I attended the Google Developer day and that helped me resolve a lot of issues. With the database and code now on the cloud, I would have to see how this helps me scale better. I did have a couple of road blocks, and I thought of writing them all here.
The second major milestone is that Sneak-O-Scope now running on top of the SNAPP Framework. The application should work for MySpace and Hi5 without modification. I have submitted the application for review on these social network and would hopefully get a positive result by the time I return from vacation.
Now for the 'gotchas'

1. The template files should not be visible externally and hence should not be specificed in app.yaml. However, this is a restriction only on the hosted service, not the local developer server. It took me a whole lot of debugging to figure out. The error simply said that it was not able to find the template file
2. If the python files are not directly under that folder where the server runs, we have to empty __init__.py has to be included inside folders where the python files are placed. This is a python convention, just to be careful.
   
3. The JSON that is sent to the application by SNAPP is currently not parsed. This is a task that I would have to pick up and do at a later point of time.
   

There were also some javascript errors, but they were trivial to debug. Debugging (using firebug) can be harder as the URL of the iFrame that hosts the application changes on orkut. Hence, it would be better to include logic using javascript files that have static names; breakpoints can be placed on them and are retained even after the page is refreshed.

Now waiting to see how it performs on Okrut.

Google Developer Day - Oct 18, 2008

I will be at the Google Developer Day, India.

IIMB-Vista - Second Submission

Previously, I had posted my submission on IIMB-Vista. Unluckily, that did not get selected. I had also written another piece that was submitted under a different name; that got selected. Not sure how this is better than the previous one :(. Too bad that I cannot go to talk tomorrow :(

Making Ammo Ups an opensource product will only increase the cost of development and will lead to mushrooming of copy cats. The free developers and reviewers that opensource promises are realized over a long period not suited for a startup. The company would lose control on the product road map. The existing code could have security implications that would impact the business. The task of separating noise from valuable contributions would take lot of time and effort. The complications of licensing would make it harder for the legal team to prevent look-alikes. The developers lose the incentive for working on a product whose development also seems to happen for free. Rather that riding the wave, the company should invest the time in strategic changes to revamp the product. The audience of these markets is known to be niche, and going opensource would not really matter to them. The company should implement a program to better integrate feedback from this audience.

Open source of NOT - IIMB Vista 2008

Here is my submission for the Software Czars event at IIM B Vista. The caselet can be read from here.

In brief, the caselet was of a gaming and music software manufacture and their dilemma to go open source. The submission had to be a 150 word explanation of whether or not should they embrace open source.

• AMPS should go opensource as it would enhance the image of the company. The move would make the product better in the long run by letting the gamers develop features they need, eventually bringing in newer users. The Intellectual Property is not only the code but the conceptualization, hardware and design that would be suitably protected by patents.
• To start with, AMPS must release a developer API that allows evangelists to create experiences that the company may not have visualized. This would increase the sales of the product and spawn new product lines.
• Open source will bring in fresh developers to add to the army of existing developers working on newer idea of a developer API.
• After judging the above effort, all code can be open sourced. This phased initiative will buy AMPS time to review the quality of existing code to better reflect the company standards

Would love to hear your comments on my arguments.

Securing Orkut Opensocial Applications based on iFrames

A few posts ago, I had written about a bug I had discovered in an application that typically runs on an iFrame. The apparent advantage of using an iFrame is the support for AJAX and seamless implementation across various containers.
The application however failed to implement the mechanism to identify and authenticate the user. Opensocial containers provide the gadgets.io.makeRequest method that can be signed and sent to the server on which the application is hosted. the gadgets.io.makeRequest is an AJAX request to the *.gmodules.com that fetches the content of the required URL from the remote server (an AJAX server proxy). Hence, it cannot be directly used to populate the iFrames.
To summarize, the problem here is that the application should be openend in an iFrame to which we pass an authenticated request identifying the request (using gadgets.io.makeRequest). A quick fix I can think of would be to make a gadgets.io.makeRequest to the server where the application is hosted. The response to this would be a URL with a nounce that would be loaded in the iFrame. The application server would use this nounce to identify the user and associate the cookie of the iFrame to the signed user data that has been posted. The SNAPP application framework would be using this method to initiate iFrames.
However, since the REST API for Orkut Opensocial application is already in the sandbox and hence, iFrames may use that directly going furthur. Till then, this is a small stop-gap solution.