Javier Albinarrate - LU8AJA

  • Increase font size
  • Default font size
  • Decrease font size



JSON (JavaScript Object Notation) is one of those dumb simple things, that existed for ages and, simply put, nobody thought of it as useful for quite a long time. Other serialization methods (talking here about data serialization, not objects with methods serialization, which is a bit messy) existed before, like PHP serialize(), Perl Storable, JavaScript JSON, etc but these were language specific. You have XML as well, which it is supposed to be the holy grail of data representation, but somehow it is not that holy... size, resources, parsing, etc make it a far from optimal solution. Then somebody thought "hey, JSON is quite simple, lightweight and easy to implement in any language", and he wasn't that wrong after all. Of course, JSON by itself has some limitations, but for almost anything it works like a charm, plus it was already implemented almost implemented natively in JavaScript (the unserialization can be done by a simple eval(), and the syntax validation by a regex) which is the key to the browser which in turn is the language behind any web based application frontend. 

That's enough for an introduction. Good resources for information are:

 Now... as I constantly use these technologies, along with XmlHttpRequest on the browser to process remote operations (before that I used hidden IFRAMEs with async Javascript), I built a "framework" which could hide the browser differences, and provide a standard implementation for doing RPC between PHP (or any other server side language) and JavaScript at the browser. When I standardized this (before that I used several custom implementations of JSON and XmlHttpRequest), I gave a good read to JSON-RPC which was already available, but a few features I wanted on the protocol were missing there (namely asynchronic operations), so I decided to go completely on my own, but keeping things similar to JSON-RPC. So, if there weren't enough JSON + XHR implementations, I created yet a new one... :) 




The framework has 2 files, one for client side the other for server side. lib.rpc.php and lib.rpc.jsWith these, you create 2 objects one in PHP the other in JavaScript.Once instantiated and configured, you reuse this object throughout the life of the script, to process whatever request you need.This allows you to put a lot more intelligence on the client side, lowering the resources required at the server side (something really important if you have hundreds of concurrent requests), and at the same time allowing you to limit the database access to whatever you wish, and still keeping the business logic on the safe server side. Of course, if you want to screw up things, you still can, like allowing the client side to send a query to be executed at the database, but as you should already be aware, you can ALWAYS screw up things, you just need to be stupidly inventive. 

Client side

In JavaScript you have an RPC_Engined object, which is used to process RPC_Transaction objects, which in turn can process n RPC messages.To put things simple, basically you will register a function or method on the Engine, then you will create transactions with the messages you wish, and the server will answer with other messages which may or may not correspond to the messages you sent (greatly depending on sync vs async). These messages are then processed one by one by the engine, and according to how you configured things, your functions/methods are called with the results. 

Server side

In PHP (and other languages if I get the need/chance to port it) you have another Engine object, where you register your functions/methods. These can be either regular functions/methods defined by the user, or can be specially prepared to receive certain parameters, in this way you can receive a lot more information, mainly about the environment and in turn have better error handling. Your function/method works with the information and returns the result/error. This result is packed with the transaction reply, and sent to the client. 

Asynchronic transactions

There are provisions on both sides, to execute and monitor asynchronic transactions. These rely on a forking mechanism, MySQL tables for holding information, and a high level script for the monitoring. All this may seem a mess, but it is needed to overcome the limitations of a short lived PHP script, especially in Windows which lacks the interprocess communications available in other OSes. However, I haven't used that in production for anything yet, it was done purely for the pleasure of programming. Also, implementing this on another language may be easier. 

The code

If you have seen the other projects in my webpage, you may find a pattern. I don't have much time, and I always have several projects going on, and putting in place tidy code for publishing takes time. So some time in the future (a few months?) I plan to publish it here the whole code, with a manual. In the meantime, a big sorry Frown, but if I can help you in something, just email me.



Last Updated on Friday, 18 July 2008 17:55  

Google Translate

English French German Italian Portuguese Spanish