views:

77

answers:

2

As a personal project, I'm making an AJAX chatroom application using XML as a server-side storage, and JSON for client-side processing.

Here's how it works:

  1. AJAX Request gets sent to PHP using GET (chat messages/logins/logouts)
  2. PHP fetches/modifies the XML file on the server
  3. PHP encodes the XML into JSON, and sends back JSON response
  4. Javascript handles JSON information (chat messages/logins/logouts)

I want to eventually make this a larger-scale chatroom application. Therefore, I want to make sure it's fast and efficient.

Was this a bad design choice? In this case, is switching between XML and JSON ok, or is there a better way?

EDIT:

Two mechanisms prevent a big server load when fetching information from the server:

  1. An "event id" is assigned to each message/login/logout, so all that's sent back to the user is the events his client hasn't yet processed.
  2. When an XML file becomes too big, a new one is created.
+4  A: 

As far as I am concerned, JSON is always a good choice for async. data transfer, because it is not as bloated as XML is. I'd choose latter only if I want the data to be human readable, e.g. config files.

--- Edited: And remember: Serializing/deserializing XML is a performance issue and not particularly convenient for persisting web application data with high frequency access, while, as mentioned, using xml as config files is imo best practice.

Agreed. And I might suggest that part of the reason there are many PHP libraries for XML and few for JSON is that JSON is so much simpler that it doesn't need a lot.
ewall
Thank you. I didn't think using XML as storage would be bad practice, but after reading everything on the page, it's now clear in my mind why it is.
Michel Carroll
Actually, I disagree in XML being bad practice per se. You are right that it is indeed extensible; and it is not necessarily poor performance either (maybe it is on PHP -- I don't know -- but not for other platforms, like Java).I think using JSON as storage might be better; but it is not at all certain you should use normalized (relational) model for data. Many newer DBs (esp. so-called "nosql" distributes ones) use much simpler models, and most people indeed store content as XML or JSON within such databases.This is not to say you have to use XML, just that it is not always bad choice.
StaxMan
@StaxMan: I am afraid to insist on the fact that serialization/deserialization a hierarchical object is *always* an expensive process, no matter if you've got an XML or a JSON or whatever object. If you want performance, you must avoid this process.
+2  A: 

Both XML and JSON are good for inter-applications communication. In Javascript, JSON is much easier than XML to deal with, so that's what I'd recommend.

As for storage... both are terrible as large datastores I'm afraid. MySQL would work better than editing a file, but it's still not an appropriate solution for a chat, especially if you're on a shared host. You may want to take a look at SQLite, perhaps creating one file per chat room.

Josh Davis
+1 for recommending a database.
tstenner
Thank you. When I'm ready to scale this application, I'll take a look at SQLite.
Michel Carroll
To be honest, no matter the database you'll run into performance and/or concurrency problems if you ever scale to as little as a thousand users, at which point you'd have to consider a chat server. Anyway, if you go the MySQL way, here's my tip: use PDO so that you can transition to another DB transparently.
Josh Davis