Why a JSON parser for JavaScript?
JSON is a proper subset of JavaScript, effectively reflecting the definition of a JavaScript object. The easiest way to parse a JSON string into a JavaScript object is using the eval statement:
var obj=eval(‘(‘+jsonString+’)’);
And therein lies the problem. Eval statements are dangerous, especially in a web2.0 environment and can be abused if your evaluation string is contaminated by content you don’t control. Even if your server side code does JSON encoding you could still end up with some severe problems. For example:
jsonString={a:new function(){document.body.innerHTML=”This script just hijacked your page”;}}
That is why JSON parsers that don’t make use of eval is recommended. The smallest and best one I’ve come across can be found at http://code.google.com/p/json-sans-eval/
WebSocket Support Investigation
With Comet technology dying out and HTML5 around the corner, WebSocket support is becoming a very hot topic on the edge of the new Push Button Web revolution.
I set out to discover how viable that technology is right now.
Client Side
HTML5 Compliant Technologies
HTML5 compliance includes a WebSocket object that can be used to make persistent streaming tcp connections to a WebSocket server (cross-domain).
The only browsers currently supporting this technology is Google Chrome and Safari. (Webkit implementors). Firefox is planning on including WebSocket support in their 3.7 release. IE is quiet on the matter (we're used to this by now).
I have tested HTML5 WebSocket implementation using Chrome as client and PHP for the WebSocket server. It was blazingly fast, reliable and robust when I intentionally disrupted network availability.
WebSocket using Flash
For browsers not offering native WebSocket support, the standard workaround is to use Flash socket connections. I implemented a few of these methods, and even though I eventually got it to work, I found it not very robust (when it broke, I had to refresh the page to get the connection back up and running) and definitely not very friendly (Flash TCP connections require a security policy file to be rendered from the same server on port 843 before the socket connection is allowed)
This is an awkward solution, and feels mostly like a hack. It is also dependent on client-side variables like whether Flash is supported on the client and what version is running.
Server Side
The server side implementation of WebSocket is well supported. Most server side programming languages provide an implementation of CURL, which is quite enough to support WebSockets.
The main challenges on this end is configuring your hosting platform to open the chosen port for traffic.
Comet support on GAE
What is Comet?
Comet is a set of web methodologies (like AJAX) that allows client browsers to have persistent http connections to their servers. It is also known as long polling. The benefits of making use of this type of connection is that any state change on the server can be immediately pushed to all connected clients. The physical result of this can be seen in applications like Google wave, where one user is typing a message into a wave, and another subscriber to that wave can see the letters appearing as they are being typed. [see wikipedia]
Browser Limitations
To maintain the security model, browsers are endpoints that don't allow connections to originate from a remote location. This means that whatever network connectivity is implemented in the browser environment has to be initiated in the browser and cannot come from the server.
This means when a state changes on the server, there is no way for the server to let the client know about the change. It has to wait until the client requests an update before it can be notified about the state change.
How Comet Works
There are several implementations of the comet meme, but they all rely on the same concept: opening a page on the server that never quite finishes loading. If, for instance, you load a JavaScript file and the server keeps the connection open, to the browser and to the rest of the world it just looks like a file that takes forever to download. The server, however, can now send updates to the client by pushing a JavaScript statement through the slow-loading file.
On the browser side, JavaScript includes are executed line by line as they arrive through the network. So when it gets the server's update code, it will immediately execute it, and your client can respond to the message.
Comet and GAE
As soon as you make use of Google AppEngine, you run into some limitations. Two of those limitations directly affect the comet concept:
- GAE does not allow streaming. This means that the entire resource has to be rendered on the server and the script on the server must exit before the response is sent off to the client. This makes using a long-loading file impossible to implement.
- GAE has a 30second execution restriction on scripts. So even if it were possible to stream files from GAE, it could only happen for 30 seconds before GAE automatically shuts it down.
This means that comet is not a viable option for achieving persistent HTTP connections between the client and the server. [see cometdaily.com]
Other Alternatives
There are other alternatives to accomplish a similar effect:
Java Sockets
Java plugins on an html page can create sockets that listen to incoming messages. This could be used by the server as an endpoint to which it can make announcements. Due to the fact that communications in this model is initiated on the server, this strategy comes with a heap of network baggage. Dealing with proxies, firewalls and non-standard endpoint network configurations becomes the responsibility of the Java plugin and the server announcer.
Very Frequent Short Polling
This is technically not in the same league, but attempts to recreate close to real-time connectivity with the server. In this model, the server is short-polled on a frequent basis (1 to 2 times a second, or whenever a previous poll completes).
As one can imagine, this method is very resource intensive and bandwidth hungry. Even if polling the server returns no data, just the TCP/HTTP overhead will consume a lot of bandwidth.
Also, when dealing with software residing on GAE, there are limitations imposed (and for premium users, costs applied) with regards to the number of connections made to the server. Even if these numbers were very large, it becomes a very real problem when very frequent short polling is used.
HTML5
With the wide adoption of this standard, browsers will have access to web sockets. This will essentially open up a two way connection to the server where the same connection can be re-used. It will be ideal for a RPC pipe. It will also be ideal for comet-type connectivity where the server can push information onto the pipe and the client can then respond to it. [see w3.org]
Google App Engine SDK 1.3.1 Released
This release is a fairly sizable one with several enhancements:
- Datastore Query Cursors – Query cursors allow an app to perform a query and retrieve a batch of results, then fetch additional results for the same query in a subsequent web request without the overhead of a query offset. [more]
- Transactional Tasks – The ability to group a set of SQL operations into a single transaction that either succeeds or fails as a whole. [more]
- Custom Admin Console Pages -
- New “month” and “synchronized” syntax for Cron configuration – [more]
- Removal of the 1000 query result limit – Stability and performance improvements as well as new technologies such as Query Cursors prompted the GAE team to get rid of their 1000 query result limit altogether.
- Automatic Datastore Retries – Sporadically, Bigtable is not available on request. The standard workaround was to manually retry the request until it succeeded. This is now a built in automatic feature, and app engine will automatically retry queries that failed due to Bigtable inaccessibility.
- AppStats (for Python GAE) – a RPC instrumentation library for profiling performance of calls from the app to backend services to identify bottlenecks, ineffective caching and redundant RPC calls in their app. (The Java counterpart is in beta testing at the moment) [more]
- Unit-Testing Framework (for Java GAE). This framework also allows for integrating App Engine apps into other existing testing and automation frameworks.
- E-Tags Support! – If-matches, If-not-matches in HTTP headers for content version control.
Adobe Air 2 Beta Finally Out!
In an industry that are working with virtual file systems and online document management (www.knowledgetree.com), I have been waiting for this moment for some time now – Adobe Air 2 is finally in beta.
This version of Air opens up several new functionalities – eg. :
- Drag & Drop support of remote files via the filePromiseList clipboard object.
- Socket Server Support – Air apps can now listen on a port and no longer need to initiate a network conversation. This also enables different air apps to now communicate with each other using socket connections.
- New Filesystem API – This includes functionalities like being able to open files with their default registered application, flag files as downloaded so that the operating system can warn against opening them and notification of mounting and dismounting volumes.
- NativeProcess API allows you to execute a third party process and interact with it.
- Microphone Capabilities allows you to access raw data from the microphone, inspect it, alter it, encapsulate it as WAV and store it to the local filesystem.
- HTML5 & CSS3 Support will let you implement the provisional features of next-gen interactive document markup.
For more information on where to get all this goodness: Adobe Labs
Adobe Air MouseLeave Window
It took me a while to figure out how to get an Air application to let me know when the mouse leaves the window. Once I got it.. easy as pie:
window.nativeWindow.stage.addEventListener('mouseLeave',function(e){
alert('The mouse just left the Window');
});
Tada!
Zend Server 5.0 Beta Code Tracing
Zend Server 5.0 Beta is promising an awesome bug-tracking method that will help find and solve problems much easier. Whenever an error is encountered, the new tracing feature will automatically log full error tracing information – even when in production mode.
Just as cool, one can manually run the trace to profile the execution of your code in real time. This will allow you to find bottlenecks, see the function tree for the entire execution of your script and use that information to optimize execution.
Take a look at Zend
jQuery & JavaScript Tips to Improve your Code
Here’s a nice post on TripWire Magazine on improving your JavaScript coding, especially in jQuery.
It deals with these topics:
- Improving your selector skills
- Testing for empty collection containers
- A URL you can use to get the very latest jQuery on page load
- Using callbacks to synchronize Effects
- Using the Event model for DOM and custom object interaction
- Creating custom selectors & how to use them
- Making entire elements clickable – the easy way
- Preloading images – jQuery style
- Disabling / capturing right-click contextual menu
- Grouping queries for simpler code
- Using QUnit for integrated unit testing
To find the article, go to TripWire Magazine
Converting Binary String to ByteArray
While using HTML/JavaScript in air, I have found no way of getting the Air-Ajax functionalities to run in synchronous mode. For this reason we are forced to manage certain upload / download functionality using the XMLHTTPRequest object available via Javascript.
However, one quickly runs into problems trying to write binary strings requested in this fashion, to the local file system. Write operations for binary files need to be passed a flash ByteArray object that contains the data.
Here is how to convert a JavaScript binary string to a ByteArray, ready for use with file IO functionality in Adobe Air:
string2byteArray=function(str){
var ba=new air.ByteArray();
for(var i=0;i<str.length; i++){
ba.writeByte(str.charCodeAt(i));
}
return ba;
}
Hope this helps some.
Drag Server Side File to Local Explorer in Air
Before we complicate things by discussing the actual file download, let’s take a quick look at how the drag & drop functionality works.
Drag & Drop Model
When dragging and dropping items between different windows, whether it be in Windows, Mac or Linux, a standardized process seems to be in place to handle it.
First, it would be a breach in the application security sandbox if an application could access the drop event of something that was drag off itself and onto another window. For this reason, if you drag an element from the Air application window to any other window on the OS, you will only be able to access the onDragStart event and will never have access to the actual drop event.
The method for communicating with the application on the receiving end of the drag drop operation is via the clipboard. As soon as a drag event off the air window is detected, one should populate the clipboard with a set of information you wish to send to the receiving application.
File Copy Clipboard Process
Next we take a look at what the general process is whenever files are copied from one window to another on most platforms. The clipboard must be populated with an array of file location objects (that actually exist on the machine). When dropped, the receiving application will perform a copy or move operation on the array of file locations sitting in wait in the clipboard.
The issue that becomes immediately obvious from this is that when dragging a file or a set of files from an air application to the desktop/explorer, the file might not be available locally as it might represent files or folders residing on the server side. Since we cannot capture the drop event on the receiving application, and since the files don’t reside locally at the moment the drag event starts, there is no information we can put in the clipboard that will cause the receiving application to download the files being dragged.
Clipboard data handler function
The clipboard handler, fortunately allows one to provide a function rather than actual data when setting it. The clipboard will then execute the function and take the result of that function and place it in the clipboard. This is what saves our butts here.
The idea is to create a function that will:
- Asynchronously get each file in the drag list from the server and save it to a local, temporary location.
- Generating a list of these now local files in the temporary folder after all the downloads have been completed.
- Return this file list as a clipboard object and specify the move rather than the copy method.
This function should then be passed as the clipboard data handler function.
There are still some issues surrounding this method (a period during which the application might freeze if you opt for using synchronous file downloading) that could be dealt with by displaying information about the progress of the file download using the same function passed to the clipboard.
Onwards & Upwards!
Categories
Tags
Friends
- Centre of the Universe Tools & Tips for web development and some excellent Titanium tutorials
- Tohir Solomons General Musings for computer addicts
Translator
