Newsgroup: it.comp.java
Titolo: [FAQ-PROJECT] Requisiti

E va bene, facciamo partire questo progetto!
Per chi non avesse partecipato ai thread relativi, riassumo brevemente.
Durante una recente discussione è scaturito che il sistema di faq di 
it.comp.java, probabilmente sconosciuto a molti nuovi frequentatori, 
comincia a diventare obsoleto nei contenuti e nella tecnologia. Da qui 
varie discussioni e proposte finché non si è optato per la creazione di 
un sistema collaborativo, realizzabile in opensource, basato su un 
webservice per la gestione dei contenuti.
Si è anche stabilito che il modello architetturale del webservice sarà 
di tipo REST (vd. 
http://www.xfront.com/REST-Web-Services.html
).
In questo thread propongo di discutere i requisiti del FAQ system, 
partendo dai suggerimenti di ul (copio e incollo):
***
Brevemente, i requisiti ovvii:
- deve essere possibile fare operazioni CRUD sulle FAQ
- deve essere possibile fare semplici ricerche sulle FAQ
- deve essere possibile generare diverse rappresentazioni delle FAQ: HTML,
PDF, ecc.
- deve essere tutto RESTful per vivere pacificamente nel web, no RPC
- deve essere Java, a meno che non esista qualcosa di già perfetto da
installare così com'è. Per i requisiti qui sopra basterebbe praticamente
installare sqlRest (che è un Java :))
quelli da decidere:
- deve essere RSS compatibile? Ossia uno può per esempio iscriversi con
RSS ed essere notificato delle operazioni sulle FAQ?
- bisogna autenticarsi? Io dico di si, altrimenti chiunque può pubblicare
qualsiasi cosa. E soprattutto qual'è il modello? Wikipedia, con chiunque
che può scrivere, o un qualcosa in cui c'è un moderatore (o più di uno,
ovviamente) che deve approvare?
- Altri???
***
Io concordo su tutto. Voterei anche per la compatibilità RSS in quanto 
potrebbe diventare una risorsa importante per molti siti.
Il modello wikipedia è in realtà proprio quello a cui pensavo: mi sembra 
uno dei successi più grossi del modello collaborativo su internet. Al 
limite potremmo adottare dei meccanismi di "sicurezza passiva" - 
fondamentalmente backup e/o versioning - per metterci al riparo da 
improbabili vandalismi o errori più o meno involontari.
In questo modo IMHO sarebbe davvero uno strumento a disposizione del gruppo.
Ovviamente se il faq sistem dovesse diventare preda di scorribande 
barbariche saremo costretti a passare al modello con autenticazione e 
editor. Tuttavia trattandosi di un webservice RESTful, con normalissime 
interfacce HTTP, ci sarà di sicuro qualcosa di già pronto da mettere 
davanti/dentro il webserver per la protezione.
Altri requisiti per ora non me ne vengono in mente, ma forse c'è già un 
bel po' di carne al fuoco :)
Ciao!
pole
-- 
ammentos - a lightweight persistence framework for JDK5
http://www.sourceforge.net/projects/ammentos
http://ammentos.biobytes.it

 bel po' di carne al fuoco :)
Ragazzi quand'è pronto? Io ho fame...
Ciao,
jRed

 avere un quadro d'insieme!
Ecco tutto quello che ho trovato (e parzialmente letto). Ciao e buona
lettura.
La tesi che ha dato origine a tutto
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
La definizione su wikipedia, tanto per cambiare:
http://en.wikipedia.org/wiki/REST
In generale tutti gli articoli di Prescod, in particolare:
http://www.prescod.net/rest/rest_vs_soap_overview/
http://www.prescod.net/rest/mistakes/
Un altro summary:
http://www.xfront.com/REST-Web-Services.html
Molti articoli da 
xml.com
, tra cui diversi sempre di Prescod. Ve li ho
messi pure in ordine cronologico:
http://webservices.xml.com/pub/a/ws/2002/02/06/rest.html
http://webservices.xml.com/pub/a/ws/2002/02/20/rest.html
http://webservices.xml.com/pub/a/ws/2002/04/24/google.html
http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html
http://www.xml.com/pub/a/2004/07/21/dive.html
http://www.xml.com/pub/a/2004/08/11/rest.html
 (best practices)
http://www.xml.com/pub/a/2004/12/01/restful-web.html
http://www.xml.com/pub/a/2005/01/05/restful.html
http://www.xml.com/pub/a/2005/02/16/rest-report.html
http://www.xml.com/pub/a/2005/03/02/restful.html
http://www.xml.com/pub/a/2005/04/06/restful.html
http://www.xml.com/pub/a/2005/08/17/restful-web.html
Rest wiki (attualmente mi sembra giù il sito)
http://rest.blueoxen.net/cgi-bin/wiki.pl
sqlRest, un'implementazione RESTful di interfaccia CRUD su un RDBMS
http://sqlrest.sourceforge.net/
e l'indirizzo per testarlo
http://www.osmoticweb.com/rest-web-service-demo.htm
questo sono io, per esempio:
http://www.osmoticweb.com/sqlrest/CUSTOMER/120770
Restgate, dello stesso autore, per fare un po' di prove (PUT, DELETE, ecc.)
http://www.osmoticweb.com/restgate/
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 
http://www.osmoticweb.com/restgate/
Avevo già effettuato qualche prova...ora sarebbe solo da capire i vari 
meccanismi di implementazione in java...e tutto il resto...! :D
Una bella montagna di documenti...ma piano piano viene tutta assimilata!
Se non sbaglio cmq nelle specifiche delle servlet c'è la possibilità di 
implementere i metodi doGet, doPost, doDelete, doPut, corrispettivi alle 
varie richieste relative a REST...quindi non dovrebbe essere troppo 
strana come implementazione...
...ma potrei anche sbagliarmi...ancora non ho assimilato nulla! :D
Si potrebbe dare un occhiata anche a sqlrest...! :D
Ciao,
jRed

 strana come implementazione...
strana? E' http, è sempre stato così fin dai tempi di Tim Berners Lee! 
Stiamo semplicemente riappropriandoci dei concetti originali che per un
motivo o per l'altro sono andati persi nel tempo. E che sembra ci si stia
rendendo conto negli ultimi anni che questi sono più che sufficienti per
fare tutto quello che serve, senza complicarsi la vita con trucchetti RPC
inventati soprattutto per passare i firewall :)
uL


 uL
Esatto...ho appena dato un occhiato alla documentazione di SqlRest...e 
"loro" utilizzano una servlet principale che "mappa" le richieste in 
stile http con appunto i doGet, doPost, doPut, doDelete...
...un ritorno al passato...in maniera sempre ma molto efficace! :D
Forte! :D

 strana? E' http, è sempre stato così fin dai tempi di Tim Berners Lee! 
Solo un dubbio:
spinto dalla curiosità ieri ho provato a fare un po' di
curl -X DELETE <indirizzo>
su alcuni siti (miei eh? ;)), e come era lecito aspettarsi apache (ma 
suppongo anche IIS) risponde con un forbidden.
Quando implementeremo la doDelete nella nostra servlet dovremo quindi 
configurare diversamente anche il webserver immagino.
Allora, per il nome? Io proponevo icj, quale tributo al ng.
Non male anche jask, anche se per me meno evocativo :P


 qualsiasi cosa.
Consiglio n.1: okkio alle norme sulla privacy!
Consiglio n.2: ma siete sicuri che non basta un micro-CMS di quelli già 
esistenti ?
In realtà ho capito che il progetto lo mettete su per studio...perché 
invece non prendete una release stabile di un progetto open source e non 
fate una fork o un'estensione ? Molti progetti sono nati così :)
Cià
-- 
  -- + Setaceous Pig + --
http://megadix.users.mcs2.netarray.com/
http://www.jroller.com/page/megadix/

 Cià
Vuoi partecipare :) ?


 
Ehm, grazie per l'invito ma per ora sono a posto così :) CMQ se trovo 
qualche link interessante ve lo posto.
Aricià


 Ehm, grazie per l'invito ma per ora sono a posto così :) 
Pazienza :)


 ovviamente) che deve approvare?
La sezione FAQ del similwiki che uso io funziona più o meno così:
chiunque può inserire domanda e relativa risposta, ma solo alcuni 
possono validarla in modo che vada a finire (eventualmente corretta) 
nella pagina faq ufficiale. Così facendo chiunque propone e chi gestisce 
approva (all'incirca come adesso, anche se tutto viene fatto a manina 
dal santo di turno che si occupa della gestione delle faq)
bye
DKano

 
Attenzione alla differenza fra personali e sensibili. I sensibili sono 
quelli tipo cartelle cliniche, preferenze sessuali & co. I personali 
sono 'tutti gli altri'; ho tentato di avere una definizione più precisa 
da un paio di avvocati ma non ci sono riuscito e la definizione 
riportata nell'apposito decreto mi fa venire l'orticaria ogni volta che 
la guardo. Purtroppo temo che comunque per tenere dati personali ci 
voglia anche lì un responsabile legale e tutta una serie di 'piccole 
fastidiosissime regolette'. Forse l'unica scappatoia (per evitarsi il 
responsabile e tutto il resto) sarebbe (ma non ne sono certo) avere 
tutto criptato.
bye
DKano

 DKano
Grazie mille per le informazioni...il più delle volte è come dici tu...
Cmq per il fatto di avere tutto criptato non sarei sicuro...perchè in 
fin dei conti non garantisce una protezione assoluta in fronte ad un 
lucro di dati...ma forse mi potrei anche sbagliare! :D
Ciao,
jRed
PS: cmq ottime le informazioni e i chiarimenti dati...continuate cosi! ;)