Differences between revisions 8 and 9
Revision 8 as of 2003-11-14 14:47:06
Size: 8154
Editor: anonymous
Comment:
Revision 9 as of 2003-11-15 11:22:41
Size: 8303
Editor: anonymous
Comment:
Deletions are marked like this. Additions are marked like this.
Line 81: Line 81:
""quest"": Quindi il client in reata' e' composto da due componenti, un client/interfaccia
ed un deamon che fa collezione di dati. (Sbaglio?!?!?)

Butto giu' il planning, aggiornate cosa vi viene in mente e cio' che ho dimenticato.

TODO

DEFINIZIONE PROTOCOLLO

  • Client Linux
    • Proc Scanner
    • Network scanner (Irc - Ftp - http - smtp - pop/imap)?
    • Avatar manager
    • Interfaccia
  • Client Winzoz:
    • Proc Scanner
    • Network scanner (Irc - Ftp - http - smtp - pop/imap)?
    • Avatar manager
    • Interfaccia
  • Server:
    • Tcp protocol
    • Sms protocol
    • Interfaccia di amministrazione
    • Generatore Mappa
  • Phone Stuff
    • Cell scanner (capire quali telefoni lo permettono)
      • --[soprattutto capire la fattibilita' a parte i telefonini javacazzi che dovrebbe essere semplice (smilzo!!!)]--
  • Ambient:
    • Sistema generale gdr
      • Ambientazione fantasy (sfartolante? dindon?)
      • Ambientazione Cyberpunk
      • Ambientazione Anni 30
      • Ambientazione eta' pietra
      • Ambientazione Solcazzo
  • World Contact
    • Pagina web e sito comunita'
    • web interface???
    • Mailing Lists??

Definizione Organizzazione:

Scusate se parlo subito di questa parte.. ma gia' scrivendo questo doc mi sono ritrovato a dover avere delle esigenze di rioganizzazione, nel senso che vedrei la cosa divisa in gruppi, non assolutamente chiusi , anzi , aperti e trasformabili (la vecchia regola nessuno necessario tutti utili). I gruppi si interfacceranno tra loro. Questa cosa puo' creare confusione, ma la vedo necessaria per poter procedere con ordine e evitando che ci siano disparita' di sviluppo. Credo che pochissimi di noi abbiano codato in Team, e questo puo' essere oltretutto un banco di prova per questa cosa. Quando si coda da soli e' bello perche' decidi il cazzo che vuoi tu e se ti serve una cosa te la fai.. per esperienza personale QUESTO E' LA MORTE in gruppo.. ognuno si fa le sue funzioni o si soddisfa come vuole le sue esigenze e questo fa del codice e dei sitemi LA MORTE. Un'organizzazione in team dove pero' ,se devo fare una cosa che influenza un altro team ,va chiesta dovrebbe permetterci di mantenere un certo ordine cercando di avere ovviamente massima autonomia sia TRA i gruppi sia ALL'INTERNO dei gruppi. (Porco dio mi sembra di parlare come un project manager.. che merda) Per il tipo di organizzazione (Wiki pubblici per team? ml separate?) demando la decisione in la'... io lavorerei con Wiki e mail in CC e terrei solo UNA ml generale dove siamo tutti.. in questo modo il modificare di un gruppo non comporta nulla (solo il cambio dei CC) ma poi ognuno si organizza come vuole, inoltre il wiki ci serve per evitare che ogni volta che ho un dubbio su come fare una cosa che influenza qualcun'altro debba andare a mandare delle mail.. posso andare a leggermi il wiki del gruppo e magari fare li la domanda. Qualcuno dira' che la cosa diventa complessa a livello di organizazzione e che magari per ora siamo 4 e quindi a che cazzo serve? Io partirei subito cosi', anche se poi ci staremmo tutti e 4 nei gruppi.. a quel punto il wiki sara' uno e il cc uno.. ma partiamo gia' con questa idea altrimenti ci potremmo poi ritrovare infognati in una discussione infinita o venti mail al giorno.

Definizione Protocollo:

Questa risulta secondo me la parte piu' importante..dato che e' la definizione di quello che il sistema comprende, accetta e rimanda. Intendo quindi in generale le possibilita' del coso. Ovviamente deve essere il piu' espandibile possibile e anche abbastanza generale. Per questo stavo pensando a XML come trasporto. In modo da poter inviare facilmente sia su tcp sia su sms, inoltre permette anche una semplice integrazione esistendo parser XML praticamente per QUALSIASI Linguaggio e SISTEMA operativo. La definizione dell'XML da mandare bisogna farla... servira' quindi probabilmente un gruppo che crei questa definizione.. che ovviamente va fatta passo passo e soprattutto ingrandita ad esigenza. Prevederei pero' sempre un gruppo di persone che si preoccupa di accettare le richieste fatta dai varti gruppi che svilupperranno le altre parti (ovviamente non e' che qualcuno fara' solo questo.. ci sara' certamente una fusione di gruppi)

Client --(Linux e Winzoz}--

Il client sara' secondo me il CAZZO IN CULO piu' grosso.. nel senso che tecnicamente assolutamente piu; stimolante ma anche piu' duro. Le cose che dovra' fare sono :

  • Leggere il proc, cioe' trovare un modo per vedere ceh programmai vengono eseguiti sul computer, con quale frequenza generare delle statistiche che vanno a modificare l'avatar. qui ovviamente va discusso anceh come i prog usati influenzano l'avatar (emacs e vi danno punti magia (o psionici o modifiche cyborg a seconda dell'ambientazione?). irc e mail variano il carisma e l'empatia? insomma.. sta robba qui.
  • Leggere il network traffic e statisticizzarlo. Questo serivra' per veder ele url viste (e farne una list adi hash) piuttosto che vedere a quante persone si mandano mail.. a da quante personesi ricevono, o quanto si sta in chat o quanto si usa napster e p2p etc.. (sempre per variare l'avatar in base a questo.
  • Leggere il FS e cercare file di certi tipi (sempre [er il discorrso di cui sopra ) chi ha tanti avi o mp3 o doc o altro (lavorerei non sulle dir standard del sistema operativo ma quelle create dall'utente.. Home e cose come repository mp3 e film e stuff, quanta roba in ftp pubblico.. insomma.. penso che avete acapito.

Con questa robba abbiamo qualcosa che ci modifica l'avatar a seconda di quello che facciamo col pc, (senza quindi che ognuno si scelga le caratteristiche ma che siano una risultante di quello che facciamo)

L'avatar manager dovrebbe usare queste info e permettere di cambiare cmq alcune cose (descrizioni personali, aspetto o cose del genere..}

L'interfaccia vera e propria e ' quella che prenderea' i dati dal server e visualizzera' il mondo.. contando che ,secondo me, la comunicazione va fatta in XML sara' un mega parser con interfaccia di vario tipo (al'inizio penso che sara' principalemente test.. ma potrebbe diventare facilmente 2d o 3d (python con blender? che e' crossplatform?)

""quest"": Quindi il client in reata' e' composto da due componenti, un client/interfaccia ed un deamon che fa collezione di dati. (Sbaglio?!?!?)

Server:

Questo dovra' essere uno dei primi passi da affrontare e andra' ingrandendosi ad esigenza dei client o delle idee che verranno da qui alla fine del mondo. Ci potremmo basare su un server MUD gia' esistente (ce ne sono molti e di ben fatti) e da li dovra' permettere pero' la comunicazione in XML (sempre che decidiamo di usare questa tecnologia)

Dovra' mantenere il mondo , questo se decidiamo di usare qualcosa di esistente dobbiamo capire come lo fa.. altrimenti trovare una soluzione (fs? DB?)

modificare la definizione del mondo e permettere quindi al client di immettere le descrizioni dei luoghi generati.

Dobbiamo inserirci anche un generatore di mondi basato sugli hash che arrivano dagli utenti (hash delle URL visitate e dei luoghi che troveremo consoni (Irc channel? Ftp? ML?) dando una descrizione random generale e decente.. (e qui interverrano gli ambientalisti). Inoltre bisognera' generare delle statistiche per capire quali luoghi si spostano verso il centro del mondo e quindi gestire una localizzazione della mappa che si generera' in base a coordinate polari (ma potremmo anceh pensar di gestirla solo in cartesiane che e' piu' semplice e anche piu' reale a parte ambientazioni space...} bisogna poi discutere sulla navigabilita' del mondo. Come attraverso le varie zone.. cosa vedo? come interagisco?

Ah! bisognera' interfacciare il server a qualche sistema di IM (Jabber?) in modo da permettere ovviamente agli utenti collegati (e scollegati) di interagire tra di loro, conoscendosi comunicando e creando spazi usati (e per questo accentrati) rispetto al mondo. Ovviamente i punti di entrata dovranno essere vari.. non solo uno o solo il centro.. ma magari basasti sui luoghi piu' frequentati.. ognuno si ritrova all'inizio nel luogo che di solito frequenta di piu'.

Per la comunicazione sms bisogna proprio farci un ragionamento sopra.. ma io cmq la demanderei a successivi sviluppi.. visto che il problema telefonino sara' il piu' grosso .. almeno all'inizio.

L'interfaccia di amministrazione parla da se.

ThreadGates (last edited 2008-06-26 10:00:14 by anonymous)