Se tu usi le librerie di php per fare certe cose decidi tu come si comportanto?Originariamente inviato da andr3a
se li ha programmati, li programmerà come gli pare, no ?
Se c'è una libreria per imap supporta le tue varianti? No. Te la devi riscrivere o usare altre librerie (se ci sono).
Siccome è stato proprio microsoft a proporre SOAP e a spingere sul modello WSDL+SOAP per i webservices le funzioni di .NET per i webservices sono incentrate su quel modello.
Se tu poi vuoi farti le tue funzioni, perdere tempo per usare strumenti particolari (ti ripeto) non vedo il problema. A volerlo fare, lo si fa.
Ah giusto.. perchè tu non indichi all'inizio di un documeto XML qual è la sua versione?eh ? ... lo hanno e come, la dtd non è che li rende "alieni" tra le varie versioni ... ma poi cosa c'entra ? :master:
Forse ti sei perso questo.. o forse sei così legato agli standard che te lo scordi?
Per ogni versione di XML esistono precise specifiche emanate dal w3c come avviene per l'html/xhtml.Codice PHP:<?xml version="1.0" encoding="ISO-8859-1"?>
Bravo, è quello che ho detto anch'io. Ognuno fa come vuole, puoi ci troveremo nella stessa situazione in cui ci siamo trovati con i browser.il w3c spesso è in ritardo rispetto le tecnologie / interfacce ... seguire scrupolosamente anche gli errori presenti o magari ufficializzati dalle working draft lo trovo ottuso e sconveniente, poi ognuno ovviamente fa come vuole ...
A me non da fastidio niente, anzi, ogni novità volta a migliorare le cose è la benvenuto. Semplicemente chiamo le cose con il loro nome. La definizione che hai dato dei webservice da un idea di cos'è un webservice per te.ed io non posso "ricordare" che se la preoccupazione è la banda si può raggirare il problema con altre soluzioni largamente usate ? ... punti al "formale" o al miglior risultato ? ... mi sa che la vediamo in modo diverso, counque il mio era un consiglio ed una precisazione ... se ti turba che tanti usino webservices con JSON o che un colosso come Yahoo abbia proposto un'alternativa valida (che se pensata significa che ce n'era l'esigenza) mi spiace
Ehm, il problema non è cosa tu vuoi fare. Il problema è chiamare le cose con il loro nome. Se XML è troppo pesante per il tuo scambio dati, o "l'interazione è semplice" puoi usare i formati che più ti aggradano. Falsh quando usa loadVars carica dati da una stringanon vedi niente, ho solo fatto accenni ad esempi ... che se limitati, potrebbero andare meglio con alternative ... XML offre tanto più di JSON, ma se l'interazione è semplice, XML è sprecato.
nomeVar=dati&nomeVar2=dati2
Ripeto che nessuno ti vieta di farlo. Puoi fare un po' come ti pare, e così possono fare tutti.
Ma anche su flash quello non si chiama webservice sebbene si appoggi ad "un servizio web... che tu chiedi e lui risponde".
Se su flash tu usi i componenti per collegarti ad un webservice non trovi JSON/Ambarabba/Cabiro/Filippo... trovi XML-WSDL-SOAP (che sono i webservice).
Hai scritto il tuo "webservice" con Cabiro? Ti attacchi al tram..
Ehm.. si, ma hai detto solo questo. Cioè che i webservices servono per i navigatori. Tutto improntato sui navigatori. Quando i webservices sono pensati per fare parte di applicazioni su larga scala che 90 su 100 vanno fruite server2server.mai supposto, mai detto niente di quelo che affermi sui webservices, ho solo detto che come servizio rivolto anche ai navigatori che devono caricare i dati, l'utilizzo di metodi alternativo può risultare vantaggioso se le interazioni non sono complesse ... ora rigirala come ti pare ma io ho detto questo
Se continui a portare esempi su quel 10% di casi finisco inevitabilmente con il credere che tu i webservice li vedi solo in quell'ottica.
Farà paura a tesi e tu hai hai la capacità di cogliere dettagli su un articolo che fa paura ... :rollo:
A me non fa nessuna paura, niente di nuovo. Tutte cose che chiunque con un minimo di conoscenze e buon senso può capire da solo.. l'unica cosa che mi ha lasciato perplesso è il fatto che mod_gzip debba salvare sul disco i file per comprimerli.. mi pare un assurdità, ma controllerò. Ad ogni modo non avrei di certo usato mod_gzip su un webservice..... avrai usato la compressione da php che usa zlib per effettuare la compressione in memoria..
I problemi con gzip cmq sono causati 90 su 100, anche per php, quando si manda in output qualcosa prima o dopo la compressione confondendo il client. Internet explorer per esempio scarta i dati se li trova non corrispondenti.
Come tutti gli strumenti bisogna saperli usate. Per il resto nessuno può farci nulla se qualcuno dice che supporta la compressione e poi non la sopporta..
Non mi è sfuggito niente, non l'ho letto li perchè lo sapevo già.o io traduco l'inglese in un modo diverso da te, oppure ti è ancora sfuggito che inviare con gzip può essere:
Io non so cosa intendi tu per sovraccarico. Il sovraccarico non è di certo una condizione determinata da gzip. Tu vai a chiedere ad un azienda se preferisce potenziare un server o pagare il doppio della banda, vedrai cosa ti risponde.1 - un sovraccarico per il server
Ad ogni modo, volendo scendere nei dettagli.
Con gzip può scegliere il grado di compressione da utilizzare.
Per esempio:
benchmarking the speed:
(compression, datasize, compress time)
0: 37440 (0.002 s)
1: 2537 (0.002 s)
2: 2298 (0.003 s)
3: 2199 (0.003 s)
4: 2299 (0.003 s)
5: 1939 (0.004 s)
6: 1789 (0.004 s)
7: 1724 (0.004 s)
8: 1635 (0.005 s)
9: 1635 (0.005 s)
Come vedi si può decidere quanto comprimere. Oltre al 6 la compressione risulta meno efficace e più lenta, quindi si può scegliere tranquillamente il livello 6 o leggermente inferiore per ottimizzare. Se si ha tanta paura del sovraccarico basta ridurre ulteriormente la compressione.
Come vedi, inoltre, stiamo parlando di un file dalle dimensioni spropositate. Guarda i tempi di compressione. Ti pare che l'ottimizzazione se hai un sovraccarico vai a cercarla qui? ....
Se intendi sovra-carico nel senso che ha un carico in più rispetto a prima chiaramente è così. Ma qualsiasi cosa tu faccia aggiunge un sovra-carico. Anche aggiungere un tag allora è un sovra-carico.2 - un sovraccarico per il client
Usare la compressione non significa fregarsene del resto. Si deve anche ottimizzare come riportato nell'articolo che hai citato (nel caso di js e css o con altri criteri per altri dati).
Alla fine il risultato è l'ottimizzazione finale, che, risulta sicuramente migliore rispetto a chi utilizza o uno o l'altro sistema.
Inoltre per decomprimere il gzip normalmente si impiega 1/3 del tempo necessario per la compressione.. capirai che sovraccarico..
Ehm... prima mi dici che sto delirando... poi continui sulla stessa strada.. e dai.. ancora con questi browser, sempre i browser, esistono solo loro per te.. I webservices sono fatti per i browser...3 - un modo scorretto di inviare dati se il client, con grandi quantità, può presentare errori in riconversione ( si parla di IE eh ... non di PincoWebBrouser ... )
Se ti preoccupa tanto questo problema di IE fai un check e non comprimi se è una versione che crea problemi (posto che l'unico problema che ho trovato è questo e non dipende certo da gzip).
Per tutto il resto (server2server) c'è mastercard... ehm.. si arrangiano e vedrai che non ci sono problemi se si utilizza correttamente la compressione (visto che è la stessa che milioni di utenti utilizzano per scambiare/scaricare file centinaia di milioni di volte al giorno).
[MODE delirio OFF]
Rispondi quotando
]
ora se vuoi continuare fai pure 
