On 7/17/07, Andrea Aime <[EMAIL PROTECTED]> wrote: > Alessandro Pasotti ha scritto: > > Il martedì 17 luglio 2007, Andrea Aime ha scritto: > > > > [...] > >> Mah, non so, ma il fatto è che stiamo deviando, occupandoci della > >> scatola e non del contenuto. Al di la che tu ti voglia "riposare" o > >> "insaponarti", tutti gli esempi che ho visto usano una qualche forma > >> di trasferimento dati testuale. > > > > Sei sicuro? Ho visto saponette piene di allegati binari, in cui di fatto > > l'unica cosa che usano di SOAP è l'envelope e il protocollo di trasporto. > > Questo è il modo migliore per dire: usiamo SOAP, siamo standard e > > interoperabili!! Poi dentro c'è fuffa binaria e proprietaria. > > Bleah, no, io voglio un binario standardizzato, non proprietario :)
Ovviamente lo standard SOAP gestisce gli allegati da specifica, il problema è che ci sono dei gravissimi problemi di incompatibilità tra le implementazione with attachment .Net e quelle java (sia JWSDP che Axis) e questo costringe spesso a dover lavorare a basso livello per fare una chiamata, addirittura creando anche l'header a mano come stringhe perchè ci sono differenze nel numero dei return tra il termine dell'header e l'inizio del pacchetto SOAP...insomma non la vedo come una soluzione interoperabile al 100%... > > >> Quello che manca è una alternativa seria e binaria a GML. > >> I signori di Cubewerx hanno provato a spingere sul binary xml > >> (quindi, binary GML) ma non mi pare abbiano avuto grande successo... > > > > Scusate, forse sto andando un po' OT o semplicemente non ci ho capito molto, > > però se il problema è l'inefficienza del XML in termini di occupazione di > > banda, non si risolve in buona misura (g)zippando il tutto? > > > > Rimarrebbero i cicli di CPU per le operazioni di marshalling/unmarshalling, > > forse è questo che preoccupa? La tecnologia FastInfoset è stata implementata proprio per questo motivo (credo che in qualche post precedente qualcuno ne parlasse come binary XML) si è creato un algoritmo ad hoc per gli xml che abbia il miglior bilanciamento tra compressione e tempo di compressione/decompressione > > Tra uno e l'altro carichi parecchio la CPU sia del server che del client > in effetti, diciamo che arrivi a farti una server farm prima con questo > approccio (ti servono tante CPU prima). Comunque hai ragione, è una > soluzione disponibile oggi, ed è anche l'unica seria per distribuire GML. > > C'e' un altro aspetto da considerare: mai provato a costruire un parser > GML3? Non ce ne sono molti in giro, perché è maledettamente difficile > scriverne uno generale e anche in grado di gestire grossi volumi di dati > senza essere memory bound. > In teoria mi piacerebbe vedere un protocollo binario ben supportato > da vari linguaggi, qualcosa tipo Hessian > (http://www.caucho.com/hessian/), e in grado di trasportare, se non > tutto, almeno una porzione significativa dei dati che > possono essere codificati in GML3. > > Mah, magari mi sto compliando la vita per nulla... la mia allergia > all'XML non vuole proprio passare :) Nono intervengo sulla diatriba tra SOAP e REST altrimenti non ne esco più cmq entrambe hanno danno il loro meglio per determinate aree di applicazioni...ho letto con molto gusto questo articolo su zdnet: http://blogs.zdnet.com/Newton/?p=17 mi piacerebbe tanto che REST non diventasse the next buzzword...ma forse questo commercialmente è inevitabile :) Ciao Simone _______________________________________________ Gfoss mailing list: 234 iscritti (13-07-2007) [email protected] http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
