winPenPack - The Portable Software Collection : Forum / topic

Proposta auto-update

2026-05-21T16:36:51+02:00

Hi all, probabilmente molti di voi NON si ricordano di me perché non sono quello che può essere definito un "utente costante" (la spiegazione: essendo passato ad ubuntu come SO non ho potuto più utilizzare wpp sui miei PiCCi e quindi non potevo essere d'aiuto; ora ho nuovamente un pc con win e, una delle prime cose che ho fatto è installare wpp).Ultimamente si parla molto della capacità di auto-update delle applicazioni, infatti molte persone si affidano molto di più al software auto aggiornante che al software manuale (sia windows che linux utilizzano gli aggiornamenti automatici (e questa funzione è l'unica cosa che non peccava in vista)). Ora : mi sono fatto una lettura complessiva dei topic che riguardano l'argomento e avrei qualche proposta da farvi per il miglioramento della prestazione di wpp (anche se è già un ottimo software penso si avrebbe un miglioramento esponeziale attraverso i sistemi di seguito elencati)--Creare una "funzione di auto-update" da integrare nel core di WPPPro : Semplice e veloce, non c'è bisogno di intervento da parte dell'utente se non un semplice "sì" o "no"Con : Servirebbe un lavoro a livello di manutenzione 'robusto'Metodologia :Supporto DataBase MySql & php.Creare una pagina server-side che gestisce una richiesta GET effettuata da WinPenPack (magari anche con Username e Password) risposta in xml da parte della pagina, dopodiché WPP richiede all'utente se vuole aggiornare, in caso di risposta positiva, vengono passati i parametri ad una seconda pagina php che trasmette tramite http un file zippato che viene poi decompresso e gestito da WPP--Creare una "lista" da integrare nel core di WPP (soluzione minore che viene compresa nella prima)Pro : Non c'è bisogno di una configurazione maniacale per far funzionare le richiesteCon : L'utente è costratto a lavorare a mano e a scaricare il soft per conto suo, i feed fanno già questa cosa (anche se in maniera ridotta), validità non molto consistente.Metodologia :Supporto DataBase MySql &phpCreare una pagina server-side che gestisce una richiesta GET effettuata da WinPenPack, risposta in xml, segnalazione da parte di WPP (come ad esempio delle scritte in rosso oppure un ! per indicare la presenza di un aggiornamento.Cosa ne pensate ? (ovviamente il sottoscritto si propone (qualora richiesto) di creare l'applicativo (server-side, non sono molto pratico di programmazione con win ))

Re: Proposta auto-update

tomcat — 2026-05-21T16:36:51+02:00

Premesso che non ho capito troppo la spiega tecnica (ma è colpa mia, non sono un programmatore ), sono assolutamente d'accordo sull'implementazione di un sistema di auto-update delle applicazioni (che credo già adottato dalla "concorrenza"...). Se poi abbiamo già il candidato realizzatore del suddetto sistema... ma cosa stiamo aspettando?Scherzi a parte... è senz'altro l'aggiunta più richiesta su wPP. Mi verrebbe da dirti "prova a realizzare un prototipo" e rilasciamolo ad un ristretto gruppo di beta-tester: se la cosa funziona (e non vedo perchè non dovrebbe) potremo rilasciarla a tutti.

Re: Proposta auto-update

Pikk — 2026-05-21T16:36:51+02:00

tomcat ha scritto ...Premesso che non ho capito troppo la spiega tecnica (ma è colpa mia, non sono un programmatore ), sono assolutamente d'accordo sull'implementazione di un sistema di auto-update delle applicazioni (che credo già adottato dalla "concorrenza"...). Se poi abbiamo già il candidato realizzatore del suddetto sistema... ma cosa stiamo aspettando?Scherzi a parte... è senz'altro l'aggiunta più richiesta su wPP. Mi verrebbe da dirti "prova a realizzare un prototipo" e rilasciamolo ad un ristretto gruppo di beta-tester: se la cosa funziona (e non vedo perchè non dovrebbe) potremo rilasciarla a tutti. Il sistema server side lo si può sviluppare in un baleno (nemmeno una settimana ed è funzionante) il problema principale è che non conosco il linguaggio di WPP che presuppongo sia VB-like, quindi saranno gli sviluppatori del team WPP a doversene occupare,poi ovviamente mi son dimenticato di dire una cosa :il lavoro 'robusto' è questo :all'uscita di un nuovo x-software l'admin che sta eseguendo la modifica deve compiere le seguenti operazioni :hostarlo sul sito (cosa che già si fa)andare su una pagina (creata da me)inserire NOME, REVISIONE, LINK, ISUP (in sostanza se esiste una nuova versione del programma ad esempio : regshot 1.8 e 2.0)cliKKare su invio ed è fatta, dopodiché è tutto okkei, finita fino alla prossima.Ah, posso anche catalogare tutti i programmi già esistenti se viva

Re: Proposta auto-update

LordJim60 — 2026-05-21T16:36:51+02:00

@Pikk, la tua proposta è interessante ed in linea con quanto ci siamo proposti di fare, l'unica cosa è che non siamo ancora pronti per questa fase, perchè ho appena riscritto il menù (ancora in versione alpha) per adeguarlo a Vista e Seven e stiamo in una fase di test.Quello che mi servirebbe è un automatismo lato web per i contributori che oltre a deployare la nuova versione aggiornino un file XML, che potrà poi essere scaricato (in automatico o sotto richiesta è ancora da vedere ) dal menù per segnalare i prodotti che hanno subito variazioni.Comunque se hai disponibilità puoi anche iniziare in collaborazione con Danix Taf ZioZione a gettare le basi di questa applicazione, tieni conto che il DB MySql già c'è.Con me puoi parlare dei dati che indendo gestire.Giacchè ogni distribuzione wpp è una storia a se, preferisco avere il file completo sul server e lasciare al menù il compito di verificare le differenze. In questo caso non c'è bisogno di una applicazione che gestisca la richiesta GET, ma mi basta che il file sia fruibile dal WebServer.Saluti

Re: Proposta auto-update

Pikk — 2026-05-21T16:36:51+02:00

LordJim60 ha scritto ...@Pikk, la tua proposta è interessante ed in linea con quanto ci siamo proposti di fare, l'unica cosa è che non siamo ancora pronti per questa fase, perchè ho appena riscritto il menù (ancora in versione alpha) per adeguarlo a Vista e Seven e stiamo in una fase di test.Quello che mi servirebbe è un automatismo lato web per i contributori che oltre a deployare la nuova versione aggiornino un file XML, che potrà poi essere scaricato (in automatico o sotto richiesta è ancora da vedere ) dal menù per segnalare i prodotti che hanno subito variazioni.Comunque se hai disponibilità puoi anche iniziare in collaborazione con Danix Taf ZioZione a gettare le basi di questa applicazione, tieni conto che il DB MySql già c'è.Con me puoi parlare dei dati che indendo gestire.Giacchè ogni distribuzione wpp è una storia a se, preferisco avere il file completo sul server e lasciare al menù il compito di verificare le differenze. In questo caso non c'è bisogno di una applicazione che gestisca la richiesta GET, ma mi basta che il file sia fruibile dal WebServer.Saluti L'aggiornamento che ho in mente io non è del rude file xml ma dei campi, questi campi vengono salvati in una TABELLA mysql (so che lo avete già :--D) Non ho ben capito cosa intendi, ma penso sia inevitabile effettuare una chiamata GET (o POST [ma non c'è necessità di sforzare il server]) {altrimenti come la ricevi la lista in XML ?}.Per quanto riguarda l'architettura ti posso fare uno schemino :SETUP :Release -> Pagina d'aggiornamento (con login) -> Aggiornamento del database (i valor inseriti dall'admin non vengono salvati come XML ma come dati nella tabella)RICHIESTA :WPP -> Richiesta GET al server -> Pagina applicativa -> Risposta in XML (con una lista) -> Interpretazione di WPP e segnalazioneDOWNLOAD :WPP -> Utente che preme il bottoncino sì -> Pagina applicativa (per ogni software) -> risposta in formato .zip (viene passato il download) -> WPP -> Unpacking ed installazioneAl vostro via posso anche cominciare a sviluppare il tutto (non ci vorrà molto)

Re: Proposta auto-update

LordJim60 — 2026-05-21T16:36:51+02:00

Scusa, se io metto un file in una cartella di apache e esploro il sito la vedo, quindi posso fare un http download senza scomodare php o qualche CGI, è un lavoro che fa il web server di suo.

Re: Proposta auto-update

Pikk — 2026-05-21T16:36:51+02:00

LordJim60 ha scritto ...Scusa, se io metto un file in una cartella di apache e esploro il sito la vedo, quindi posso fare un http download senza scomodare php o qualche CGI, è un lavoro che fa il web server di suo.Cioè praticamente vuoi rubare il lavoro al database ?Il sistema che proponi tu è un po' "stazzoso" in sostanza ti espongo i 2 esempi :SENZA mysql :file.1La mia appVersioneRevisionefile.2La mia app 2Versione 2Revisione 2file.3La mia app 3Versione 3Revisione 3CON mysql :dati : app = La mia app; ver = Versione; rev = revisionephp fa il lavoro sporco e la converte ottenendo il primo risultatodopodiché lo restituisce come xml(anche se esplori il sito attraverso http, negli header dovrai specificare un metodo, quel metodo è GET XD)Morale : col primo (metodo) il file è statico e c'è una lista (insieme di file oppure unico) che occupa spazio ed è scomodo da aggiornarecol secondo (metodo) i file NON esistono, vengono generati solo dei "log" dalla pagina php che interpreta i dati archiviati nel MySql.

Re: Proposta auto-update

LordJim60 — 2026-05-21T16:36:51+02:00

si cosi devo fare una chiamata per ogni app che ho moltiplicato per tutti gli utenti che lo fanno?vabbè poi ne riparliamo.

Re: Proposta auto-update

LordJim60 — 2026-05-21T16:36:51+02:00

io vorrei un solo file xml che contiene tutti i dati dei pacchetti, lo scarico e me lo lavoro in locale.

Re: Proposta auto-update

Pikk — 2026-05-21T16:36:51+02:00

LordJim60 ha scritto ...io vorrei un solo file xml che contiene tutti i dati dei pacchetti, lo scarico e me lo lavoro in locale.Bhe, per come la metti tu sì :Richiesta X numero di applicativi X Utenti che la richiedono(1 x (es.) 100 x 1000 al giorno) =1000 query e 100000 elaborazioni da parte di phpMa ovviamente la richiesta deve essere inteLLigente ossia : WinPenPack deve richiedere SOLO i software installati (questo non è un mio problema XD, è necessario in qualche modo identificare i softs tramite un "marchio" (per gli x-soft può essere il file .ini del launcher, ma per i portable non saprei))100 query non sono niente (se poi stiamo parlando di qualche kb di dati ancora meno)l'elaborazione si basa su un pattern che viene applicato soltanto per uniformare i dati allo standard XML che viene interpretato da WPP

Re: Proposta auto-update

LordJim60 — 2026-05-21T16:36:51+02:00

a me serve il file con tutti i dati, la dimensione non credo sia eccessiva, io con 300 programmi ho un xml di 70kb e quello di wpp è un xml molto gonfio rispetto ai dati che dovremmo salvare. io applico sempre un pattern che recita +o- così: keep it simple, stupid!mi serve una cosa semplice, quindi una applicazione di deploy lato web che aggiorna anche questo file e la possibilità di scaricarlo per poter fare la notifica di tutte le applicazioni installate e aggiornate con un solo colpo. Oggi mi serve per questo, magari domani per altre funzionalità.

Re: Proposta auto-update

Pikk — 2026-05-21T16:36:51+02:00

LordJim60 ha scritto ...a me serve il file con tutti i dati, la dimensione non credo sia eccessiva, io con 300 programmi ho un xml di 70kb e quello di wpp è un xml molto gonfio rispetto ai dati che dovremmo salvare. io applico sempre un pattern che recita +o- così: keep it simple, stupid!mi serve una cosa semplice, quindi una applicazione di deploy lato web che aggiorna anche questo file e la possibilità di scaricarlo per poter fare la notifica di tutte le applicazioni installate e aggiornate con un solo colpo. Oggi mi serve per questo, magari domani per altre funzionalità.Ok, farò in modo di strutturarlo così, ma comunque mi servirà mysql:ecco lo schemino :SETUP (da parte degli admin) :Release (upload) -> Pagina d'aggiornamento -> Update della tabella mysql -> Generazione del file XML contenete la lista e save sul webserver, dopodiché SE il file esiste viene sostituito (posso anche fare un backup volendo) altrimenti viene semplicemente messo nella cartella.Il resto sta a WPP (ma questo file contiene TUUUUUUTTI i programmi che ci sono nell'area download, quindi sarà grandino, e le app non saranno tutte quelle quelle del WPP che effettua la chiamata al server)

Re: Proposta auto-update

LordJim60 — 2026-05-21T16:36:51+02:00

Tieni conto che il file XML dovrà avere solo:Nome AppVersione wppVersione prodottoin ogni caso programmi che gestiscano richieste GET serviranno, qualora l'utente voglia fare un upgrade in quel caso farà una richiesta specifica per il prodottola quale dovrà restituire diversi dati ( tra i quali mi piacerebbe anche la descrizione del prodotto ).

Re: Proposta auto-update

Pikk — 2026-05-21T16:36:51+02:00

LordJim60 ha scritto ...Tieni conto che il file XML dovrà avere solo:Nome AppVersione wppVersione prodottoin ogni caso programmi che gestiscano richieste GET serviranno, qualora l'utente voglia fare un upgrade in quel caso farà una richiesta specifica per il prodottola quale dovrà restituire diversi dati ( tra i quali mi piacerebbe anche la descrizione del prodotto ).Quindi in pratica :la lista "iper-gigante" che varia ad ogni cambiamento da parte di un admin ti va bene ?Invece per il download vuoi sempre una richiesta GET che restituisce-Nome-Rev-Versione-Descrizione???

Re: Proposta auto-update

LordJim60 — 2026-05-21T16:36:51+02:00

no, come la vedo io mi serve solo un file XML aggiornato ad ogni cambiamento che contenga per tutti i SW che vogliamo gestire:-Nome-Rev wpp-Versione( che magari tu hai anche messo in una tabella mysql insieme a gli altri dati )e immagino che questo file si trovi in una cartella del web in modo che io possa scaricarla quando voglio senza chiamare nessun script php, esempio:
http://www.winpenpack.com/main/upgrades/wppApplications.XML
( ovviamente è solo un esempio )poi in futuro prevedo delle chiamate specifiche a programmi php (che spero scriverai tu) che, passando come parametro il nome dell'applicazione, mi possano restituire dati aggiuntivi, es:link downloaddescrizioneetc.

Re: Proposta auto-update

Pikk — 2026-05-21T16:36:51+02:00

LordJim60 ha scritto ...no, come la vedo io mi serve solo un file XML aggiornato ad ogni cambiamento che contenga per tutti i SW che vogliamo gestire:-Nome-Rev wpp-Versione( che magari tu hai anche messo in una tabella mysql insieme a gli altri dati )e immagino che questo file si trovi in una cartella del web in modo che io possa scaricarla quando voglio senza chiamare nessun script php, esempio:
http://www.winpenpack.com/main/upgrades/wppApplications.XML
( ovviamente è solo un esempio )poi in futuro prevedo delle chiamate specifiche a programmi php (che spero scriverai tu) che, passando come parametro il nome dell'applicazione, mi possano restituire dati aggiuntivi, es:link downloaddescrizioneetc.Comincio a scrivere il codice

Re: Proposta auto-update

Pikk — 2026-05-21T16:36:51+02:00

LordJim60 ha scritto ...Pikk ha scritto ...Bhe, io costruisco sulla base delle preferenze che mi date, quelli che do io sono consigli... Comunque per il problema delle portabilizzazioni "non proprio a norma" c'è la possibilità di includere un "piccolo file" in ogni software in modo tale da richiamare soltanto le app registrate a wpp (e non partendo solo dall'elenco).Anche in questo caso continueremmo a complicare una cosa semplice solo per il gusto di mettere il programma php, sinceramente non ne vedo lo scopo.C'è un solo caso in cui vedo bene la soluzione di generazione online del file XML, ed è quella che tu, analizzando le tabelle MySql di e107 riesca a generare il file XML ( sempre completo ovviamente ) così come mi serve. Io una volta ho dato un occhiata a quelle tabelle, ma ovviamente sono orientate ad un CMS e non a catalogare il SW, però puoi dargli un occhiata. Per questo invito lo stranamente silenzioso Danix ad inviarti un dump della tabella che ci interessa in modo che tu possa studiarla. In questo caso sarebbe inutile il programma di deploy giacchè le info che ci servono si possono prendere direttamente dai dati del sito.Pikk ha scritto ...Oltretutto se avete preferenze per la versione di XML che devo utilizzare, o se devo inserire l'ID del download del programma(ad esempio : il software Xsi scarica dal sitowpp.com/download.php?view.9899quello è l'id che intendo io, poi sta a wpp aggiungere il sito e collegarlo con l'id per creare il link.)questo non è possibile giacchè nel file XML del menù di wpp questo dato non è presente, l'unica forma che abbiamo per identificare un SW è il nome che gli è stato dato, se un utente gli cambia nome perde la possibilità di verificare, se un utente da a un suo programma lo stesso nome che abbiamo utilizzato noi, anche in questo caso si avrebbero dati incongruenti.1) E cioè... come ti serve il file ?Non riesco a capire cosa intendi purtroppo, sono vicino all'analfabetismo settecentesco sigh*2) Cioè tu vorresti fare un confronto tra l'XML che ha il menù (quello su cui si basano le iconcine, per capirsi) ?Se la seconda fosse sì, penso che sia insensato, come proponevo prima, non è meglio gestire un XML a parte ?Oppure, per meglio dire, integrare un piccolo XML nella cartella del programma (in bin) in modo tale da richiamarlo al momento opportuno ?Se ci affidassimo ad un sistema fragile (e potenzialmente molto più modificabile (visto che lo si può fare via GUI)) sarebbe una cosa fallimentosa, costruire la torre sulla sabbia (in sostanza).3) Per id del soft intendo questo : wpp fa il confronto, se il soft non è "OK", appare una vocina nel menù (col tasto destro) che dice aggiorna, apre il browser e ti manda alla pagina di download del software

Re: Proposta auto-update

Pikk — 2026-05-21T16:36:51+02:00

L'applicazione che sto sviluppando è a livello beta (sistema funzionate, devo solo attuare qualche piccola miglioria) purtroppo la grafica non c'è, quindi si rimane alla famosa "whitepage + buttons", per il resto sembra tutto funzionante, la generazione del file xml parte da una base mysql dove c'è tutto l'archivio di dati.(Riporto l'argomento a galla : se anzicché generare il file e lasciarlo sul server potessimo utilizzare un file php che gestisce una richiesta get per generare il codice sul momento ed inviarlo a wpp non sarebbe maleAvremmo un minore impiego di risorse RO imensioni del file da inviare minori (sia per l'utente che lo deve scaricare che per noi che lo dobbiamo inviare)CON:1 query per ogni richiestaQuesta sistemazione ha la dicitura MYSQL FA IL LAVORO SPORCO X-D------------L'alternativa è la creazione di file xml per ogni singola applicazione, nonché richiesta di wpp tramite get ad una pagina php che restituisce i dati SENZA l'ausilio del mysql (che invece svolge la funzione di "libreria-backup")Questa sistemazione ha la dicitura PHP FA IL LAVORO SPORCO X-D (anche un po' apache)------------Ultima ma non per importanza è la struttura che sto costruendo ora, generazione dell'xml alla modifica di un singolo componente, tutti i dati di TUTTI i programmi sono in un unico file che viener richiesto da wpp tramite get via http diretto richiedendo ad apache (apache fa il lavoro sporco).)Inolte se è possibile vorrei sapere la versione di xml che devo utilizzare (e se nella lista ci va anche l'ID del download).

Re: Proposta auto-update

LordJim60 — 2026-05-21T16:36:51+02:00

Scusa ma non capisco perchè le dimensioni sono minori, a meno che l'utente non spedisca l'elenco di tutti i suoi programmi tu devi sempre inviarmi l'elenco completo altrimenti come faccio a fare il match? o tu pensi una soluzione dove l'utente chiede se c'è un aggiornamento per un singolo file? in questo caso è praticamente inutile per distribuzioni come la mia con 300 programmi.Se non ho capito, allora, cerca di farmi un quadro completo di come pensi la soluzione, perchè forse non ci stiamo capendo.Io provo a spiegare nuovamente come la vedo io:1) wpp chiede l'elenco delle applicazioni presenti sul server scaricando il file xml in una directory temporanea.2) fa il match tra la propria distribuzione ( che è diversa da utente a utente ) e per ogni programma nuovo segnala in un modo ancora da verificare ( icona new? ) che è presente un aggiornamento.3) L'utente per i programmi a cui è interessato accede al sito e scarica oppure scarica in forma automatica ( questo è ancora da vedere.

Re: Proposta auto-update

Pikk — 2026-05-21T16:36:51+02:00

LordJim60 ha scritto ...Scusa ma non capisco perchè le dimensioni sono minori, a meno che l'utente non spedisca l'elenco di tutti i suoi programmi tu devi sempre inviarmi l'elenco completo altrimenti come faccio a fare il match? o tu pensi una soluzione dove l'utente chiede se c'è un aggiornamento per un singolo file? in questo caso è praticamente inutile per distribuzioni come la mia con 300 programmi.Se non ho capito, allora, cerca di farmi un quadro completo di come pensi la soluzione, perchè forse non ci stiamo capendo.Io provo a spiegare nuovamente come la vedo io:1) wpp chiede l'elenco delle applicazioni presenti sul server scaricando il file xml in una directory temporanea.2) fa il match tra la propria distribuzione ( che è diversa da utente a utente ) e per ogni programma nuovo segnala in un modo ancora da verificare ( icona new? ) che è presente un aggiornamento.3) L'utente per i programmi a cui è interessato accede al sito e scarica oppure scarica in forma automatica ( questo è ancora da vedere.La richiesta di Wpp dovrebbe fare proprio quello.Wpp invia la sua listaPhp interpreta e generera l'XML dopodiché lo inviaWpp interpreta e segnala(Pensare ad una richiesta singloare (file per file) è improponibile, io intendevo sempre attraverso la richiesta iniziale di Wpp :Wpp richiedePhp interpreta e NON genera l'xml, ma li va a cercare nella cartella dove c'è un file per ogni programmaPhp assembla tutti questi file xml e genera la lista, dopodiché la inviaWpp Interpreta e segnala.)(Per quanto riguarda il download del file, io penso che sarebbe bello salvarlo in una delle directory di Wpp, in modo tale da avvisare l'utente anche offline (e magari implementare un sistema che disablita la segnalazione.)).

Re: Proposta auto-update

LordJim60 — 2026-05-21T16:36:51+02:00

cosi il giorno dopo stiamo su PCWin catalogati come spyware.a te piacerebbe avere una distribuzione che invia tutto il catalogo del tuo sw ad un sito? magari poi tu ti sei fatto qualche portabilizzazione non proprio in regola e ovviamente il menù invierebbe anche quella giacchè non ci sono elementi per discriminare.Non ci siamo Pikk, insisto... K.I.S.S.

Re: Proposta auto-update

Pikk — 2026-05-21T16:36:51+02:00

LordJim60 ha scritto ...cosi il giorno dopo stiamo su PCWin catalogati come spyware.a te piacerebbe avere una distribuzione che invia tutto il catalogo del tuo sw ad un sito? magari poi tu ti sei fatto qualche portabilizzazione non proprio in regola e ovviamente il menù invierebbe anche quella giacchè non ci sono elementi per discriminare.Non ci siamo Pikk, insisto... K.I.S.S. Bhe, io costruisco sulla base delle preferenze che mi date, quelli che do io sono consigli... Comunque per il problema delle portabilizzazioni "non proprio a norma" c'è la possibilità di includere un "piccolo file" in ogni software in modo tale da richiamare soltanto le app registrate a wpp (e non partendo solo dall'elenco).Io intanto continuo a sviluppare il sistema che genera l'xml statico (come hai detto tu), se poi cambiate idea fatemelo sapre Oltretutto se avete preferenze per la versione di XML che devo utilizzare, o se devo inserire l'ID del download del programma(ad esempio : il software Xsi scarica dal sitowpp.com/download.php?view.9899quello è l'id che intendo io, poi sta a wpp aggiungere il sito e collegarlo con l'id per creare il link.)

Re: Proposta auto-update

LordJim60 — 2026-05-21T16:36:51+02:00

Pikk ha scritto ...Bhe, io costruisco sulla base delle preferenze che mi date, quelli che do io sono consigli... Comunque per il problema delle portabilizzazioni "non proprio a norma" c'è la possibilità di includere un "piccolo file" in ogni software in modo tale da richiamare soltanto le app registrate a wpp (e non partendo solo dall'elenco).Anche in questo caso continueremmo a complicare una cosa semplice solo per il gusto di mettere il programma php, sinceramente non ne vedo lo scopo.C'è un solo caso in cui vedo bene la soluzione di generazione online del file XML, ed è quella che tu, analizzando le tabelle MySql di e107 riesca a generare il file XML ( sempre completo ovviamente ) così come mi serve. Io una volta ho dato un occhiata a quelle tabelle, ma ovviamente sono orientate ad un CMS e non a catalogare il SW, però puoi dargli un occhiata. Per questo invito lo stranamente silenzioso Danix ad inviarti un dump della tabella che ci interessa in modo che tu possa studiarla. In questo caso sarebbe inutile il programma di deploy giacchè le info che ci servono si possono prendere direttamente dai dati del sito.Pikk ha scritto ...Oltretutto se avete preferenze per la versione di XML che devo utilizzare, o se devo inserire l'ID del download del programma(ad esempio : il software Xsi scarica dal sitowpp.com/download.php?view.9899quello è l'id che intendo io, poi sta a wpp aggiungere il sito e collegarlo con l'id per creare il link.)questo non è possibile giacchè nel file XML del menù di wpp questo dato non è presente, l'unica forma che abbiamo per identificare un SW è il nome che gli è stato dato, se un utente gli cambia nome perde la possibilità di verificare, se un utente da a un suo programma lo stesso nome che abbiamo utilizzato noi, anche in questo caso si avrebbero dati incongruenti.

Re: Proposta auto-update

LordJim60 — 2026-05-21T16:36:51+02:00

non riusciamo proprio a capirci, tutto ciò che proponi prevede significativi cambiamenti a tutte le distribuzioni che al momento sono in circolazione e questo non è ragionevole. A me serve un file XML "GLOBALE" che con una struttura simile a questa:

....

Re: Proposta auto-update

Pikk — 2026-05-21T16:36:51+02:00

LordJim60 ha scritto ...non riusciamo proprio a capirci, tutto ciò che proponi prevede significativi cambiamenti a tutte le distribuzioni che al momento sono in circolazione e questo non è ragionevole. A me serve un file XML "GLOBALE" che con una struttura simile a questa:

....

Nè una informazione di più ne una di meno.PS) 1) Io non credo che pensare ad una elaborazione distribuita sia insensato.2) Non ho ancora capito cosa proponi tu senza trasformare wpp in uno spyware, per favore spiegati meglio.EDITNon riesco a formattarlo ma comunque si capisceAllora, probabilmente è colpa del mio analfabetismo settecentesco D: Tenterò di essere il più chiaro possibile :Le mie proposte sarebbero :IdeaAggiungere un "piccolo file XML" ad ogni programma per poterlo identificare (SOLAMENTE se si fa la richiesta a php per ottenere la lista (cosa che ho capito non ti va molto a genio))SpiegaWpp raccimola i "piccoli file XML", li unisce, trasmette questo contenuto a php, php elabora e restituisce una lista con SOLO i programmi richiesti, wpp riceve la lista, la interpreta e poi...EsempioNella cartella di Z-photo c'è IL "piccolo file XML" che contiene il seguente codiceX-Zphoto1.24oppure ConclusioniL'XML su cui si basa il menù di wpp è STACCATO dal sistema che definisce i programmi quando si richiede la listaIdeaA prescindere dalla precedente (sia che si utilizzi la chiamata per ottenere l'XML, sia se l'XML è già pronto e lo prendi dal server).Aggiungere nel file XML una voce : l'id del download qui su wpp.SpiegaViene semplicemente aggiunta una voce in cui è indicato il numerino del download (che identifica la pagina del programma)EsempioX-Zphoto1.24578oppure ConclusioneQuesto sistema è pressoché inutile al fine pratico se attuato da solo, vedere l'idea successivaIdeaAggiungere una voce nel menù col click laterale su ogni applicazione non aggiornata (il menù è quello che si apre clickando col pulsante destro su un collegamento ad un'applicazione del menù di wpp)SpiegaQuesto sistema non fa che aggiungere solo una che permette a wpp (una volta interpretato l'XML con i programmi) di segnalare all'utente se il programma è da aggiornare, inoltre, clickando su questa voce, non viene effettuato al download, ma si apre il browser con la pagina del download.EsempioAvviaApri cartella programmaAggiorna------Salva listaOpzioniCerca fileecc...Una volta clickkato sulla voce aggiorna wpp apre il browser prendendo l'id (ad esempio 578, quello di prima) e ci aggiunge la stringa 'http://www.winpenpack.com/main/download.php?view.' (senza virgolette) ottenendo così 'http://www.winpenpack.com/main/download.php?view.578' senza virgolette, il link viene passato al browser, che porta l'utente sulla pagina di download.ConclusioneSenza un sistema di riconoscimento da parte di wpp (come quello citato sopra) è impossibile da fare, molto utile al fine pratico, evita all'utente la fatica di cercare il download (e riduce il traffico (anche se di poco))Spero di essermi espresso bene stavolta

Re: Proposta auto-update

LordJim60 — 2026-05-21T16:36:51+02:00

Senti, io proprio non capisco perchè vuoi complicare così la vita... scusami...io dovrei aggiornare circa 53mila distribuzioni di wpp facendo scaricare questi filetti che devono essere prodotti , da non so chi ma non è questo il punto.oltretutto dovrei rispedire indietro queste info trasformado il menu in uno spyware ( che già ti ho detto che non voglio ) Io mi scarico il file, in circa 2 millesimi di secondo lo elaboro con buona pace di tutti. tra l'altro lo fa un thread e quindi l'utente non deve aspettare, quando l'informazione sarà pronta verrà presentata.Per quanto riguarda l'ID non è proponibile, e sarebbe troppo lungo spiegare il perchè, inoltre tieni conto che c'è la retrocompatibilità e il file XML deve essere aperto ( e scritto ) anche dal vecchio menù.Io termineri qui la discussione, se puoi fallo altrimenti non importa, se poi, proprio ti scappa di fare un programma php che crea il file XML, valuta la possibiltà che ti ho proposto in un post precedente, ovvero quella di leggere le tabelle di e107.Saluti

Re: Proposta auto-update

Pikk — 2026-05-21T16:36:51+02:00

LordJim60 ha scritto ...Senti, io proprio non capisco perchè vuoi complicare così la vita... scusami...io dovrei aggiornare circa 53mila distribuzioni di wpp facendo scaricare questi filetti che devono essere prodotti , da non so chi ma non è questo il punto.oltretutto dovrei rispedire indietro queste info trasformado il menu in uno spyware ( che già ti ho detto che non voglio ) Io mi scarico il file, in circa 2 millesimi di secondo lo elaboro con buona pace di tutti. tra l'altro lo fa un thread e quindi l'utente non deve aspettare, quando l'informazione sarà pronta verrà presentata.Per quanto riguarda l'ID non è proponibile, e sarebbe troppo lungo spiegare il perchè, inoltre tieni conto che c'è la retrocompatibilità e il file XML deve essere aperto ( e scritto ) anche dal vecchio menù.Io termineri qui la discussione, se puoi fallo altrimenti non importa, se poi, proprio ti scappa di fare un programma php che crea il file XML, valuta la possibiltà che ti ho proposto in un post precedente, ovvero quella di leggere le tabelle di e107.Saluti essì, sono molto assillante vero ? XD brutto caratteraccio, non penso di essere in grado di elaborare le tabelle di e107, troppo complesse sasal'idea dell'id e del menù mi piaceva molto, speriamo che in un secondo momento si possa attuare, per ora mantengo tutto ciò come me lo hai chiesto.l'architettura è quella che hai indicato tu nel vecchio post vero ?

Re: Proposta auto-update

ZioZione — 2026-05-21T16:36:51+02:00

Ciao Pikk, ciao LordJim60,premetto che questa discussione riapre un argomento da sempre "spinoso" perché è stato già affrontato a vari livelli e con alterne fortune, ma non essendo poi stato mai concretizzato (per inutili lungaggini e complicazioni di chi pensava di avere sempre e comunque la soluzione giusta...) potete farvi un'idea del perché noi della "vecchia guardia" siamo così restii nel gettarci subito a pesce quando rispunta fuori...Quindi direi, LordJim60, che tu puoi continuare tranquillamente a fare quello che ben sai, senza preoccuparti di seguire questa discussione passo passo.Per quanto riguarda te, Pikk, ti siamo certamente molto grati per l'entusiasmo che stai mettendo in questa cosa: se anche solo la metà degli utenti mettessero il tuo impegno nel far crescere questo progetto, a quest'ora avremmo già un nuovo menu scintillante con tutti gli optional! Naturalmente, affinché il tuo contributo possa essere veramente utile, occorrerebbe un po' più di disponibilità all'ascolto. Quindi ben venga il brainstorming, ma non mettiamoci troppo a concretizzare: qui servono più fatti e meno parole... Ad esempio, se rileggi quanto scritto da LordJim60, lo schema non è

ma
...
e basta... Keep it simple!Detto ciò, condivido al 100% la linea di LordJim60: è più che sufficiente avere un singolo file xml da scaricare dal nostro sito, generato a runtime (per garantirne l'aggiornamento costante) a seguito della richiesta del singolo utente verso una pagina php o un database (ma anche altro). Non trovo né utile né necessario dover rimandare indietro informazioni al server, quindi con un singolo download risolviamo tutto. Resterebbe eventualmente in sospeso il problema della gestione del pregresso (cosa fare con i programmi già installati, magari anche rinominati dall'utente?), ma direi che abbiamo già abbastanza carne al fuoco già così...Passo e chiudo.CordialmenteZioZione

Re: Proposta auto-update

Pikk — 2026-05-21T16:36:51+02:00

ZioZione ha scritto ...Ciao Pikk, ciao LordJim60,premetto che questa discussione riapre un argomento da sempre "spinoso" perché è stato già affrontato a vari livelli e con alterne fortune, ma non essendo poi stato mai concretizzato (per inutili lungaggini e complicazioni di chi pensava di avere sempre e comunque la soluzione giusta...) potete farvi un'idea del perché noi della "vecchia guardia" siamo così restii nel gettarci subito a pesce quando rispunta fuori...Quindi direi, LordJim60, che tu puoi continuare tranquillamente a fare quello che ben sai, senza preoccuparti di seguire questa discussione passo passo.Per quanto riguarda te, Pikk, ti siamo certamente molto grati per l'entusiasmo che stai mettendo in questa cosa: se anche solo la metà degli utenti mettessero il tuo impegno nel far crescere questo progetto, a quest'ora avremmo già un nuovo menu scintillante con tutti gli optional! Naturalmente, affinché il tuo contributo possa essere veramente utile, occorrerebbe un po' più di disponibilità all'ascolto. Quindi ben venga il brainstorming, ma non mettiamoci troppo a concretizzare: qui servono più fatti e meno parole... Ad esempio, se rileggi quanto scritto da LordJim60, lo schema non è

ma
...
e basta... Keep it simple!Detto ciò, condivido al 100% la linea di LordJim60: è più che sufficiente avere un singolo file xml da scaricare dal nostro sito, generato a runtime (per garantirne l'aggiornamento costante) a seguito della richiesta del singolo utente verso una pagina php o un database (ma anche altro). Non trovo né utile né necessario dover rimandare indietro informazioni al server, quindi con un singolo download risolviamo tutto. Resterebbe eventualmente in sospeso il problema della gestione del pregresso (cosa fare con i programmi già installati, magari anche rinominati dall'utente?), ma direi che abbiamo già abbastanza carne al fuoco già così...Passo e chiudo.CordialmenteZioZioneConcordo pienamente, bhe, per il fatto dell'xml, presumevo che ci fosse la dichiarazione del linguaggio, non pensavo non vi servisse , continuo a sviluppare ciò che già mi avete richiesto, e mi spiace che il mio comportamento aggressivo vi abbia infastidito, lo faccio solo per rendere il progetto un po' migliore.Per quello che riguarda i programmi rinominati... l'unica cosa da fare lì è la richiesta a php ma, da quanto ho capito, non la volete proprio... L'unica soluzione che mi viene in mente è quella, spero che possiate trovare una soluzione a questo problema.Vi tengo aggiornati, ho quasi completato il beta-testing e sto pensando alla grafica (minimalista, s'intende).

Re: Proposta auto-update

ZioZione — 2026-05-21T16:36:51+02:00

Ciao Pikk,Pikk ha scritto ...Concordo pienamente, bhe, per il fatto dell'xml, presumevo che ci fosse la dichiarazione del linguaggio, non pensavo non vi servisse nessun problema, era solo per evidenziare che con XML intendiamo solo la notazione, non necessariamente il file in sé.Pikk ha scritto ...continuo a sviluppare ciò che già mi avete richiesto, e mi spiace che il mio comportamento aggressivo vi abbia infastidito, lo faccio solo per rendere il progetto un po' migliore.Anche qui, per me non c'è nessun problema. Quello che tu chiami (chissà perché) "atteggiamento aggressivo" per me è semplicemente ansia propositiva e di ben figurare. Qui, però, non c'è nessuna gara a chi arriva prima (quindi stai tranquillo da quel punto di vista), ma la collaborazione di tutti, a qualsiasi livello (anche solo, quindi, per smuovere un po' le acque) serve per arrivare ad uno scopo comune, che è la crescita di questo progetto.Pikk ha scritto ...Per quello che riguarda i programmi rinominati... l'unica cosa da fare lì è la richiesta a php ma, da quanto ho capito, non la volete proprio... L'unica soluzione che mi viene in mente è quella, spero che possiate trovare una soluzione a questo problema.Vi tengo aggiornati, ho quasi completato il beta-testing e sto pensando alla grafica (minimalista, s'intende).Anche facendo una richiesta al server, se i programmi si chiamano in modo diverso non c'è che l'utente stesso che possa capire se sono la stessa cosa o meno, quindi direi di no: è inutilmente dispendiosa e non risolve il problema in maniera definitiva. A regime si potrebbe ovviare con un ID univoco associato a ciascuno dei programmi (cioè un ID per ogni programma, indipendentemente da versione e release), ma questa, appunto, è un'altra storia... Vedremo in seguito quale sarà la strada migliore da seguire...Buon lavoro a tutti! CordialmenteZioZione

Re: Proposta auto-update

Pikk — 2026-05-21T16:36:51+02:00

zandet2 ha scritto ...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.CiaoEcco 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

Re: Proposta auto-update

zandet2 — 2026-05-21T16:36:51+02:00

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 software2) confronto con software presenti nel pack ed estrapolazione elenco software da aggiornare3) esposizione all'utente dall'elenco4) gestione della scelta utente dei software da aggiornare5) download degli X-Software selezionati dall'utente6) 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 aggiornamenti2) 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 XDrive3) 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 disposizione5) 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 scaricato6) 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 successiviC) 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 funzionaliUn 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

Re: Proposta auto-update

Pikk — 2026-05-21T16:36:51+02:00

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 eliminatoB)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 aiutare2) 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 oscuri4) 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 35) 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 autoupdateAggiornamento manuale per i portable (con reindirizzamento alla pagina di download)Concordo in piena lineaD)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)

Re: Proposta auto-update

LordJim60 — 2026-05-21T16:36:51+02:00

Io volevo solo fare una funzione che avvisa quali programmi sono stati aggiornati...

Re: Proposta auto-update

zandet2 — 2026-05-21T16:36:51+02:00

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

Re: Proposta auto-update

zandet2 — 2026-05-21T16:36:51+02:00

LordJim60 ha scritto ...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!

Re: Proposta auto-update

LordJim60 — 2026-05-21T16:36:51+02:00

zandet2 ha scritto ...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.

Re: Proposta auto-update

Pikk — 2026-05-21T16:36:51+02:00

LordJim60 ha scritto ...zandet2 ha scritto ...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)