Newsgroup: it.comp.www.php
Titolo: xml-rpc

il modulo di php per xml-rpc è affidabile o ancora in fase sperimentale ? 

 il modulo di php per xml-rpc è affidabile o ancora in fase sperimentale ?
[quoting 
http://php.net/xmlrpc
]
This extension is EXPERIMENTAL. The behaviour of this extension -- including
the names of its functions and anything else documented about this
extension -- may change without notice in a future release of PHP. Use this
extension at your own risk.
[quoting 
http://php.net/xmlrpc
]
-- 
www.iuz-lab.info


si lo so , ho pensato che magari era di quelle classiche cose che non 
aggiornavano ma che alla fine
usavano tutti, siccome  volevo "buttarmi" sui web service avevo xml-rpc
---

 usavano tutti, siccome  volevo "buttarmi" sui web service avevo xml-rpc
[..]
IMHO credo che non sia ancora affidabile.. 
yag se non ricordo male 'poco' tempo indietro hai posto domande riguardanti
l'uso delle funzioni XML..
posso sapere se hai avuto problemi nel comprenderne il funzionamento..
e in caso tu ne abbia avuti, quali erano, od in caso non siano ancora stati
risolti, quali sono?
ti ringrazio anticipatamente
-- 
www.iuz-lab.info

"iuz" <us...@host.network> ha scritto nel messaggio 
news:%k4qe.1006226$b5.43...@news3.tin.it...

si ma era un bagionata se non sbaglio a conclusione del tread ho messo anche 
la "soluzione"

 IMHO credo che non sia ancora affidabile..
falso
personalmente ho scritto due classi (client/server) per la gestione di
webservice con questa estensione e non ho mai avuto problemi. le classi
vengono usate in produzione per un portale di certe dimensioni
ho visto altre soluzioni con un parsing "manuale" delle richieste
xmlrpc e la creazione dell'xml per le risposte nella medesima maniera,
evitando l'utilizzo di questa estensione, ma si tratta imho
semplicemente di brutto codice, inutilmente complicato e che adotta
soluzioni poco pulite

 soluzioni poco pulite
una estensione in fase sperimentale in genere non e' considerata adatta a
destinazioni di rilievo.. proprio perche' il funzionamento non e'
assicurato come completamente affidabile..
ed IMHO preferirei non utilizzare detta estensione per progetti poiche'
proprio come il manuale dice..
[quoting 
http://php.net/xmlrpc
]
This extension is EXPERIMENTAL. The behaviour of this extension -- including
the names of its functions and anything else documented about this
extension -- may change without notice in a future release of PHP. Use this
extension at your own risk.
[/quoting 
http://php.net/xmlrpc
]
ed in un progetto di rilievo bisogna tendere a rendere il piu' esiguo
possibile il rischio di malfunzionamenti..
-- 
www.iuz-lab.info

 possibile il rischio di malfunzionamenti..
il manuale non parla di nessun tipo di rischio di malfunzionamenti,
dice semplicemente che lo stato dell'estensione e' sperimentale, ovvero
(come e' appunto scritto chiaramente) le sue caratteristiche potrebbero
cambiare in versioni future del php. questo non toglie che la versione
attuale sia pienamente funzionante. quindi, tu puoi credere che non sia
affidabile, ma e' un preconcetto o superstizione tua, non avvallata da
nessuna constatazione: ne' da indicazioni del manuale, ne' da casi di
utilizzo (tanto per: l'hai provata l'estensione per dire che non e'
affidabile?).
poi, se non ti fidi, preferisci non rischiare, e' una tua scelta, ma se
si chiede se un'estensione e' affidabile potresti evitare di rispondere
se non hai elementi per dare un'opinione, oppure specificare che parli
solo a livello emotivo, senza nessun fondamento tecnico che motiva le
tue opinioni
personalmente ho provato entrambe le soluzioni possibili per l'uso di
xml-rpc in php: l'estensione e la programmazione di un parser ad hoc.
la prima funziona, richiede esclusivamente la scrittura di un metodo di
transport (che non avrebbe bisogni di mofiche anche se cambiassero le
specifiche). la seconda e' piu' complicata da implementare, richiede
piu' codice e di conseguenza maggior rischio di bachi e
malfunzionamenti, oltre a non essere pulita come soluzione.
per quanto riguarda il mantenimento del codice: nel caso
dell'estensione un client/serve xmlrpc si risolve in un centinaio di
righe, in poco tempo si ottiene una release pressoche' definitiva che
non richiede ulteriore manutenzione, se non nel caso l'estensione venga
modificata e si decida di passare alla nuova versione, nel qual caso si
dovranno probabilmente perdere due o tre giorni per riscrivere
l'applicazione. l'uso di un parser ad hoc richiede, come la
programmazione di ogni parser, piu' righe di codice (un duecento circa
solo per il parser, a cui aggiungere l'applicazione client e il
server), il codice e' meno pulito ed intuitivo, aumenta la probabilita'
di bachi, richiede un tempo di sviluppo e testing maggiore per
implementare tutte le specifiche xmlrpc (l'implementazione dei metodi
di introspezione e' impossibile in php4 se non con le funzioni di
token, il che vuol dire scrivere un ulteriore parser per i commenti nel
codice dello script, in php5 si possono usare le reflection api, senza
che l'evenienza semplifichi le cose)
insomma, mi sembra che tra le due, e' meglio rischiare (con poi che
fattore?) di dover riscrivere un'applicazione semplice e leggera che
stare dietro ad una inutilmente complessa e verbosa
senza considerare le prestazioni

 senza considerare le prestazioni
-- 
www.iuz-lab.info

 [/self quoting]
e tra le due:
1. un'applicazione semplice e leggera
2. una inutilmente complessa e verbosa
quale da' il maggior rischio di malfunzionamenti?

 quale da' il maggior rischio di malfunzionamenti?
i fattori da te citati IMHO sono legati indirettamente al rischio di
malfunzionamento (ma almeno questi possono essere ovviati dal programmatore
e dalla sua abilita')..
e comunque cio' che rende l'applicazione semplice e leggera e' il supporto
di quello che tu intendi come inutilmente complesso e verboso (in questo
caso sperimetale)..
se un problema richiede un lavoro di risoluzione di una determinata entita'
usare una estenzione o non usare una estenzione per raggiungere l'obiettivo
alla fine non determina la semplicita' o la complessita' del lavoro
stesso..
-- 
www.iuz-lab.info

 stesso..
a che titolo dici questo? in maniera cosi' generale? in xmlrpc il
discorso e' appunto che usando l'estensione l'entita' del lavoro di
risoluzione e' minore
cmq, a dimostrazione di come non usare l'estensione implichi maggiori
rischi di "malfunzionamenti" (come li chiami):
http://punto-informatico.it/p.asp?i=53897
le librerie di cui si parla non usano l'estensione