Showing posts with label ajax. Show all posts
Showing posts with label ajax. Show all posts

Wednesday, June 06, 2007

All the Web is a Stage

Google Gears' WorkerPool - Message Passing, Shared Nothing Concurrency

By now, you‘ve probably already seen Google Gears, Google's solution for dragging AJAX applications offline. The one thing that jumped out at me was their WorkerPool component. This is a very nice solution for concurrency in Javascript.
In short: if you have any long running task, you can create a WorkerPool which is basically group of Javascript processes Note: they're not threads! The workers in a WorkerPool share nothing with each other, which makes them like OS processes or Erlang's lightweight processes (actually, they're more like the latter, as they're likely to run in the same address space).

And now guess, how these workers, these processes, communicate? Yep: messages, formatted as strings. Important to remember: if you format objects with as JSON strings, you can even send objects and structures along. The handler that receives messages also gets the ID of the sender, so if the sender implements a handler too, it‘s possible to return results asynchronously.

If you‘re reminded of Erlang or the old Actor concept you‘re right. I wonder what the Google Apps will do with this new concurrency approach (well, new for Javascript… yes I‘m ignoring Javascript Rhino).

I still hope that AJAX will die a quick death, like Java Applets, just for being so damn ugly and horrible to implement. But… things like this tell me that this will probably not happen. Good ideas like Google Gears will help paint over the ugly details of a solution, and it‘s all hip now, so it's easy to ignore many of the problems.


The same idea is also being implemented in Scala with their Actors.

Monday, April 16, 2007

State of Origin

Same-Origin Policy Part 1: Why we’re stuck with things like XSS and XSRF/CSRF
In my experience most developers—and even many security people—don’t really know what the same-origin policy is. Worse yet, the rise of AJAX and mash-ups seems to have turned same-origin into something developers are trying to break. Complicating the issue further are the weaknesses in most browsers’ implementations of same-origin, leaving open questions about the effectiveness of the policy itself.


I was surprised that not everyone understood this recently talking to Web 2.0 gurus. Points to the very clear definition of what exactly is the same origin. See also: Subverting Ajax, which includes things like using XSS to extend the XMLHttpRequest object to capture calls and to record the data being transmitted.

Update: Just noticed that the lastest Crypto-gram highlights a similar attack overriding object creation.

Monday, April 02, 2007

Testing and AJAX

Two completely unrelated areas of interest.

The first is Unitils which automates a number of testing tasks. It includes:
* Equality assertion through reflection, with options like ignoring Java default/null values and ignoring order of collections.
* Support for database testing involving test data management with DbUnit, automatic maintenance of unit test databases and automatic constraints disabling
* Hibernate integration features such as session management and testing the mapping with the database
* Integration with Spring, involving ApplicationContext management and injection of spring managed beans
* Integration with EasyMock and injection of mocks into other objects

The cookbook offer concrete examples to do things like mock object injection and the like.

The second is Slingshot: Desktop Apps via Rails, "Slingshot looks like it wraps up a Rails app and packages it in such a way that the user is opening up a Site Specific Browser that accesses your world". It's seen as an alternative to the Firefox 3 or Apollo.

Sunday, March 25, 2007

On the Web No One Can Agree on the Schema

Sunday, February 11, 2007

The Death of Applets and AJAX

Hybridizing Java

So here’s my question. Allow for a moment the possibility that, after 10 years, Java is not going to take over the world of RIAs. Further allow that Ajax is just “how JavaScript was supposed to work in the first place,” but that the limitations imposed by browsers, HTML and CSS committees seem unlikely to let it expand beyond its current bounds. What are we going to use to build RIAs?


And the answer is?

The only obvious solution is Flash. Flash has always been all about cross-platform multimedia experiences and user interfaces. People are very familiar and comfortable with Flash, and it is installed on almost all machines in the world. It’s trusted, stable and reliable.


Do we just forget every 10 years what's going on, does anyone remember Flash Generator from 1998? And I still remember the horrible, inconsistent Flash UIs from that era. Has anything changed with Flex?

Via, Bruce Eckel: Use Flex as the UI for Java Applications

Thursday, February 01, 2007

Need for Speed

Bosworth On Why AJAX Failed, Then Succeeded links to which isn't the first time he has examined AJAX's success and failures or why other technologies fail such as RDF. Some commentary was interesting in the comments and a few blogs, including this summary:


All in all the speaker (intentionally) kept his talk simple and stupid but here are some points I think are worth noting:
  • Products fail because of [lack of] human psychology not poor engineering
  • Top 3 keypoints of UI:
    1. Speed
    2. Speed
    3. Speed
  • Your app should be a tool, it shouldn't leave the user feeling like one
  • Search isn't perfect but it is far better than any human can do so it is tolerable.
  • Analyze the frequency of use of feature and implement those first
  • If your app takes more than 2 seconds to load - forget about it
  • The Motorola RAZR was cool enough so the poor UI (narrow keypad) didnt matter

Tuesday, January 30, 2007

SPARQLing AJAX

Dojo Data "As of January 2007, we have five simple datastores, which are included in dojo as example datastore implementations...dojo.data.RdfStore a read-write store that uses SPARQL to talk to RDF data servers including, for example, the Rhizome RDF application server"

From the source of RdfStore: "RdfStore provides a dojo.data Store for querying and updating a server that supports the SPARQL Query Result JSON format. (see http://www.w3.org/TR/rdf-sparql-json-res/). It also maps RDF datatypes to Javascript objects. RdfStore makes following assumptions about the Result JSON: (1) The result always contains 3 bound variables named "s","p", and "o", and each result binding is treated as an RDF statement. (2) When saving changes to the store, the JSON "results" object will also contain a "deleted" key whose value is a list of deleted RDF resources."

Update: OAT: OpenAjax Alliance Compliant Toolkit "Ondrej Zara and his team at Openlink Software have created a Openlink Software JS Toolkit, known as OAT. It is a full-blown JS framework, suitable for developing rich applications with special focus to data access."

"OAT also provides Data Aware controls for the above that include...SVG based RDF Graph Control".

Only works in Opera and Firefow - IE doesn't support SVG.

"OAT is Open Source and GPL’ed over at sourceforge and the team has recently managed to incorporate our OAT data access layer as a module to dojo datastore."

Via Planet RDF.

Friday, July 07, 2006

Three More SW Applications


  1. FOAF to hCard via SPARQL "So I used the scutterplan from the FOAFBulletinBoard, going 2 steps, producing 17382 statements, containing I think it was 2035 foaf:Person nodes...To the results I applied sparql2hcard.xsl using xsltproc, script was sparql-hcard.sh (I do hope this was the latest SPARQL XML results format...), producing these hCards." XLST, querying - sounds like descriptors.

  2. Timeline "...a DHTML-based AJAXy widget for visualizing time-based events. It is like Google Maps for time-based information."

  3. iris: open your eyes to the future of the desktop "Iris is a java open source source integrated desktop environment including email, calendar, file browser, web browser, chat, and a data mining toolkit (clustering, indexing, and lots more)." Uses Jena.

Sunday, June 04, 2006

Burst of Links

Monday, May 22, 2006

World Wide VB

Two interesting talking points at the moment between Google's AJAX Framework and Continutations. Starting with, Continuations and GUIs, "...Web UIs are drastically constrained, offer a paucity of controls, and enforce a brutally linear control flow; and these are good things. I remember, in the early days, people saying “Once you know how to use one Windows app, you know how to use them all”. Ha ha ha. But you know what? Once you know how to use a browser, you are well on the way to being able to use most Web apps. The best AJAX apps are still very Web-like (as in, the Back button always works); but they’re faster and more responsive and nicer to look at. The worst AJAX apps are like bad Nineties VB."

This linked to: Continuations, cont’d "...there’s no need to drive a continuation bulldozer through your webapp, when a little REST garden spade will work quite nicely (and won’t tear up your lawn in the process). Don suggests that there may be other, more legitimate use cases for continuations outside of web applications, and I have no reason to disagree, but I would like to look at them pretty carefully."

The seed of the continued continuations conversation was, "Will Continuations continue?".

The Google Web Toolkit gets a reasonable overview, "GWT: Googles plain Java AJAX tools". This seems to be a similar approach taken by DWR 2.0 (out since late April) - using Java to write Javascript. DWR 2.0 also supports Jetty's AJAX continuations.

Update: So GWT is not like DWR. With DWR you still create your HTML and Javascript pages directly. With GWT you use widgets and lay them out like Swing - there's no direct access to the Javascript or layout. There is some criticism that this approach is at the wrong level of abstraction. One of the potential advantages is the ability to test drive the Java code and then deploy the Javascript - and hope that there are no bugs in only the Javascript version.

Tuesday, February 14, 2006

Yipee Yahoo

Yahoo User Interface "...a set of utilities and controls, written in JavaScript, for building richly interactive web applications using techniques such as DOM scripting, HTML and AJAX."

As well, Yahoo Design Patterns including a list of patterns for your AJAX or Web user interface such as: Autocomplete, Breadcrumbs, and Drag and Drop.

Looking forward to the faceted navigation and others.

Thursday, February 02, 2006

Hypercode - Beyond AJAX

There's nothing like combining two technologies together to produce something that sounds cool, Redfoot, "...can be best described as a webized Operating System. An operating system built around the notion of hypercode and where the persistence is built around the notion of an RDF Graph rather than a File Tree (see the namesys Graph vs. Tree). It provides standard web mechanisms to transport information across different machines and programmatically specifies the tasks for bundling and installing new software features across networked machines. The functions of Redfoot are analogous to that of an operating system kernel that manages resources across the web. To allow humans and other HTTP service agents to utilize Redfoot, it uses RDFLib and third party libraries such as Twisted and Kid to convert between RDF-based information and HTML or other popular formats. Therefore, each Redfoot server, is designed to interacting with a human, other redfeet, or any other HTTP-aware computing service. The design and implementation principles of Redfoot is to recursively utilize existing standards and libraries whenever and whereever it can, resulting in a highly compact, yet functionally rich execution kernel."

Hypercode "...is mainly designed as a portable database that helps both programmers and machines to exchange either executable or structured data...specifically utilizes RDF to capture both the structure and meaning of raw data in the XML-based global naming context, therefore, it has the potential to better utilize information in the code's execution context when necessary. In other words, Hypercode dosen't only treat Python or other scripting language as textual data, the defacto interpreter, Redfoot server, could adaptively leverage the supporting resources and execution policies defined in the associated RDF content to control the rights and behavior of script execution."

I was looking at O'Reilly's Twisted book this morning.

I don't know where I read this but it seems cool enough to download and try - like the Bookmark aspect.

Tuesday, January 10, 2006

Bookshelf of Bookmarks

Wednesday, August 31, 2005

AJAX and REST

Why I think AJAX breaks REST "The Web is a hypermedia application. According to REST, following a link you should be transferred to a state representation which is associated with a particular URI (in the case of the Web, a URL). As it happens, together with that state representation we may also get some code that our hypermedia document viewer (the browser) executes. Depending on the interactions with the end-user, another program, the environment, etc. the executed code may make use of asynchronous calls to change the represented state that our viewer has loaded. It does so by usually fetching more state, possibly in a REST-friendly way (i.e. HTTP requests). However, during the user-application interactions, the URI remains the same even though the state representation that is rendered on our screens has obviously changed. Now, some AJAX applications may force a change in the URI effectively simulating a state transition but most of the ones I have used do not."

REST is a way to expose services and AJAX is a way to write client software - they can't really effect one another.

AJAX can break the ability to save client state, in exactly the same way that frames do (complete with breaking the back button). AJAX applications may or may not update the URI in the browser to represent the current state it is in, but you can certainly write them so that they do (just like frames).

In a RESTful approach the architecture puts restrictions on the server, not how the client represents its current state:"...each request from client to server must contain all the information necessary to understand the request, and cannot take advantage of any stored context on the server."

Also, AJAX - beyond the buzzwords.

Update: Why I think AJAX breaks REST continued "What I did say is that the use of the AJAX approach to building distributed applications, or even just client-side ones, encourages a move away from the REST principles and that those building distributed applications should be aware of that...We just can't call all the good things out there RESTful."

I take REST principles to mean providing URIs to represent the current state they are in. However, I don't see browsers or client side applications as being RESTful or not. Tabs, frames, pop-ups, running code in Flash, Javascript, and applets; all of these things are not represented by the URI in the toolbar.

The only thing that's guaranteed in REST is that a client changes state when it goes to a URI (the representation of the state) on a server. How it represents that state is entirely up to it.

There are good reasons why everything just isn't represented by a URI, but I do think that more things should be. One is space requirements, imagine GMail storing every state that your mail box is in and providing the ability to go back and forward (very Xanadu perhaps).