>>>>> "Daniele" == Daniele Nicolodi <daniele@xxxxxxxxxx> writes: Daniele> Ciao, ho una semplice interfaccia web (Python) ad un Daniele> database che contiene blob binari di alcuni Mb (dati Daniele> sperimentali) associati a dei metadata. L'utente, una Daniele> volta individuati i dati che gli interessano attraverso Daniele> query sui metadati, può scaricare i blob binari. Daniele> Vorrei fare in modo che non sia solo possibile scaricare Daniele> ogni oggetto singolarmente, ma anche una lista di Daniele> oggetti. Quale è il modo più furbo per farlo? Daniele> Ho fatto qualche ricerca e sembra che il protocollo HTTP Daniele> supporti anche risposte con payload MIME multipart. In Daniele> principio sarebbe dunque possibile generare una risposta Daniele> multipart/related con dentro tanti attachment quanti sono Daniele> gli oggetti binari da scaricare. Il problema di questo Daniele> approccio è che richiede di costruire tutto il payload in Daniele> memoria prima di mandarlo al client (a meno di non Daniele> modificare le librerie MIME di Python) e, visto che ogni Daniele> singolo oggetto è qualche Mb, la cosa risulta un po' Daniele> pesante da fare. Daniele> In ogni modo ho provato a generare una tale risposta Daniele> multipart/related ed il browser non sembra interpretarla Daniele> correttamente (ma potrei star sbagliando qualcosa). Daniele> Altre idee più furbe? Ho anche io necessità simili, nel mio caso si tratta di sviluppare un proxy per il mobile che "comprima", una serie di chiamate ad API HTTP in un'unica transazione, mantenendo però una certa efficienza lato server. Devo dire che non ho ancora sviluppato questo componente perciò la mia ricerca è solo agli inizi, ma per quanto riguarda le possibilità del protocollo qualche sguardo intorno l'ho dato. Anche io mi son fermato per un po' sull'encoding multipart/related ma appunto il suo tallone d'achille sono la definizione della lunghezza totale del messaggio nell'header dell'unica risposta e forse anche un overhead di encoding base64 (ma dovrei rinfrescarmi la memoria), poi ho cambiato angolo di visione al problema ed ho scoperto l'encoding "chunked" di HTTP 1.1 [1]_ che sembra mettere assieme capra e cavoli, per avere una idea precisa ti consiglio 5 minuti di questo video introduttivo su node.js che lo supporta veramente bene ed in maniera efficiente: http://www.youtube.com/watch?feature=player_detailpage&v=jo_B4LTHi3I#t=945s detto questo io sarei curioso di approfondire nelle seguenti direzioni: a) Quanto e quale supporto c'è in Python (so che Twisted lo supporta ma non so con che efficienza e non conosco la situazione di altre librerie); b) Approfondire tecnoligie simil- Comet come WebSocket e vedere se e che strumenti utilizzano per rispondere alla medesima problematica. _[1]: http://en.wikipedia.org/wiki/Chunked_transfer_encoding -- Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO "subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx