Thursday, October 20, 2005
AMASS Update
I want to clear up a few points about AMASS, the Ajax MAssive Storage System, that I've seen around the blogosphere:
1) AMASS can store much more than 100K, up to megabytes of information. AMASS can store up to 100K of information without prompting the user; afterwards, the underlying Flash system prompts the user, which AMASS detects to make the Flash "Do you give this website permission to store X amount of information" dialog appear. Afterwards, you can store an arbitrary amount of information; I've successfully stored up to 10 megabytes. Why don't you try more and see where it falls over?
2) AMASS is not a security threat. The underlying Flash SharedObject system that AMASS uses keeps storage partitioned between domains (though be careful using something like AMASS on a website where different providers have the same host name). Also, at each level of magnitude of increasing storage (i.e. storing 100K, 1 Meg, 10 Megs, etc.) AMASS reprompts the user to make sure the user gives the site permission.
3) AMASS, by itself, does not make offline access possible. However, it is one of the essential ingredients in achieving offline functionality for AJAX apps, which is one of the reasons I created it.
4) AMASS is in alpha, so expect bugs :) In November and December I will have more time to focus on making it reliable.
5) I need help on making AMASS work on Firefox for the Mac!
6) AMASS does not uses the Flash JavaScript Integration kit; I built an early prototype of AMASS using that framework. The Flash JavaScript Integration kit is excellent and well designed; however, the internal mechanisms it uses to achieve communication between Flash and JavaScript have serious performance and data size issues for large datasets. Instead, I use the Flash ActiveX methods in IE, which are fast, and the Flash LiveConnect methods in Gecko based browsers, which are also fast. A small point is that all methods calls have to be asynchronous in the Flash JavaScript Integration kit, which would have made the AMASS API more difficult, while the ActiveX/LiveConnect methods made it possible for me to make synchronous methods for the AMASS API.
7) AMASS uses features that have been in Flash since the Flash Plugin Version 6; over 95% of the installed PC base on the Internet have the Flash features necessary to support AMASS (according to Macromedia statistics), so it is essentially everywhere. I didn't use Flash 8's Flash/JavaScript communication facilities for exactly this reason.
1) AMASS can store much more than 100K, up to megabytes of information. AMASS can store up to 100K of information without prompting the user; afterwards, the underlying Flash system prompts the user, which AMASS detects to make the Flash "Do you give this website permission to store X amount of information" dialog appear. Afterwards, you can store an arbitrary amount of information; I've successfully stored up to 10 megabytes. Why don't you try more and see where it falls over?
2) AMASS is not a security threat. The underlying Flash SharedObject system that AMASS uses keeps storage partitioned between domains (though be careful using something like AMASS on a website where different providers have the same host name). Also, at each level of magnitude of increasing storage (i.e. storing 100K, 1 Meg, 10 Megs, etc.) AMASS reprompts the user to make sure the user gives the site permission.
3) AMASS, by itself, does not make offline access possible. However, it is one of the essential ingredients in achieving offline functionality for AJAX apps, which is one of the reasons I created it.
4) AMASS is in alpha, so expect bugs :) In November and December I will have more time to focus on making it reliable.
5) I need help on making AMASS work on Firefox for the Mac!
6) AMASS does not uses the Flash JavaScript Integration kit; I built an early prototype of AMASS using that framework. The Flash JavaScript Integration kit is excellent and well designed; however, the internal mechanisms it uses to achieve communication between Flash and JavaScript have serious performance and data size issues for large datasets. Instead, I use the Flash ActiveX methods in IE, which are fast, and the Flash LiveConnect methods in Gecko based browsers, which are also fast. A small point is that all methods calls have to be asynchronous in the Flash JavaScript Integration kit, which would have made the AMASS API more difficult, while the ActiveX/LiveConnect methods made it possible for me to make synchronous methods for the AMASS API.
7) AMASS uses features that have been in Flash since the Flash Plugin Version 6; over 95% of the installed PC base on the Internet have the Flash features necessary to support AMASS (according to Macromedia statistics), so it is essentially everywhere. I didn't use Flash 8's Flash/JavaScript communication facilities for exactly this reason.
Comments:
Links to this post:
<< Home
Sometimes I understand slowly :-P...
But now I am starting to realize the power of AMASS. It sounds very intressting and I can't wait to test it.
Have I understand it correctly; -If the user close the browser window and later on enter the webpage, the webpage that has stored data in AMASS can recover any data that belongs to it?
If this is true, than AMASS is huge...
Regards,
hbi
But now I am starting to realize the power of AMASS. It sounds very intressting and I can't wait to test it.
Have I understand it correctly; -If the user close the browser window and later on enter the webpage, the webpage that has stored data in AMASS can recover any data that belongs to it?
If this is true, than AMASS is huge...
Regards,
hbi
I am considering of using AMASS with one of my hobby projects; Challenger. It is a distributed desktop environment, resembles to webos, though so far only for IE6+.
But I will store and work with XML clientside. I have built a server API that interprets XML to arbitrary actions (SQL or other). The syncronization will probably be trivial to applicate.
Post a Comment
But I will store and work with XML clientside. I have built a server API that interprets XML to arbitrary actions (SQL or other). The syncronization will probably be trivial to applicate.
Links to this post:
<< Home
Subscribe to Posts [Atom]