<< Previous thread | Next thread >> |
Proposta auto-update Go to page << |
Author | Post |
zandet2 |
| ||
Registered Member #3184 Joined: Tue 06 Mar 2007 - 11:52Location: Busto Arsizio Posts: 3301 | Ciao a tutti, non me ne vogliate, intervengo per frenare un po' gli entusiasmi, e contemporaneamente complicare di molto le specifiche. Scusate la prolissità del post, ma l'argomento è molto più complicato di quanto può sembrare. Dal mio punto di vista bisogna tenere ben presente il mantenimento delle performance del sito, delle implicazioni che comportano migliaia di utenti che effettuano gli aggiornamenti, dei tipi di software da aggiornare, della mole dei dati da scaricare, della situazione del menu attuale ecc. ecc. Quindi, elenco per punti (per comodità, non per importanza) quali sono gli argomenti di cui tenere conto. A) Server web ritengo che dal server web non debba essere assolutamente richiesta nessuna operazione attiva (query, interrogazioni tabelle ecc...), per evitare rallentamenti nella fruizione del sito e per non far crollare tutto l'impianto se un domani l'admin decide di cambiare piattaforma da e107 a qualsiasi altra cosa ritenga migliore. Dal sito dovrà essere scaricato solamente un file contenente l'elenco statico dei programmi con tutte le informazioni necessarie, che a mio avviso potrebbero essere: - ID software (se vogliamo seguire la strada indicata da ZioZione) - Tipo di software (X-Software / X-Launcher / Portable) - Categoria/sottocategoria del software (eventuale, solo per chiarezza) - Nome del software - Versione del software - Numero della Release - Descrizione breve del software (eventuale, solo per chiarezza) - Dimensioni del software - Hash (desiderata da sviluppare) - Link alla pagina di download - Link al download Il formato del file al momento per me non è importante (txt, csv, xml, JSon, FreddyKruger); come verrà creato va poi analizzato con l'admin, ad esempio si potrebbe pensare a una query giornaliera ad orario fisso. B ) UpdateManager (nome "convenzionale") la gestione degli update dovrà essere sviluppata in un programma separato dal menu attuale, per garantire la retrocompatibilità per tutta l'utenza e in attesa di una nuova versione del wppMenu; come quale linguaggio sarà sviluppato non è al momento fondamentale, l'importante è che sia Open Source (vabbè), eseguibile su sistemi operativi diversi, e agevolmentente manutenibile e ricompilabile anche da persone che non siano lo sviluppatore iniziale (Delphi docet). Le funzionalità fondamentali dovranno essere: 1) connessione al sito e recupero situazione software 2) confronto con software presenti nel pack ed estrapolazione elenco software da aggiornare 3) esposizione all'utente dall'elenco 4) gestione della scelta utente dei software da aggiornare 5) download degli X-Software selezionati dall'utente 6) installazione X-Software Cerco di entrare un po' nelle problematiche di ogni punto: 1) la connessione a internet dovrebbe (desiderata) gestire anche i proxy, anche quelli con accesso "blindato" da utenza e password, altrimenti tutta l'utenza inserita in reti aziendali non sarebbe in grado di effettuare gli aggiornamenti 2) il software dovrà lavorare in una struttura winPenPack; per garantire la retrocompatibilità nei pack l'unico modo per avere le informazioni è leggersi i file INI nella cartella XDrive 3) l'esposizione dovrà segnalare all'utente le dimensioni degli aggiornamenti disponibili, l'utente deve sapere che aggiornare X-7Zip (2 MB) non è come aggiornare X-OpenOffice (180 MB) 4) durante la scelta l'utente deve sempre sapere quale sarà la dimensione complessiva dei download selezionati, per poter decidere se può permettersi la mole di download con la sua connessione a disposizione 5) tenendo valido quanto al punto 1) per l'accesso a internet, i download possono essere fatti nella cartella "Download" del pack, gestendo però i download interrotti o già presenti nella cartella per eventuali sovrascritture, similmente a quanto fatto per l'utility JavaGet; eventualmente si può implementare l'uso dell'hash per verificare la correttezza di quanto scaricato 6) UpdateManager dovrà effettuare anche l'installazione, in quanto (nota dolente) il wppMenu attuale non prevede esecuzioni massive ma solo installazioni manuali di singoli X-Software; le installazioni dovranno essere effettuate da UpdateManager una alla volta, verificando che il software interessato non sia già in esecuzione, spostando/rimuovendo il file originale dopo l'installazione per evitare riesecuzioni o problemi con download successivi C) X-Software vs Portable Software (vs X-Launcher) L'aggiornamento automatico potrà avvenire solo per gli X-Software, dal momento che ogni Portable fa storia a se, e le indicazioni di come effettuare le installazioni sono presenti nelle singole schede di download; inoltre winPenPack non distribuisce direttamente i software, ma rimanda sempre alle pagine di download esterne di ogni programma. Situazione analoga per gli X-Launcher, dove wPP non distribuisce i software ma solo lo "strumento" che permette la portabilizzazione. Quello che potrà effettuare l'UpdateManager sarà quindi evidenziare la presenza di una nuova versione, e sarà poi cura dell'utente collegarsi al sito, recuperare il software, installarselo. D) Problematiche funzionali Un aspetto di cui bisogna tenere conto è che attualmente esistono diversi limiti al download giornaliero, necessari per permettere a tutta l'utenza di usufruire dei contenuti in modo ottimale ed efficiente: con il sistema degli aggiornamenti automatici questi limiti verrebbero aggirati, a meno che non si inserisca nel software un sistema di autenticazioni di accesso (assolutamente fuori luogo). I software sono inoltre ospitati su siti mirror, alcuni collagati a wpp, altri no come ad esempio Sourceforge e bisognerebbe valutare anche su questi gli impatti di un accesso massivo per il download: immaginate 50.000 utenti che accedono contemporaneamente per scaricare l'aggiornamento di X-OpenOffice.... Vedete che i gli argomenti sono tanti, ognuno con le sue difficoltà, e tutto questo senza parlare di aspetto grafico, metodo di sviluppo, linguaggio da utilizzare, e senza entrare nel dettaglio dell'analisi e dello sviluppo. Ciao | ||
Back to top |
Pikk |
| ||
Registered Member #13527 Joined: Fri 12 Sep 2008 - 17:18Posts: 29 | Purtroppo non sono un maestro dell'autoit quindi non vi posso aiutare nell'interpretazione client-side sorry, per quello che ho capito tu vorresti (sinteticamente): A) Avere più info nel file XML (o Freddy XD) (cosa NON possibile attualmente (per motivi oscuri e troppo lunghi da spiegare (se ho ben capito))) Per quanto riguarda la generazione del suddetto file penso che il cron non sia l'idea migliore, infatti il sistema che sto sviluppando effettua l'analisi della tabella e genera il file ogni volta che qualcosa viene modificato, aggiunto o eliminato B) Sempre client-side, non posso aiutarvi... (Non penso che produrre un auto-updater in java possa aiutare (i programmi girano solo su Windows, su linux stentano visto che Wine non è proprio quello che si può dire "un buon costruttore", ogni tanto fallisce) Ma su alcune cose c'è da dire qualche parolina : 1) connessione al sito e recupero situazione software (e su questo siamo d'accordo) 2) confronto con software presenti nel pack ed estrapolazione elenco software da aggiornare (anche su questo) 3) esposizione all'utente dall'elenco (e anche su questo) 4) gestione della scelta utente dei software da aggiornare (ed anche su questo) 5) download degli X-Software selezionati dall'utente (impossibile da realizzare (spero solo attualmente) a causa dei motivi oscuri) 6) installazione X-Software (completamente fuori luogo dato che senza ID o link per il download del programma non c'è niente da fare) 1) la connessione a internet dovrebbe (desiderata) gestire anche i proxy, anche quelli con accesso "blindato" da utenza e password, altrimenti tutta l'utenza inserita in reti aziendali non sarebbe in grado di effettuare gli aggiornamenti --Client-side, non posso aiutare 2) il software dovrà lavorare in una struttura winPenPack; per garantire la retrocompatibilità nei pack l'unico modo per avere le informazioni è leggersi i file INI nella cartella XDrive --Non sarebbe meglio integrare il software in winPenPack, nel menù ? 3) l'esposizione dovrà segnalare all'utente le dimensioni degli aggiornamenti disponibili, l'utente deve sapere che aggiornare X-7Zip (2 MB) non è come aggiornare X-OpenOffice (180 MB) --Sarebbe bello ma impossibile a causa dei motivi oscuri 4) durante la scelta l'utente deve sempre sapere quale sarà la dimensione complessiva dei download selezionati, per poter decidere se può permettersi la mole di download con la sua connessione a disposizione --Come punto 3 5) tenendo valido quanto al punto 1) per l'accesso a internet, i download possono essere fatti nella cartella "Download" del pack, gestendo però i download interrotti o già presenti nella cartella per eventuali sovrascritture, similmente a quanto fatto per l'utility JavaGet; eventualmente si può implementare l'uso dell'hash per verificare la correttezza di quanto scaricato --Ottima idea (ma c'è sempre il problema misterioso per cui l'hash non si può mettere) 6) UpdateManager dovrà effettuare anche l'installazione, in quanto (nota dolente) il wppMenu attuale non prevede esecuzioni massive ma solo installazioni manuali di singoli X-Software; le installazioni dovranno essere effettuate da UpdateManager una alla volta, verificando che il software interessato non sia già in esecuzione, spostando/rimuovendo il file originale dopo l'installazione per evitare riesecuzioni o problemi con download successivi --Client Side... C) Aggiornamento download automatico : X-software e menù di wpp, non ché del programma (se fosse separato) di autoupdate Aggiornamento manuale per i portable (con reindirizzamento alla pagina di download) Concordo in piena linea D) La soluzione c'è e posso svilupparla io, ma purtroppo c'è sempre un problema : Non sono in grado di sincronizzare i download dal portale di e107 e quelli che utilizzano il download automatico: esempio : Un utente può scaricare 10 file al giorno da e107 (cifra simbolica) Se metto come limite 10 al sistema che costruisco, quei 10 file si sommano : si ottiene così 10 dal portale e 10 dall'auto update (i portable non vengono contati dato che si fa il redirect sul sito) | ||
Back to top |
LordJim60 |
| ||
Registered Member #33962 Joined: Sat 18 Jul 2009 - 08:45Location: Roma Posts: 1147 | Io volevo solo fare una funzione che avvisa quali programmi sono stati aggiornati... | ||
Back to top |
zandet2 |
| ||
Registered Member #3184 Joined: Tue 06 Mar 2007 - 11:52Location: Busto Arsizio Posts: 3301 | Pikk, il mio prolisso post non voleva essere un'assegnazione dei compiti, ma un mettere in chiaro i reali problemi di cui si deve tenere conto nell'affrontare l'argomento Auto Update. Il primo fondamentale motivo per cui l'elaborazione in toto deve essere eseguita da un client è che NON bisogna appesantire il sito; scaricare un file statico non è come ottenere le stesse informazioni con migliaia di query ripetute da migliaia di utenti. Secondo fondamentale motivo (l'oscuro motivo), il menu attuale non è manutenibile: è scritto in Delphi (che praticamente nessuno conosce), lo sviluppatore originale ha perso l'interesse a portare avanti il progetto, l'ambiente di sviluppo è difficilmente assemblabile, lo strumento di sviluppo CodeGear non è opensource, anzi, la licenza costa migliaia di euro. Ecco perchè non abbiamo intenzione di mettere mano al wppMenu attuale. Se leggi tra le righe poi, LordJim ha già anticipato che è in corso di riscrittura del menu con strumenti totalmente differenti, e non è il caso di appesantire il lavoro attuale con ulteriori (non così semplici) funzionalità. Spero di aver chiarito il mio punto di vista, come dice ZioZione l'Auto Update è un argomento su cui siamo sempre stati molto sensibili, ma le molte difficoltà ci hanno finora frenato dall'affrontare l'argomento. Ciao | ||
Back to top |
Pikk |
| ||
Registered Member #13527 Joined: Fri 12 Sep 2008 - 17:18Posts: 29 | zandet2 wrote ... Pikk, il mio prolisso post non voleva essere un'assegnazione dei compiti, ma un mettere in chiaro i reali problemi di cui si deve tenere conto nell'affrontare l'argomento Auto Update. Il primo fondamentale motivo per cui l'elaborazione in toto deve essere eseguita da un client è che NON bisogna appesantire il sito; scaricare un file statico non è come ottenere le stesse informazioni con migliaia di query ripetute da migliaia di utenti. Secondo fondamentale motivo (l'oscuro motivo), il menu attuale non è manutenibile: è scritto in Delphi (che praticamente nessuno conosce), lo sviluppatore originale ha perso l'interesse a portare avanti il progetto, l'ambiente di sviluppo è difficilmente assemblabile, lo strumento di sviluppo CodeGear non è opensource, anzi, la licenza costa migliaia di euro. Ecco perchè non abbiamo intenzione di mettere mano al wppMenu attuale. Se leggi tra le righe poi, LordJim ha già anticipato che è in corso di riscrittura del menu con strumenti totalmente differenti, e non è il caso di appesantire il lavoro attuale con ulteriori (non così semplici) funzionalità. Spero di aver chiarito il mio punto di vista, come dice ZioZione l'Auto Update è un argomento su cui siamo sempre stati molto sensibili, ma le molte difficoltà ci hanno finora frenato dall'affrontare l'argomento. Ciao Ecco svelato l'oscuro motivo ! Non l'avevo inteso come "assegnazione dei compiti", infatti la mia risposta si riferisce a quello che sto realizzando (riferito ai punti che hai messo in evidenza), visto che, sarebbe inutile per me costruire qualcosa che non serve. Ho letto qui e là che state sviluppando un nuovo menù, ma mai avrei pensato che non sarebbe stato lo stesso di tutte le altre versioni. A questo punto, forse è meglio aspettare la prima uscita di questo nuovo menù per poter cominciare a fantasticare con le funzioni avanzate di auto-update | ||
Back to top |
zandet2 |
| ||
Registered Member #3184 Joined: Tue 06 Mar 2007 - 11:52Location: Busto Arsizio Posts: 3301 | LordJim60 wrote ... Io volevo solo fare una funzione che avvisa quali programmi sono stati aggiornati... Si si, questo era chiaro, e l'analisi di dettaglio che hai allegato (sempre valida!!! ) ha spiegato perfettamente il giro che stava prendendo questo topic. Quello che volevo rendere chiaro è che se si parla di AutoUpdate gli argomenti da sviluppare sono tanti e difficili; cosa diversa se invece si vuole fornire una funzione di AvailableUpdates (o "Sono disponibili aggiornamenti"), sembra un sofisma da niente sui nomi ma in realtà sotto c'è un vero e proprio abisso. Tra parentesi, senza andare tanto lontano, una base da cui partire per sviluppare una simile funzione ci sarebbe già: winPenPack Versions List. Ciao! [ Edited Wed 08 Sep 2010 - 20:27 ] | ||
Back to top |
LordJim60 |
| ||
Registered Member #33962 Joined: Sat 18 Jul 2009 - 08:45Location: Roma Posts: 1147 | zandet2 wrote ... Tra parentesi, senza andare tanto lontano, una base da cui partire per sviluppare una simile funzione ci sarebbe già: winPenPack Versions List. Ciao! Quella è una funzionalità che integrerò in modo nativo nel nuovo menù (solo per Pikk: quel programma l'ho scritto io ) , e se avessi quel famoso file XML fare il match sarebbe una sciocchezza. | ||
Back to top |
Pikk |
| ||
Registered Member #13527 Joined: Fri 12 Sep 2008 - 17:18Posts: 29 | LordJim60 wrote ... zandet2 wrote ... Tra parentesi, senza andare tanto lontano, una base da cui partire per sviluppare una simile funzione ci sarebbe già: winPenPack Versions List. Ciao! Quella è una funzionalità che integrerò in modo nativo nel nuovo menù (solo per Pikk: quel programma l'ho scritto io ) , e se avessi quel famoso file XML fare il match sarebbe una sciocchezza. E io te lo fornirò (coro di soprano XD) | ||
Back to top |
Go to page <<
Moderators: Danix, Taf, Rcs, Energy, zandet2, ZioZione, Admin, LordJim60 |