SWX - Een kritische gedachte

[TheDutch]

Hoi,

De laatste tijd horen we veel over SWX, het SWF Data Format ontwikkeld door Aral Balkan. Een geschenk uit de hemel of een doorn in het oog? Graag wil ik met jullie mijn mening delen omtrend dit nieuw formaat.

De volgende punten wil ik graag bespreken:

1. SWX Inleiding
2. Doelgroep
3. To hack or not to hack?
4. Toekomst
5. Conclusie

1. SWX Inleiding
SWX is zoals gezegd het nieuwe formaat ontwikkeld door Aral Balkan om data uit te wisselen tussen Flash en een applicatie server zoals PHP. Het formaat wordt weggezet als dé nieuwe manier om eenvoudig data uit te wisselen, zo gezegd een geschenk uit de hemel voor de Flash Community. Maar is dat wel zo?

Zo werkt SWX:

// Initialize SWX for PHP
org.swxformat.PHP.init();

// dataHolder is a movie clip on Stage.
dataHolder.className = "Simple";
dataHolder.method = "echoData";
dataHolder.data = [ 'data', 'to', 'send' ];

dataHolder.loadMovie("http://localhost:8888/swx/trunk/php/swx.php", "POST");

// A very simple check for returned data
function onEnterFrame()
{
debug_txt.text = "Data: " + dataHolder.data;
}


2. Doelgroep
Voor designers die werken aan kleine tot middelgrote projecten is SWX een zeer handig formaat om als communicatie laag te gebruiken tussen Flash en de data aan de achterkant. Deze groep is reeds gewend om met loadMovie() assets in te laden en dus is dit voor hen snel op te pakken om data uit een PHP class mee in te laden. Voor serieuze (beginnende) programmeurs is het echter ten zeerste af te raden van SWX gebruik te maken! SWX is programmeer technisch geheel onlogisch en maakt de boel voor programmeurs alleen maar verwarrend vooral in groot teamverband. Daarnaast leren beginnende programmeurs op een verkeerde manier om te gaan met het inladen van data, iets wat later in zijn of haar carieere mogelijk kan opbreken.

Aangezien remoting niet beschikbaar is voor Flash Lite is SWX daar zeker wel een goede toepassing voor.

3. To hack or not to hack?
Eén van de eerste dingen die je leert als programmeur is om alleen in echte noodzaak gebruik te maken van hacks. Een hack is het misbruiken van middelen om iets voor elkaar te krijgen wat standaard niet mogelijk is. SWX is zo'n hack! Het misbruiken van loadMovie() om data binnen te halen en het gebruik van het verouderde prototyping binnen SWX om functies toe te voegen aan standaard objecten zorgt ervoor dat het van mij deze benaming krijgt. Daarnaast maakt het ook nog gebruik van onEnterFrame om te kijken of de data al binnen is. Van de slogan "You loadmovie() your data!" gaan mijn nekharen al overeind staan. Als we het hebben over bad-practices dan heeft SWX er een hele hoop. Dit geldt natuurlijk alleen maar voor het gebruik van SWX met Flash en niet met Flash Lite. Flash Lite loopt namelijk nog generaties achter op Flash en kan zeker van SWX profiteren.

4. Toekomst
Heeft SWX toekomst? In mijn ogen niet. SWX is zoals reeds gezegd gebasseerd op oude technologie (ActionScript 1.0) en op hacks, wat het krijgen van een draagvlak bemoeilijkt. Daarnaast kan SWX door die hacks (nog) niet worden gebruikt binnen ActionScript 3 projecten. Ik ben zeer benieuwd hoe Aral Balkan dit zal gaan oplossen.

Het Flash platform groeit als kool! De overgang van ActionScript 2.0 naar ActionScript 3.0 is een grote stap richting meer professionaliteit binnen het Flash Platform. Wanneer je met ActionScript 2.0 nog vrij kon scripten zal je met ActionScript 3.0 echt moeten programmeren. Gezien de basis van SWX zal het de groei van het Flash Platform moeilijk kunnen bijhouden en het bestaan mogelijk niet lang kunnen volhouden. SWX groeit niet mee met de professionalisering van het Flash Platform.

Hoeveel Flashers hebben moeite met OOP in ActionScript 2.0? Veel! Hoeveel Flashers waren enthousiast toen Aral Balkan SWX presenteerde? Veel! Waarom? Omdat de gemiddelde Flasher geen echte programmeur is en moeite heeft de materie te begrijpen. Dat is ook de reden voor Aral Balkan geweest om SWX te ontwikkelen. Echter zet je dan stappen terug i.p.v. vooruit. Het Flash Platform zal als maar sneller blijven doorgroeien en het wordt steeds lastiger voor Flashers om het bij te houden. We erkennen allemaal dat het voor veel mensen moeilijk is, maar hoe help je dat soort mensen? Doe je dat door ze het te proberen te leren of doe je dat door ze te laten zitten met de achtergelopen kennis en ze een formaat als SWX onder de neus te leggen?

SWX helpt de Flashers niet de groei van het Flash Platform bij te benen, het geeft ze alleen maar nog meer afstand en daarmee wordt het gat alleen maar groter. Om die reden heeft SWX in mijn ogen geen toekomst en is het gebruik van SWX gevaarlijk voor je eigen positie in de markt.

5.Conclusie
Mijn conclusie is dat SWX toen het gepresenteerd werd al verouderd was. SWX zal de groei van het Flash Platform moeilijk kunnen bijhouden en trekt daar gebruikers in mee. Ik zal het een ieder afraden te gebruiken voor andere projecten dan Flash Lite projecten.

Er zijn al meer programmeurs (waaronder de maker van AMFPHP (http://www.5etdemi.com/blog/archives/2007/03/swx-a-bad-idea/)) geweest die SWX hebben bekritiseerd. Het is begrijpelijk dat Aral Balkan trots is op zijn product, hij heeft er immers veel tijd in gestopt, alleen zou het hem niet misstaan wanneer hij zich wat minder verdedigend zou opstellen richting dit soort kritiek. Daarnaast zou ik het persoonlijk fijn vinden wanneer SWX wat minder enthousiast in de community gezet wordt omdat het helemaal niet zo geweldig is als hij het doet laten overkomen.

Gr,
Erwin

[BernardV]

Ik ben het helemaal met je eens, SWX heb ik nooit echt bekeken alleen al om het feit dat het met loadMovie() data laadt. Los van het feit dat Flash Lite er zeker van kan profiteren, is er totaal geen toegevoegde waarde. Waarom zou je geen gebruik maken van remoting, XML of zelfs loadvars?
Nu hoor je dan als reactie dat je complexe types kunt gebruiken om te laden. Ja, maar dat kun je ook en beter met remoting en daarbij wil je helemaal geen complexe types, tenminste zo min mogelijk. Dit alleen al om je systeem zo transparant mogelijk te houden.

Al met al een mooi stuk TheDutch!

[TheDutch]

Thanks BernardV! :)

Complex types zijn in bepaalde gevallen natuurlijk wel enorm handig. Hele recordsets doorgeven van PHP naar Flash, hele arrays met objecten, of zelfs class instanties. Maar dit is meest van tijd alleen van toepassing bij de grotere projecten. Projecten die geen gebruik gaan maken van een formaat als SWX, maar Flash Remoting gebruiken via AMFPHP bijvoorbeeld. SWX is voor dezelfde doelgroep die net zo goed LoadVars of XML kan gebruiken. Buiten Flash Lite zie ik daarom net als jij niet het doel van complex types via SWX.

Maak dan een wrapper API die Netconnection wat eenvoudiger maakt voor beginners of (eventueel samen met) een Flash IDE Component waar je eenvoudiger een verbinding kunt maken met een AMFPHP. SWX is achter de feiten aanlopen.

[Folkert]

Dan wil ik graag daarop ook mijn mening even kwijt door te reageren op de punten:

1. SWX Inleiding
2. Doelgroep
3. To hack or not to hack?
4. Toekomst
5. Conclusie

1. SWX Inleiding
SWX is SWF Bytecode oftewel Native flash(Objecten Arrays String etc).
Verder in tegenstelling tot je code even hoe SWX (zonder Actionscript Library gebruik) wel werkt.

Even de laatste twitters uit de public gateway halen

//loader is de instancenaam van een movieClip op of naast je stage
loader.serviceClass = "Twitter";
loader.method = "getPublicUpdates";
loader.debug = true;
// Argumenten in JSON format, handmatig als je niet de
//simpele of volledige SWX APIs gebruikt.
loader.args = "[" + 1 + "]";
loader.loadMovie("http://swxformat.org/php/swx.php", "GET");

// A very simple check for returned data
function onEnterFrame()
{
//even de laatste update laten zien
debug_txt.text = "Data: " + loader.result[0].text;
}


Uiteraard ga je dit niet willen als Flash Developer en zeker niet als leerproces bij het leren van OOP. Je kan echter simpel de ActionScript API gebruiken en dan bijvoorbeeld de code zo produceren.

import org.swxformat.SWX;
// Maak het SWX object.
swx = new SWX();
swx.gateway = "http://swxformat.org/php/swx.php";
swx.encoding = "GET";
//debug aan om data in de analyzer te zien
swx.debug = true;
// Voeg de 'method' eigenschappen toe.
var methodParameters:Object =
{
serviceClass: "Twitter",
method: "getPublicUpdates",
args: [1],
progress: [this, progressHandler],
result: [this, resultHandler],
timeout: [this, timeoutHandler]
}
// Doe de SWX call.
swx.call(methodParameters);
/*
de event Handlers
*/
function progressHandler(event:Object)
{
trace (event.bytesLoaded + " van de " + event.bytesTotal + " geladen...");
}
function resultHandler(event:Object)
{
var res = event.result;
trace ("Door:"+res[0].user.screen_name+" :: " + res[0].text );
}
function timeoutHandler(event:Object)
{
trace ("De data call timed out voor loader: " + event.target);
}
2. Doelgroep
Je doet hier voorkomen of beginnende programeurs niet kennis maken met Remoting, XML, LoadVars etc als ze in aanraking komen met SWX. Dat is uiteraard onzin. Verder is op dit moment de hoofd doelgroep zoals je al aangaf Flash Lite, en designers en developers (zoals ik) die het een prachtig iets vinden.

Technische helemaal niet onlogisch je werkt met Native data (meer simpel kan je niet hebben). Door de nog niet bekendheid en de jonge leeftijd van SWX heb je een klein punt bij het grote team verband verhaal. Ook hierin is 1 en ander te verbeteren omtrent SWX.

3. To hack or not to hack?
Je eerste stuk is wat makkelijk. SWX is een hack omdat JIJ vind dat loadMovie niet voor data verkeer gebruikt moet worden. Met name jij zou toch moeten weten dat Flash en Flex en bijna elk program vol zit met hacks, check anders even wat source classes in Transition of for that matter in de Services.

Jammer dat je valt over de enterFrame omdat deze enkel de simpelheid van SWX aantoont. Natuurlijk gebruik je de SWX Library wanneer je echt met SWX aan de slag bent (gaat). Van de slogan "You loadmovie() your data!" denk ik nog steeds OLEEJ.

Flash Lite is uiteraard een hele goede gegadigde.

4. Toekomst
Heeft SWX toekomst? In mijn ogen wel. SWX is Native en dus heeft het draagvlak.
ActionScript 3 versie is onderweg. Houd even rekening met het feit dat het jong is en net als andere projecten aan het groeien is.

"Het Flash platform groeit als kool! De overgang van ActionScript 2.0 naar ActionScript 3.0 is een grote stap richting meer professionaliteit binnen het Flash Platform." Helemaal mee eens.

"SWX groeit niet mee met de professionalisering van het Flash Platform"

Vette onzin zoals je wellicht zelf ook wel begrijpt. Aral Balkan is niet 1 van de zovelen en heeft in die zin dacht ik wel wat meer credit verdient. Ik denk dat SWX wel degelijk met de tijd en as versies mee kan. Maar goed dat zal de tijd leren.

"Hoeveel Flashers hebben moeite met OOP in ActionScript 2.0? Veel! Hoeveel Flashers waren enthousiast toen Aral Balkan SWX presenteerde? Veel! Waarom? Omdat de gemiddelde Flasher geen echte programmeur is en moeite heeft de materie te begrijpen. Dat is ook de reden voor Aral Balkan geweest om SWX te ontwikkelen. "

Kan je uit eerste hand zeggen dat dit niet 'DE' reden is van het bestaan van SWX. Met name het niet aanwezig zijn van Remoting voor Flash Lite en de ergernis van al die Remoting classes, dat zijn meer de redenen van het ontstaan. Dat het vervolgens ook in gewone Flash Applicaties erg handig is dat is winst ;)

"Doe je dat door ze het te proberen te leren of doe je dat door ze te laten zitten met de achtergelopen kennis en ze een formaat als SWX onder de neus te leggen?"

Volgens mij kan je beter even geduld betrachten en de officiele Internet Drafts en dergelijke afwachten. SWX afschilderen als achterhaalt is wel vaag zeker als je nagaat dat er hard aan gewerkt word en dat de as3 versie gewoon aanstaande is. Daarnaast gebruik ik momenteel SWX gewoon in OOP omgeving as2 en straks met veel plezier in as3.


"Om die reden heeft SWX in mijn ogen geen toekomst en is het gebruik van SWX gevaarlijk voor je eigen positie in de markt."

Ai ai daar gaat mijn positie ;) Gelukkig heb ik, en vele anderen, volle vertrouwen in de ontwikkeling van SWX.

5.Conclusie
Mijn conclusie is dat SWX toen het gepresenteerd werd al erg handig was voor met name Flash Lite maar ook voor Actionscript 2 projecten. SWX zal de groei van het Flash Platform zeker kunnen bijhouden en trekt daar gebruikers in mee. Ik zal het een ieder aanraden het te bekijken, te testen en te gebruiken ook in voor andere projecten dan Flash Lite projecten.

Daarnaast zou ik het persoonlijk fijn vinden wanneer SWX wat enthousiaster in de community gezet wordt. Aangezien het een prima en simpele manier is die in verhouding met Remoting, XML, loadvars etc een prima alternatief is.

ps: Erwin je snapt wel dat ik je niet persoonlijk aan wil vallen hiermee echter ik reageer omdat je de persoonlijke aanval op SWX opent en in het artikel laat zien dat je er NET Niet goed genoeg naar gekeken hebt (getuige je links naar artikelen van begin van het jaar en je voorbeeld code). Zoals je kan lezen zie ik het net even wat anders.

[TheDutch]

Folkert,

De SWX Library (ActionScript API) is op zo'n manier complex dat de Flashers net zo goed AMFPHP via de remoting classes kunnen gebruiken. Daar heeft SWX totaal geen voordeel in.

Ik zeg dat wanneer Flashers in aanraking komen met SWX dat ze dan de dingen op een verkeerde manier leren. Tuurlijk komen ze ermee in aanraking met remoting etc, maar je kunt dingen op verschillende manieren leren, je hebt goede manieren en slechte manieren, en de manier hoe SWX het presenteert valt bij mij onder een slechte manier. SWX wijkt namelijk te veel af van de standaard (lees: hoe het over het algemeen werkt) en maakt misbruik van (verouderde) functionaliteiten.

Ik vind het een hack omdat het prototyping gebruikt om functies aan objecten toe te voegen terwijl dit al sinds ActionScript 2.0 verouderd is. Daarnaast is loadMovie() nooit gemaakt voor data verkeer zoals SWX het nu gebruikt. Dat is fout en maakt misbruik van de functionaliteit. Dat is niet alleen mijn mening, dat is een algemene mind-set binnen de programmeer wereld. De sources voor classes mx.transitions en mx.services zijn naar mijn weten niet openbaar, graag hoor ik van jou waar ik die kan inzien. Daarnaast gaat het er hier niet om wat voor een soort hacks Adobe wel of niet gebruikt, we hebben het nu over SWX.

De simpelheid van SWX is juist het paradepaardje waarmee het voet aan de grond moet krijgen. Wanneer onEnterFrame daar deel vanuit maakt dan bekritiseer ik dat, niet omdat het simpel is maar omdat het terug in de tijd gaat en erg bad-practice is hedendaags.

Draagvlak heeft niets te maken met of iets native is. Het heeft alles te maken met hoe het wordt neergezet en wat de mogelijkheden zijn. Natuurlijk is Aral bezig met een ActionScript 3.0 versie, maar die moet op zo'n manier verschillen van de huidige versie dat ik erg benieuwd ben naar het resultaat. Ik zie het niet snel komen, en als het dan toch komt dan ben ik benieuwd in welk opzicht het dan nog "beter" is dan de andere mogelijkheden zoals AMFPHP.

Dat ik denk dat SWX niet mee kan gaan met de groei van het Flash Platform is niet "vette onzin!". SWX loopt of achter de feiten aan (dan refereer ik naar dat loadMovie() verhaal) of het komt op hetzelfde neer als AMFPHP en biedt weinig meerwaarde omdat het niet minder complex is. Voor SWX in zijn huidige vorm zie ik dan ook geen langdurige plek in de Flash Community.

Als er aan een techniek hard gewerkt wordt wil dat nog niet zeggen dat waar aan gewerkt wordt niet achterhaald is. Laat die ActionScript 3.0 versie eerst maar eens komen, dan praten we erover verder. Dat jij SWX gebruikt in OOP is me geen verassing, ik heb ook nooit gezegd dat dit niet kon. Wel goed mijn woorden lezen hoor ;).

Ik ben blij voor Aral dat er mensen zijn die wel de volste vertrouwen hebben in SWX. Op een gegeven moment krijg je toch drie kampen in de Flash Community, de Die Hard programmeurs, de designers, en alles wat daar tussenin zit.

Jouw voorbeeld (de simpele variant) van SWX verschilt nauwelijks van mijn voorbeeld dus ik zie niet in hoe dat mijn kennis van de werking van SWX minder betrouwbaar kan laten zijn. Daarnaast link ik naar een artikel van de maker van AMFPHP die kritiek heeft op SWX. Dat dit artikel 6 maanden oud is doet weinig te zaken, de kritiekpunten gelden nog steeds en ook hier zie ik ook niet waarom dat minder betrouwbaar zou moeten zijn dan een artikel van gisteren.

Als laatste wil ik even zeggen dat ik Aral Balken niet meer credits geef dan ieder ander. Hij is voor mij gewoon een programmeur met een bepaalde kennis. Wanneer iemand iets goeds heeft neergezet dan spreek ik daar lof over. Wanneer iemand iets heeft neergezet wat ik minder goed vind dan spreek ik daar mijn kritiek over uit. Wel zo eerlijk :).

[BernardV]

Als ik deze codes zo bekijk is het (in mijn ogen) nog makkelijker te doen om bv de laatste twitters te laden met AMFPHP.
Immers is de JSON API van twitter gewoon aan te roepen en dus ook makkelijk naar een AMFPHP service om te zetten.
Wat ze alleen bij swx leuk doen is API's laten schrijven door mensen zodat die gebruikt kunnen worden, immers zo kan iedereen een twitter lezen. Dit is natuurlijk ook met AMFPHP of wat dan ook te doen.

[TheDutch]

Ze maken inderdaad handige API's zodat Flashers zonder veel omkijken Twitter of Flickr kunnen aanroepen. Daar ben ik dan wel weer positief over :).

[Folkert]

Wat SWX doet is de resultaten omzetten in bytecode zodat je een native swf bestandje terugkrijgt. De hack erin is dat de bytecode wordt geschreven niet meer niet minder. Er komen overigens geen prototypes aan te pas, of ik heb ze althans nog niet gevonden.

Ik zie er in ieder geval niet meer kwaad in dan in de alom gebruikte hacks in verscheidene programma's inclusief Flash. Daarover verschillen we dan ook van mening. Wellicht leuk discussie punt voor een andere draad.

[Ea.Z]

Ik ben geen zo'n hardcare developer als jullie allemaal dus denk ik dat mijn standpunt weleens interessant kan zijn. :p

Toen ik in meerdere presentaties van Aral aanwezig was vertelde hij over LoadVars, Remoting, en XML... Hij vroeg toen 'Wie vind werken met XML in AS2 een leuke ervaring?'

Ik stak mijn hand op... Als enige... Ik vond meteen de rest van het publiek oerdom...
Wat hebben we in AS2?
LoadVariables: Achterhaald.
LoadVars: Redelijk goed, maar je moet alles gaan serializen
Remoting: Te ingewikkeld, je hebt een server nodig... veel tralala... Ook voor minieme toepassingen.
XML: Simpel, universeel, en niet extreem ingewikkeld. Makkelijk te genereren, makkelijke om te navigeren, wordt veel gebruikt: RSS overal, iTunes library, etc... Kost niets. Als ik naar de rest kijk: XML IS MAKKELIJK!
Maar wat voor techniek gebruiken anderen dan!? Als XML een pain in the.... is? :p
Dusja: in mijn ogen was XML makkelijk.

Toen kreeg ik swx te zien: Gewoon je results ophalen, en returnen. In flash gewoon benaderen, makkelijker dan XML, en simpeler. Erg leuk om mee aan de slag gaan, en het is gratis! Waarom niet? Op dat moment was ik echt vertrokken met SWX.

Nu ik wat begaan ben met AS3 is SWX weer geen optie meer. Ook is het zo dat XML in AS3 echt makkelijk en snel gebruikt kan worden. Momenteel zie ik niet veel voordelen die SWX in AS3 kan voortbrengen.

Het sterkste van SWX momenteel is dat het werkt op Flash Lite. Voor mobile apps is het dus zeker een oplossing, maar dat moet ik niet meer vertellen :)

Momenteel ben ik niet meer echt bezig met SWX gezien ik meer gebruik maak van XML (waardoor ik mijn php files niet moet herschrijven van de vorige versie van mijn projecten, naar de volgende (van AS2 naar AS3 dus)).

mijn conclusie: SWX was een echte oplossing for all my troubles toen ik alleen met AS2 werkte. In AS3 zie ik er niet meteen een invulling voor.

Dat neemt niet weg dat ik SWX een heel tof project vind en het op de voet volg.

[TheDutch]

Wat SWX doet is de resultaten omzetten in bytecode zodat je een native swf bestandje terugkrijgt. De hack erin is dat de bytecode wordt geschreven niet meer niet minder. Er komen overigens geen prototypes aan te pas, of ik heb ze althans nog niet gevonden.

De prototyping hack zat in het PHON gedeelte dat nu is vervangen door JSON. Slimme zet overigens! Laten we vanaf nu dus niet meer over hacks spreken :).

Het probleem bij SWX zit 'm erin dat SWX (via de simpele mode) de gebruiker data laat verzenden en inladen via loadMovie(). Tuurlijk het werkt en het resultaat is prachtig, maar je leert Flashers op een verkeerde manier met instrumenten omgaan. Het gebruik van loadMovie() is onlogisch en heeft in de verste verte een overeenkomst met hoe het over het algemeen wordt aangepakt. Veel Flashers hebben al een achterstand en op deze manier blijft dat alleen maar. Je geeft ze een middel om op het huidige niveau te kunnen blijven functioneren i.p.v. dat je ze helpt die drempel over te gaan.

De SWX ActionScript Library gebruikt ook loadMovie() maar daar maakt het me eigenlijk helemaal niets uit, dat gebeurd namelijk achter de schermen. De gebruiker heeft daar over het algemeen helemaal geen weet van. Voor wat ik heb kunnen zien van de SWX ActionScript Library ziet dat er beter uit (al zou ik het één en ander anders hebben aangepakt) en meer zoals we gewend zijn om met RPC om te gaan. Echter in hoeverre verschilt het dan nog van een Flash Remoting? Voor SWX moet je ook bestanden op de server installeren net zoals bij Flash Remoting en AMFPHP. Oké SWX kan de data grootte doorgeven zodat je een mooie preloader kunt maken. Maar het enige moment wanneer je over het algemeen wat langer zit te wachten is wanneer de server de berekeningen aan het uitvoeren is of SQL de data aan het ophalen is, data uploaden naar de client is in de meeste gevallen geen probleem (uitzonderingen daar gelaten) en gaat razendsnel. Noem mij eens de vele voordelen op van de SWX ActionScript Library over Flash Remoting in Flash (dus niet Flash Lite want die zijn duidelijk). Ik zie ze namelijk niet echt :).


Ik zie er in ieder geval niet meer kwaad in dan in de alom gebruikte hacks in verscheidene programma's inclusief Flash. Daarover verschillen we dan ook van mening. Wellicht leuk discussie punt voor een andere draad.
Folkert, je hebt het steeds over hacks in andere programma's. Het kan me eerlijk gezegd voor dit onderwerp geen ene moer schelen wat anderen doen in andere programma's. Maar je blijft erover beginnen dus zou ik graag van jou de voorbeelden willen zien die in Flash zitten. Het is nu de tweede keer dat ik je vraag deze te overleggen. Graag dus meer info daarover!

Het is van mijn kant geen persoonlijke aanval op jou of op SWX. Ik heb gewoon mijn vraagtekens bij SWX en die gooi ik hier open voor discussie. Ik snap dat je erg betrokken bent bij het SWX project maar kritiek of meningen van anderen kunnen soms verhelderend werken ;).

[TheDutch]

Ik stak mijn hand op... Als enige... Ik vond meteen de rest van het publiek oerdom...

Het zegt in elk geval veel over jouw kunnen ;).


Remoting: Te ingewikkeld, je hebt een server nodig... veel tralala... Ook voor minieme toepassingen.

Dat heb je volgensmij ook nodig voor SWX (server bestanden en client classes).


Toen kreeg ik swx te zien: Gewoon je results ophalen, en returnen. In flash gewoon benaderen, makkelijker dan XML, en simpeler. Erg leuk om mee aan de slag gaan, en het is gratis! Waarom niet? Op dat moment was ik echt vertrokken met SWX.

Heb je ooit Flash Remoting weleens volledig neergezet en laten draaien voor een project? Ik ben gewoon benieuwd of mensen die werkelijk Flash Remoting via bijvoorbeeld een AMFPHP hebben gebruikt ook zo enthousiast zijn over SWX en dit verkiezen boven Flash Remoting.


Het sterkste van SWX momenteel is dat het werkt op Flash Lite :).

Wanneer het was neergezet als Flash Remoting voor Flash Lite had ik heel anders over SWX gedacht. SWX is inderdaad voor Flash Lite geweldig! :)

[BernardV]

Heb je ooit Flash Remoting weleens volledig neergezet en laten draaien voor een project? Ik ben gewoon benieuwd of mensen die werkelijk Flash Remoting via bijvoorbeeld een AMFPHP hebben gebruikt ook zo enthousiast zijn over SWX en dit verkiezen boven Flash Remoting.

Nou daar kan ik je geen antwoord op geven, maar ik heb nog niet zo lang geleden een site met foto's moeten maken waarbij ze de foto's dus op basis van de exif timestamp wilden sorteren op datum.
Resultaat: http://www.dutchsnowtimeweek.com/
Draait op AMFPHP, het opzetten van AMFPHP was niet veel werk, sterker nog de basis (zonder transities etc) draaide in flash binnen 6 uur (dit is inclusief AMFPHP opzetten).

//EDIT: Wat ik hiermee bedoel te zeggen, dat ik betwijfel of je dat ook zo snel/sneller met SWX zou kunnen doen.

[Folkert]

Okee we houden op over hacks te praten. Voor flash bijvoorbeeld check bv deOnEnterFrameBeacon (http://www.darronschall.com/weblog/archives/000082.cfm)

Verder blijft het grote voordeel dat je met native data werkt, i know, klinkt saai en als repeater maar dat is het grootste voordeel voor de flash kant.
Doordat er een public gateway is hoef je niet net als bij remoting dingen op je server te zetten. Dat voordeel valt uiteraard weg als je eigen services en een eigen endpoint wilt draaien. Gelukkig dan ook dat je die Services evengoed via AMFPHP kan roepen alswel via XMLRPC of JSON.
Om met de woorden van Aral zelf te spreken om het bestaan van SWX te rechtvaardigen:
Aral Balkan: As such, we can compare SWX to AMF (the data format) and SWX RCP to Flash Remoting (the RPC protocol) and SWX PHP (my PHP implementation of SWX RPC) to AMF PHP.

So the real question becomes, does the Flash Platform need a new data format and a new RPC protocol? I believe it does and here are some reasons why:

* Existing formats are non-native, complicated, require parsing and/or writing plumbing code e.g., XML, variable-encoded strings (LoadVars, loadVariables), Flash Remoting, etc.
* SWX files have low processor overhead when parsed by the Flash Player as they are native (SWF bytecode)
* SWX RPC is the only RPC solution for Flash Lite 2.0 and 2.1 (and thus for mobile Flash applications). Flash Remoting does not work with Flash Lite.
* Most important: SWX, being native, has inherent advantages such as cross-platform data exchange (via allowDomain support for SWF files), simplicity (no ActionScript library is necessary to use it), etc.


Ik snap je punt overigens wel Erwin over dat je bang bent dat nieuwe developers verkeerd leren omdat het via loadMovie data laden een punt is waarop je die vraagtekens kan zetten.
Blijf ikzelf anders over denken zeker gezien het gebruik van loadMovie in persoonlijke ervaring. Maar goed ik zie je punt daar.

Dus nogmaals grote voordeel is de native data, direct te gebruiken. en uiteraard de FlashLite oplossing.

De nieuwe echt handige Format van SWX (SWF Bytecode) rechtvaardigt wat mij betreft volledig zijn/haar bestaan. Maar goed nu ga ik mezelf herhalen ;)

[BernardV]

Ik snap je (volgens mij) prima Folkert.
Wat ik alleen nog steeds niet snap zijn de argumenten voor SWX.
Dat het native is, ja klopt, maar flash bytecode bevat ook AMF, immers dat is de manier van "data" opslag in flash. Ik ben nu bezig in AS3 via bytecode swf's te genereren en dat is zeker leuk werk! Video embedden draait al! Maar als ik dit zo bekijk is het een beetje overdone, want het voegt geen functionaliteit toe (flash lite buiten beschouwing).
De cross-platform data exchange die aangehaalt wordt is ook alleen leuk als er een losse swf met data staat en die niet geupdate wordt, moet deze geupdate worden heb je nog steeds te maken met een server die via PHP de swf bytecode genereert. Zo kun je dus ook prima een AMFPHP service aanzetten met een crossdomain..
De low overhead vind ik een heel discutabel punt, want waar wil je de load hebben.. de ene seconde extra bij de client of de seconde op de server ;), niet dat AMFPHP geen load genereert, in tegendeel, maar dat is niet de discussie..

[TheDutch]

Folkert, ik moet je zeggen dat ik de punten van Aral Balkan, behalve over Flash Lite natuurlijk, erg zwak vind en kloppen doen ze ook niet altijd. Graag geef ik een meer uitgebreide reactie vanavond, dan ga ik ook in op jouw eigen reactie :).

[Ea.Z]

Het zegt in elk geval veel over jouw kunnen .
Ik ben geen zo'n hardcare developer als jullie allemaal dus denk ik dat mijn standpunt weleens interessant kan zijn.
Antwoord dan op de vraag en zeg me welke manier van data loaden er nog meer zijn. LoadVariables(num) >deprecated Loadvars XML Remoting
Remoting schijnt heel goed, en krachtig te zijn, maar voor een gemiddelde AS'er (zoals ik) is Remoting gewoon te complex/ingewikkeld.
Geef maar toe dat XML voor deze doeleinden EASY en niet veeleisend is!
SWX is nog 1 stap dichter naar makkelijk, en maakt het benaderen/navigeren door je gegevens heel erg makkelijjk, omdat je objecten, of arrays krijgt, ipv het hele childeren gedoe.

Mijn kunnen is hier idd erg beperkt en bij de meeste mensen die voor SWX gaan is dat toch juist de reden WAAROM ze voor SWX gaan en niet voor remoting: Simplicity.

Verder kan het goed zijn dat je ook bestanden op de server moet installeren. Moet er zelfs geen extra Remoting service op de server draaien? Ik weet het niet. Ik weet alleen dat het op mijn server draait, en ik het niet gebruik :p

[TheDutch]

Antwoord dan op de vraag en zeg me welke manier van data loaden er nog meer zijn.

Het was een compliment...


LoadVariables(num) >deprecated Loadvars XML Remoting

FlashVars? :P.
Volgensmij heb je ze allemaal opgenoemd.


Remoting schijnt heel goed, en krachtig te zijn, maar voor een gemiddelde AS'er (zoals ik) is Remoting gewoon te complex/ingewikkeld.

Flash Remoting is qua ActionScript niet meer complex dan de SWX ActionScript API. Probleem met Flash Remoting is dat het nooit toegankelijk is neerget en vooral onder de aandacht is gebracht oor de wat meer ervaren programmeurs en grotere projecten. De andere Flashers moesten het maar houden bij LoadVars e.d. opties. Maar bijvoorbeeld AMFPHP is eigenlijk heel eenvoudig te installeren. Je download de ZIP, pakt het uit in de root van de website, en je bent vervolgens eigenlijk zo goed als klaar om het te gebruiken. In welke maten is dit meer complex dan de SWX ActionScript API waarbij je jouw eigen gateway gebruikt?

Het gebruik van de "simple mode", je weet wel met loadMovie(), wil ik niet eens meer in de vergelijking gooien. Het gebruik van loadMovie() en onEnterFrame() aan de gebruikers kant om data communicatie te verzorgen en af te handelen is in mijn ogen misbruik en een foute gedachten. De eenvoud weegt daar niet tegen op.


SWX is nog 1 stap dichter naar makkelijk, en maakt het benaderen/navigeren door je gegevens heel erg makkelijjk, omdat je objecten, of arrays krijgt, ipv het hele childeren gedoe.

Dat heeft Flash Remoting net zo goed en zelfs nog beter (lees: je kunt daarmee nog veel verder gaan en is sneller).


Mijn kunnen is hier idd erg beperkt en bij de meeste mensen die voor SWX gaan is dat toch juist de reden WAAROM ze voor SWX gaan en niet voor remoting: Simplicity.

Maar dan blijf je dus hangen op je niveau i.p.v. dat je vooruit gaat. Daarnaast zal je vanaf ActionScript 3 weer een hele nieuwe SWX moeten leren kennen wanneer je de "simple mode" gewend bent. Deze zal namelijk zeker weten veranderen en lang niet zo eenvoudig meer zijn dan het nu is of veel eenvoudiger dan een Flash Remoting. Tijdelijke simplicity?


Verder kan het goed zijn dat je ook bestanden op de server moet installeren. Moet er zelfs geen extra Remoting service op de server draaien? Ik weet het niet. Ik weet alleen dat het op mijn server draait, en ik het niet gebruik :p
Flash Remoting (gateway) moet op de server draaien net zoals SWX dat moet, daar ontkom je niet aan. Tuurlijk SWX heeft een public gateway, maar is dat zo betrouwbaar voor je projecten? Daarnaast is die SWX public gateway alleen bruikbaar voor de API's gemaakt voor SWX door mensen als Aral Balkan, en dus niet je eigen projecten.

Het wordt allemaal heel mooi en leuk neergezet, beter dan Flash Remoting ooit is neergezet (voor de gemiddelde Flashers). Hierdoor lijkt het gelijk hemel, maar dat is het zeker niet. Met deze discussie probeer ik niet SWX af te kraken. Ik probeer er van een andere kant licht op te werpen, waar je je hoofd zeker niet voor moet wegdraaien. Probeer bijvoorbeeld AMFPHP zelf eens: http://www.amfphp.org/ :)

[TheDutch]

Verder blijft het grote voordeel dat je met native data werkt, i know, klinkt saai en als repeater maar dat is het grootste voordeel voor de flash kant.

Zoals BernardV al aangaf, dat doe je ook met Flash Remoting.


Doordat er een public gateway is hoef je niet net als bij remoting dingen op je server te zetten. Dat voordeel valt uiteraard weg als je eigen services en een eigen endpoint wilt draaien.

Verwaarloosbaar argument dus ;).


Om met de woorden van Aral zelf te spreken om het bestaan van SWX te rechtvaardigen:

=========================================

1 & 2: Met Flash Remoting is het ook native (daar maakt Aral dus een foutje).
3: Flash Lite waren we het allemaal over eens.
4: Zie punt 1 en daarbij vind ik de "simple mode" niet echt een zeer goed argument. De "simple mode" zal zeker weten veranderen vanaf ActionScript 3 en lang niet zo simpel meer zijn als het in ActionScript 1 en 2 was. Daarnaast weet je mijn standpunt over loadMovie() aan de gebruikers kant.

=========================================

In het kort komt het mij hier op neer; SWX is zeer handig voor Flash Lite en voor designers die echt weinig snappen van ActionScript en OOP. Want in mijn opinie gaat een serieuze programmeur geen data communicatie laag neerzetten via loadMovie().


Ik snap je punt overigens wel Erwin over dat je bang bent dat nieuwe developers verkeerd leren omdat het via loadMovie data laden een punt is waarop je die vraagtekens kan zetten.
Blijf ikzelf anders over denken zeker gezien het gebruik van loadMovie in persoonlijke ervaring. Maar goed ik zie je punt daar.

Dat is inderdaad één van mijn punten. Ik zit al sinds 2000 in de Flash Community, zowel nationaal als internationaal, je weet van FlashDevils. Jaren lang heb ik tijd gestopt om mensen Flash te leren en later juist het ActionScript gedeelte over te brengen. De verschuiving van design naar geavanceerd programmeren is voor mij heel merkbaar. Juist nu is het het moment om jezelf te gaan verdiepen in ActionScript 3, omdat ActionScript 2 niet lang meer zal bestaan en Flash niet lang meer gebruikt kan blijven worden zonder die nieuwe kennis. Door SWX zal die overgang vertragen en zullen veel mensen uiteindelijk die grotere stap niet meer kunnen maken. Dat komt dan omdat SWX het gat te groot heeft gemaakt. Zie jij dit echt zo heel anders?


Dus nogmaals grote voordeel is de native data, direct te gebruiken. en uiteraard de FlashLite oplossing.

Flash Remoting werkt ook met native data. Flash Remoting is even direct te gebruiken als SWX (gateway installeren/uploaden en draaien maar, net zoals met SWX). En Flash Lite daar is het geweldig voor.

Let wel: Ik neem de SWX public gateway niet mee in deze discussie. De SWX public gateway is alleen beschikbaar voor de bestaande SWX API's. Daarnaast is het voor serieuze projecten niet echt betrouwbaar en dien je jouw eigen gateway te draaien net zoals met Flash Remoting :).

[Ea.Z]

Het was een compliment...Mijn onwetendheid deed me het omgekeerde denken ;)

Van AMF heb ik al vaak gehoord, maar nog nooit mee gewerkt(XML deed het voor mij. SWX werd me live voorgetoond. Naar AMF heb ik nooit gekeken, dus de fout ligt daar in feite bij mij.)

Het is zo dat ik niet altijd evenveel uitkijk naar 'nieuwe' technieken. Vandaar dat XML voor mij altijd de problemen oploste, tot ik SWX eens gezien had.
Nu gebruik ik SWX niet meer zoveel gezien je met E4X toch heel makkelijk je gegevens kunt benaderen.

Op hetzelfde puntje blijven steken omdat dit simpel is?
Ik denk het niet. Als je behoeften voldaan zijn om data in te laden is toch 'een probleem' opgelost? Data inladen lijkt mij een probleem met weinig oplossingen. Eens je het opgelost hebt kijk je niet meer uit naar nieuwe wegen. Toch niet tot er iets uitkomt dat beduidend beter is, of tot er iets onder je neus geduwd wordt :)
Dus je kunt je energie/tijd in andere dingen steken.

Dus wat evolutie op je eigen niveau betreft denk ik dat je door SWX toch niet blijft hangen? op andere vlakken van AS kun je toch verder evolueren?

[Folkert]

Juist nu is het het moment om jezelf te gaan verdiepen in ActionScript 3, omdat ActionScript 2 niet lang meer zal bestaan en Flash niet lang meer gebruikt kan blijven worden zonder die nieuwe kennis. Door SWX zal die overgang vertragen en zullen veel mensen uiteindelijk die grotere stap niet meer kunnen maken. Dat komt dan omdat SWX het gat te groot heeft gemaakt. Zie jij dit echt zo heel anders?


Niet heel anders ;) Wat ik zie is hier en nu. Hier en start ik een project en kies ik wat er voor nodig is en in hoeverre het schaalbaar moet zijn voor later. Ik ken de opties die ik heb inclusief SWX wat mij betreft dus. Verder kan ik me nogmaals goed in je argumenten daaromheen vinden.

AMF moet overigens nog deserialized worden als het in flash aankomt ;) daarna kan je het wellicht native noemen.

[TheDutch]

@Ea.Z: Ik zie dat als niet verder kijken dan je neus lang is, no offense. Wellicht een idee om een keer serieus Flash Remoting eens te proberen, dan heb je daar tenminste ook wat kennis over op gedaan :).

@Folkert:
Eigenlijk maakt het weinig uit of er nu een SWF gegenereerd wordt op de server door SWX of dat met Flash Remoting een ge-serialized object wordt ge-deserialized aan de client. Het gaat erom of ze bij binnenkomst in je applicatie native zijn en dat zijn ze voor beide. Dat is geen direct punt om SWX te rechtvaardigen. Wanneer dit daadwerkelijk wel een punt is dan wil ik je vragen dit wat verder toe te lichten met duidelijke argumenten :).

Laat ik gewoon even wat vragen stellen:

Wat voor meerwaarde zal SWX hebben binnen ActionScript 3 boven een Flash Remoting? Dan ben ik vooral benieuwd naar overduidelijke meerwaarde van SWX zelf, dus niet de public gateway of API's argumenten.
Wanneer iemand SWX neemt omdat Flash Remoting en/of OOP te moeilijk is, hoe moet dat dan met ActionScript 3? Het niveau van ActionScript 3 ligt namelijk minstens aan het niveau van bijvoorbeeld Flash Remoting.
Wat is jouw ervaring uberhaupt met Flash Remoting? Wat vindt je bijvoorbeeld moeilijk aan Flash Remoting? Ik ben erg benieuwd waar het knelpunt zit om de keuze voor SWX boven Flash Remoting te begrijpen.
Zou je nog antwoord willen geven op mijn vorige vragen? ;)


ps. Ik heb net een interview met Aral Balkan gezien op MAX over SWX door bloginblack.de. Daarin geeft Aral zelf toe dat de "simple mode" niet echt geadviseerd wordt om te gebruiken en dat het meer is om aan te tonen dat er een SWF naar binnen geladen wordt met data. Nu dat ook uit Aral zijn eigen woorden "wegvalt", ben ik nog meer benieuwd naar de uiteindelijke voordelen van de SWX ActionScript API / SWX Gateway boven een Flash Remoting / AMFPHP.

[Folkert]

Wat voor meerwaarde zal SWX hebben binnen ActionScript 3 boven een Flash Remoting? Dan ben ik vooral benieuwd naar overduidelijke meerwaarde van SWX zelf, dus niet de public gateway of API's argumenten.


Beetje flauwe vraag vind je niet ? als je weet de SWX momenteel alleen voor as2 er is. Wat de voordelen t.z.t. zijn kan ik je dan ook niet vertellen. Zoals ik al eerder zei, ik kijk naar hier en nu en wat kan ik het best/makkelijkst gebruiken voor het project waar ik voorsta.


Wanneer iemand SWX neemt omdat Flash Remoting en/of OOP te moeilijk is, hoe moet dat dan met ActionScript 3? Het niveau van ActionScript 3 ligt namelijk minstens aan het niveau van bijvoorbeeld Flash Remoting.


Goeie vraag niet alleen niet relevant. Maar goed je kan er ook wat positiever naar kijken, die persoon doet dan wel dynamische data gebruiken wat die eerst niet deed. En lang niet iedereen is developer (sterker nog Flash is eigenlijk een design tool en geen develop tool ) , gelukkig zie je daar straks in Astro wat van terug weer voor de designers en animators.
As3 is wat hoger nivo dan Flash remoting overigens. remoting is immers enkel 1 aspect. actionScript 3 houd wat meer in :D


Wat is jouw ervaring uberhaupt met Flash Remoting? Wat vindt je bijvoorbeeld moeilijk aan Flash Remoting? Ik ben erg benieuwd waar het knelpunt zit om de keuze voor SWX boven Flash Remoting te begrijpen.


Ik heb genoeg ervaringen met remoting (heb je me niet eens gevolgd sinds 2000 ;)) en zal die ook zeker nog gaan hebben aangezien het voor mij dus niet AMFPHP vs SWX is maar SWX of AMFPHP of nu met as3 ook XML.

Er zijn dus ook geen knel punten. Die keuze maak ik (zoals al meerdere malen gezegd) per project. Maar genoeg over mij.

SWX is voor vele gevallen (Met name flash lite en niet nog zozeer as3 en flex) heel geschikt. Je zegt wel de API's en de public Gateway niet meerekenen, maar ja dat is dus onderdeel van SWX en van makkelijk bereikbaar maken voor iedereen die met plezier wil Flashen. Natuurlijk kan je dit met AMFPHP ook publiekelijk doen overigens. Bij de SWX PHp download krijg je ook de Services erbij. Dus in die zin ben je niet afhankelijk van de publieke gateway om toch het voordeel van de Services te hebben.

Als je de enterframe weglaat moet je in beide gevallen een download doen.

Even de code vergelijken, dan mag iedereen voor zich bepalen wat die wel/niet handig vind.
AMFPHP (as2 aangezien SWX as2 is momenteel)

import mx.remoting.Service;
import mx.remoting.PendingCall;
import mx.rpc.RelayResponder;
import mx.rpc.ResultEvent;
import mx.rpc.FaultEvent;

var gatewayURL:String = "http://site.nl/amfphp/gateway.php";
var deService:Service = new Service ( gatewayURL, null, "eenService", null, null );
var pendingCall:PendingCall = deService.getContents( contentName );
pendingCall.responder = new RelayResponder(this, "onResult", "onFault" );
//verder de handlers


SWX met Library

import org.swxformat.SWX;
swx = new SWX();
swx.gateway = "http://site.nl/php/swx.php";
var methodParameters:Object =
{
serviceClass: "eenService",
method: "getContents",
args: [ contentName ],
progress: [this, progressHandler],
result: [this, resultHandler],
timeout: [this, timeoutHandler]
}
// Note de progressHandler.
swx.call(methodParameters);
//handlers



ps. Ik heb net een interview met Aral Balkan gezien op MAX over SWX door bloginblack.de. Daarin geeft Aral zelf toe dat de "simple mode" niet echt geadviseerd wordt om te gebruiken en dat het meer is om aan te tonen dat er een SWF naar binnen geladen wordt met data. Nu dat ook uit Aral zijn eigen woorden "wegvalt", ben ik nog meer benieuwd naar de uiteindelijke voordelen van de SWX ActionScript API / SWX Gateway boven een Flash Remoting / AMFPHP.
Beetje kinderachtig begin je nu wel te worden, wat dacht je dan dat Aral daar anders over dacht ? De man heeft jarenlang good practische en design patronen en code geademt.

En nu voor de laatste keer, het hangt geheel af van welk project je doet, of SWX daarin een logische keuze is. By the way geef ik antwoord op vragen als de vragen me tot een antwoord brengen, en anders niet ;)

Ik ben overigens benieuwd wat anderen ervan vinden, dus heb je er een beeld over doe die dan even posten ;)

ps: Erwin we moeten serieus een keer live koffie drinken en het hier in detail over hebben, we zeggen op een aantal vlakken dezelfde dingen, alleen vanuit andere oogpunten.

[TheDutch]

Beetje flauwe vraag vind je niet ? als je weet de SWX momenteel alleen voor as2 er is. Wat de voordelen t.z.t. zijn kan ik je dan ook niet vertellen. Zoals ik al eerder zei, ik kijk naar hier en nu en wat kan ik het best/makkelijkst gebruiken voor het project waar ik voorsta.

Dit vind ik geen flauwe vraag, ik denk immers verder dan vandaag. Ik probeer te bekijken wat voor plek SWX kan innemen op dit moment en in de nabije toekomst of in projecten die al op ActionScript 3 gebouwt worden in de opzet hoe SWX's ActionScript API nu in elkaar zit. De vraag hoe jij de meerwaarde van SWX zou zien binnen ActionScript 3 is daarom een reëele vraag. De keuze om SWX te gebruiken boven een Flash Remoting is voor bedrijven een zeer belangrijk iets. Niet iets waar je zomaar even per project van kunt switchen. Dat jij dit wel per project kunt benaderen is eerder een uitzondering dan regel.


Goeie vraag niet alleen niet relevant. Maar goed je kan er ook wat positiever naar kijken, die persoon doet dan wel dynamische data gebruiken wat die eerst niet deed. En lang niet iedereen is developer (sterker nog Flash is eigenlijk een design tool en geen develop tool ) , gelukkig zie je daar straks in Astro wat van terug weer voor de designers en animators.
As3 is wat hoger nivo dan Flash remoting overigens. remoting is immers enkel 1 aspect. actionScript 3 houd wat meer in :D

Wanneer SWX wordt gebruikt omdat Flash Remoting te moeilijk is voor veel Flashers dan vraag ik me terecht af hoe dat dan moet gaan met ActionScript 3 en verder. Wanneer jij zegt dat Flash een design tool is en geen development tool, dan denk ik dat je wat gemist hebt de afgelopen jaren (refererende aan het hele Flash Platform).

Wat betreft het niveau van ActionScript 3 zei ik volgensmij dat ActionScript 3 minstens op het niveau ligt van Flash Remoting. Dan heb ik het vooral over de denkwijze e.d. :)


Ik heb genoeg ervaringen met remoting en zal die ook zeker nog gaan hebben aangezien het voor mij dus niet AMFPHP vs SWX is maar SWX of AMFPHP of nu met as3 ook XML.

Er zijn dus ook geen knel punten. Die keuze maak ik (zoals al meerdere malen gezegd) per project. Maar genoeg over mij.

Wanneer jij zo'n afweging maakt tussen SWX of AMFPHP, dan ben ik benieuwd hoe zo'n afweging in zijn werk gaat. Je zal toch daarin keuzes moeten maken, de voor- en nadelen (knelpunten?) overwegen.


SWX is voor vele gevallen (Met name flash lite en niet nog zozeer as3 en flex) heel geschikt. Je zegt wel de API's en de public Gateway niet meerekenen, maar ja dat is dus onderdeel van SWX en van makkelijk bereikbaar maken voor iedereen die met plezier wil Flashen. Natuurlijk kan je dit met AMFPHP ook publiekelijk doen overigens. Bij de SWX PHp download krijg je ook de Services erbij. Dus in die zin ben je niet afhankelijk van de publieke gateway om toch het voordeel van de Services te hebben.

De API's worden los(!) meegeleverd met SWX en zijn daardoor zeker geen onderdeel van SWX net zoals de public gateway wat gewoon een server is die iedereen kan opzetten en draaien. SWX is om Flashers met plezier te laten Flashen? Is SWX bedoeld voor hobbiesten? Het klinkt misschien flauw maar professionele Flashers die acht ik toch wel tot wat meer in staat :).


Beetje kinderachtig begin je nu wel te worden, wat dacht je dan dat Aral daar anders over dacht ? De man heeft jarenlang good practische en design patronen en code geademt.

Blijkbaar heb jij Aral Balkan op een hoog voetstuk staan. Voor mij is Aral gewoon een programmeur net zoals veel leden hier. Probeer hem alsjeblieft niet, ondanks dat je hem geweldig vindt, boven anderen te stellen. Aral is namelijk niet de enige met die hoeveelheid aan kennis ;).

Verder was mjn reactie ook helemaal niet om Aral aan te vallen, je trekt het gelijk zo persoonlijk aan. Ik vond het gewoon opmerkelijk dat Aral SWX neerzet als "You loadMovie() your data!" en alle voorbeelden laat zien zoals op de "Moo cart" of wel de "simple mode", maar vervolgens in een interview het eigenlijk afraadt om het op die manier te gebruiken. Dan spreek je jezelf en je product behoorlijk tegen.


By the way geef ik antwoord op vragen als de vragen me tot een antwoord brengen, en anders niet ;)

Ik vraag je gewoon of je daar nog antwoord op zou willen geven. Je kunt ook gewoon zeggen dat je dat niet wilt of dat je daar geen antwoorden op hebt, wel zo beleefd toch? :)


ps: Erwin we moeten serieus een keer live koffie drinken en het hier in detail over hebben, we zeggen op een aantal vlakken dezelfde dingen, alleen vanuit andere oogpunten.
We zullen eens een datum prikken :D.

Ik denk dat alles zo'n beetje wel gezegd is van mijn kant en we komen er klaarblijkelijk toch niet echt uit nu, dus ik laat het hier graag tussen ons even bij. Natuurlijk ben ik net zoals jij erg benieuwd naar de mening van anderen!

[Folkert]

Blijkbaar heb jij Aral Balkan op een hoog voetstuk staan. Voor mij is Aral gewoon een programmeur net zoals veel leden hier. Probeer hem alsjeblieft niet, ondanks dat je hem geweldig vindt, boven anderen te stellen. Aral is namelijk niet de enige met die hoeveelheid aan kennis ;).

Ik heb respect voor Aral en door zijn verleden heb ik er dus wel vertrouwen in dat SWX, SWX RPC, SWX PHP zich op goede manier gaan ontwikkelen. Op een voetstuk staat niemand ;)


We zullen eens een datum prikken :D.

Cool !