SWX. La forma más sencilla de trabajar con datos en Flash

Wow, no había visto las noticias : )

Y en este caso estoy con Aral. Una cosa no influye demasiado en la otra. Y lo de la dudosa legalidad de SWX o AMFPHP es FUD del bueno. Me quedo con esto:

<fieldset>The key point here is this though: Those restrictions only apply if you agree to Adobe?s terms and read the spec.

I wrote the SWX assembler that creates the data SWFs without ever agreeing to the terms of the Adobe license for the Flash 8 spec and without ever reading the spec. Instead, I used a trusty hex editor (0xED), Flasm, and TextMate to decipher the SWF bytecode.</fieldset>

Hay por ahí alguno ( http://www.davidarno.org/2007/12/13/has-adobe-just-killed-swx/ ) que piensa que el BlazeDS de Adobe ( http://www.adobe.com/aboutadobe/pressroom/pressreleases/200712/121307BlazeDS.html ) acabará "matando" al SWX.

Aral Balkan, como era de suponer, defiende al SWX en http://aralbalkan.com/1109

Zárate

Pero vamos, si alguien lo ha probado extensamente estaría encantado de oirlo.

Lo he visto como una opción interesante, pero no la he probado.

Yo le eché un ojo hace tiempo, lo comenté en este post.

Además como en el curro trabajamos con dispositivos móviles, hice un pequeño test de rendimiento SWX vs XPath "pelao". Y ganó XPath : )

Es cierto que fué hace casi 9 meses y SWX seguro que ha avanzado un montón, pero en su momento yo no le vi ventaja. A ver si le vuelvo a echar un ojo al test de rendimiento con la nueva versión.

Dicho esto, la mayor desventaja que le veo es que SWX necesita obligatoriamente un servidor. Sin embargo xml normal solo necesita una URL. Si es en servidor bien. Si es local también. Eso ayuda mucho a la portabilidad.

Pero vamos, si alguien lo ha probado extensamente estaría encantado de oirlo.

Salud!