Re: [Wpaisb-devel] MANIFESTO il mio diritto di argomentare sul MANIFESTO in maiera convulsa e 'circoncisa'

[nids]

Ciao a Tutti!

Ok adesso che ho tutte le sisposte di Luca puntualizzo alcuni punti.

Le mie puntualizzazioni, spesso, non saranno delle affermazioni ma,
bensi', delle domande (che ritengo piu' utili delle affermazioni :) ).

Voglio essere provocatorio quanto basta: Desidero che ci sia un po' di
interazione per capire cosa ci serve e di cosa possiamo fare a meno.

Da bravo informatico contero' da zero.

0) Della novita' del progetto: Il progetto, per se', non e' una novita'
sconvolgente. Di sistemi client/server ce ne sono parecchi in giro e per
tutti i gusti. Cio' che ci interessa e' (di)mostrare e' che pescando i
pezzi dalla stessa cesta da cui gli altri hanno pescato, possiamo
comunque montarli in maniera corretta e fare qualcosa che sia piu'
informatico che ingegneristico.

1) Della struttura client: Come ho gia' detto abbiamo due opportunita'
ed entrambe interessanti:
        a) Client *non* browser: In questo caso quando il client parte e' solo
un canvas vuoto che ti chiede "dove saresti voluto andare ieri?" (oggi e
domani sono gia' occupati :) ) tu gli dai l'indirizzo pinco.palla del
server, l'applicazione si scarica i pezzi e parte. Una domanda potrebbe
essere: Come si scaricano i pezzi? Tutti insieme o un pezzo alla volta?
Con un (possible) call-tree, ottenutenuto in maniera  statica durante la
compilazione, possiamo tirare giu' l'albero "twig-by-twig". Ovviamente
tutto cio' che e' metaprogrammazione ce la battiamo alle pudenda :) E'
necessario comunque, per motivi "storici," usare la porta 80 e qualcosa
simil-HTTP(S) per via di firewall, filtri ed altre amenita'.
        b) Client browser: In questo caso si potrebbe compilare la parte client
dell'applicazione da scheme a javascript(con ajax). In questo caso
javascript sarebbe il backend di compilazione. Per usare l'applicazione
si accende il browser, si va all'indirizzo pinco.palla e la pagina si
crea. Questa compilazione la si fa una volta per tutte a tempo di
deployment dell'applicazione? Si compila cio' che server mentre si va?
Dobbiamo scrivere un interprete scheme in javascript per tutti i casi di
metaprogrammazione? Se i casi di metaprogrammazione diventassero troppo
pesanti sarebbero da sconsigliare?

2) Realizzazione di interfacce: Un grosso "vantaggio" delle web
applications di oggi e' che le interfacce grafiche sono facili da
programmare e si possono fare "carine" con poco (interprete-HTML
permettendo). Poi con sistemi quali JSF e' possibile staccare la parte
grafica dalla logica dell'applicazione. Possiamo fare un sistema che
renda semplice creare anche le interfacce? Non vorrei che si finisca in
un sistema alla X (vedi Xt etc...).

3) Della struttura del/dei server: I server comunicano tra loro
esattamente come nell'interazione client-server: RPC. Dato che
l'interazione e' la stessa: Un client si attacca ad un solo server? Un
client puo' direttamente attaccarsi a piu' server? Come conosco le varie
risorse? Queste infomrazioni vengono date al client dal primo server al
quale si collega, o le deve gia' sapere da prima?

4) I nostri concorrenti diretti: I nostri "concorrenti" diretti, sono i
web services. Se noi vogliamo fare esattamente lo stesso senza XML,
aggiungiamo poco, sarebbe bello riuscire a fare di piu' e meglio. Fare
meglio ci vuol poco, fare di piu' e' impegnativo. Cosa possiamo fare
piu' di loro, dato che fare meglio e' facile?

Per ora penso possa essere tutto, se mi viene in mente qualcos'altro vi
faro' sapere :)

Ciao a tutti: In Italia sono le 19:44 quindi buona cena!
Francesco

-- 

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"The best way to predict the future is to invent it."
-- Alan Kay
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=