Different kinds of serialization of data are possible.

AHAH

Return prerdendered HTML from server:

• less effort in client +
  
• data not really reusable in client -
• data to serialization overhead great -
• no parsing needed +

Json

return a javascript object noted as javascript and eval it.

• using eval in client -
• data to serialization overhead small +
• data optimal reusable ++
• no parsing needed +

Xml

Generate a XML Format and use a clientside logic to use the data via dom operations.

• dom parsing of data slow -
  
• data to serialization overhead great -
• data good reusable +
• xml parsing needed -

WDDX

Wddx has its origins in Xold Fusion and is a XML Format to serialize and deserialize Data and Objects. PHP has wddx support.

• wddx in js slow & not usable for large datasets --
  
• data to serialization overhead great -
• data good reusable +
• xml parsing needed -
• ease of use +

Soap

Even webservices can be used. Objects are invoked from webservices.

• data to serialization overhead great -
• data optimal reusable ++
• xml parsing needed -

No Serialization

Data comes unserialized from server as text and is passed into a string.

• fast data -> js ++
• no serilalization +
• data reusable +
• no xml parsing needed +
• only one result and value can be used --

With a little help from e-voc i made the json serializer work.
No well go soon to be async and the all will be much better.

Besides i started work hard on the integration of jsobjects. I guess ill have to rewrite some of the code to make it work w.o. evil eval.
The grid example is still simple, dropping notices etc .. but the api is growing. I dont have this much time, bus as ill make pnAjax a important component on the pncommerce project, reusing the grid and the tree for basic gui layout, it will get a lot of commits anyway.

The big Ajax discussion has come in place to postnuke. Again it looks like writing down things, instead of write code in the first blink of an idea is considered to be a bad thing there. Markwest requested a unified ajax Project for the postnukeworld, but i guess that will not take place .. why ?

The Approaches are too different

Chestnuts Ajax example is
- not using serialization
- relies on handcoded servers
- has no framework components
- has no event model catching errors from the serverside

Frank Schummertz pnForum Stuff:
- is using AHAH data (returning HTML instead of XML or serialized data
- relies on handcoded servers
- has no framework components
- has no event model catching errors from the serverside

pnAjax
- uses json data serialization
- has a tested gui kit / framework
- relies on no handcoded server to use ajax funcs on the client
- has a event model catching errors from the serverside

Anyway, i am really opposing doing 3 times the same work, but as i see from the mailing list postings, there is a request for a lot of functionality that is already in pnAJax. So i guess it was worth the time to sit down and thing of a framework that can totally integrate with postnuke instead of building stuff on top, that might be sexy, but is ugly code.

You migth call me a thread , but if there is no movement twoards a performant approach for the data stuff and nothing more that, hey, integrate scriptacolous into postnuke, Ill not be the one to jump in and make the lead on such a project .. ill guess it takes a year to explain to others what they need to develop .... pnAjax is rather complex on the code side of the project development ... but easy to use for the final developer, implementing his own apps with just a buch of loc.