[Linuxtrent] Re: HTTP response con attachement multipli

  • From: azazel <azazel@xxxxxxxxxxxxxxx>
  • To: linuxtrent@xxxxxxxxxxxxx
  • Date: Fri, 17 Feb 2012 16:10:32 +0100

>>>>> "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


Other related posts: