October 19, 2005

From Cookies to Chocolate Mousse Cakes

Brad Newberg's AJAX MAssive Storage System (AMASS) combines flash and javascript to offer web sites a convenient, local store for large amounts of JSON data. It works only on win for now.

The AJAX MAssive Storage System (AMASS) uses a hidden flash applet to allow JavaScript AJAX applications to store an arbitrary amount of sophisticated information on the client side.

Internally, we use a hidden Flash file and Flash's SharedObject functionality to permanently store the information. We script the Flash file using it's ActiveX methods on IE and it's LiveConnect methods on Firefox. We use Flash's SharedObject's callbacks to detect when the request storage dialog is on the screen, and pass these back to the JavaScript application. We also center these values on screen.

Source: AMASS Project

This is very cool, so I won't make too much fun of why Brad put the AJAX buzzword in the project name :)

October 14, 2005

QOTD

I'm borrowing Danny's QOTD convention here:

"Some people would call this a worm. I call it popularity."

- Samy, writing on his project blog before proceeding to make over 1,000,000 friends on MySpace (with the help of some overlooked javascript).

October 5, 2005

Ning Content Store

Chris covers this subject in much more detail, but I'll post anyway.

I was looking around Ning (perhaps Ning around?) and noticed an interesting blog entry about the Ning Content Store.

This hosting service provides its community with "data playdough" in the form of content objects which can be read (but not written) across apps. There is no direct management of the data store, although you can browse the data using the RESTish pivots.

The biggest difference between the Content Store and a traditional RDBMS is that in the Content Store, there is no definition of content structure separate from actual content. There are no table schemas that must be set up before rows are inserted. The type and developer attributes that an app chooses to use at runtime are the type and developer attributes that end up in a content object.

Restrictions on content type and structure are not enforced by the content store. That job is left to the app. This allows apps to be much more flexible about the data they manage. Creating an app that allows end-users to define their own fields in addition to those defined by the app developers (such as a flexible calendaring app or a to-do list manager), is unwieldy in a relational database -- in essence, a developer would have to create a mechanism like that provided by the Content Store natively. Queries and data management are simpler, and apps can be both more flexible and more powerful, without making them harder to build.

Source: Ning Dev Docs

I prefer the structured approach to defining application data, but I understand why Ning's developers are prioritizing convenience. Over time, conventions and standards will emerge in the Ning community, and us structured folks can always help.

Playdough and Lego bricks are both great ways to build things.