UiTransfer

[supermac]

Mi han chiesto se sarebbe possibile replicare "in casa" un sistema come quello del noto WeTransfer senza le limitazioni sulle dimensioni dei files da inviare e sullo storage (capita ogni tanto che dobbiamo trasferire bombe da parecchi giga, finora abbiamo usato il sistema di un altro fornitore che però non verrà più fornito).

Ora replicare il loro meccanismo di upload file, messaggistica, verifica dei download, statistiche e amenità connesse per me non sarebbe niente di particolare, il fatto è che ne so poco sul "tecnico" di un upload di file di grandi dimensioni, timeout e cose così.... voglio dire, si usa veramente lo stesso "codice" di un upload file normale o è tutto un altro mondo con split del file, thread multipli in parallelo (sto inventando, non so davvero cosa ci possa essere dietro) e cose meno alla portata di tutti?

[supermac]

lo so che non c'è solo uitransfer

[alka]

Ora replicare il loro meccanismo di upload file, messaggistica, verifica dei download, statistiche e amenità connesse per me non sarebbe niente di particolare, il fatto è che ne so poco sul "tecnico" di un upload di file di grandi dimensioni, timeout e cose così.... voglio dire, si usa veramente lo stesso "codice" di un upload file normale o è tutto un altro mondo con split del file, thread multipli in parallelo (sto inventando, non so davvero cosa ci possa essere dietro) e cose meno alla portata di tutti?

Non conosco gli "internals" del funzionamento di WeTransfer, ma dai feedback visuali che produce l'applicazione do per scontato che abbiano un controllo più dettagliato della fase del download, ma nulla di trascendentale: vedi ad esempio questa documentazione.

Detta in due parole, quando l'utente fa drag+drop di un file sulla pagina Web, tramite JavaScript (usando in congiunzione la Drag & Drop API) sono tante le informazioni che poi acquisire in merito al suddetto file, nonché "pilotarne" diverse operazioni comprese l'upload ma non solo.

In giro trovi anche tanti plugin che forniscono "out of the box" logiche già pronte per riprodurre comportamenti molto simili a quelle di WeTransfer.

Devi documentarti su tutte queste possibilità per "assemblarle" e implementare quello che ti viene richiesto.

Ciao!

[supermac]

Mi impensierisce di più lo strato sottostante, ovvero la tecnologia per velocizzare l'upload, riduzione di banda, mantenere la pagina viva durante le operazioni, recuperare l'up/download in caso di buco della rete e cose di questo tipo.... magari non c'è niente di tutto questo ma lo troverei strano, credo che la cosa sia meno semplice di quel che riesco a vedere da utente insomma

(link interessante comunque, grazie)

[alka]

Mi impensierisce di più lo strato sottostante, ovvero la tecnologia per velocizzare l'upload, riduzione di banda, mantenere la pagina viva durante le operazioni, recuperare l'up/download in caso di buco della rete e cose di questo tipo....

Non ci sono tecnologie particolari per "velocizzare" l'upload o ridurre la banda, salvo avere una connessione decente.

La maggior parte dei protocolli di trasporto supporta nativamente la compressione, quindi non è richiesta nemmeno farla "in locale". Certo, non si esclude che possano esserci espedienti per trasferire meno dati alla fonte, o algoritmi particolari e aggiuntivi di compressione, ma se questi vanno implementati da zero, entriamo in un ambito dove si applicano principi di ingegneria del software che esulano dalle problematiche dell'upload in sé, e richiedono senz'altro competenze molto specifiche e abilità particolari.

Il "mantenere la pagina viva" non capisco come sia un problema, in quanto... non c'è nessuna pagina da ravvivare: via JavaScript si effettua il trasferimento e basta segnalare in chiusura della pagina all'utente l'eventuale operazione in corso, mentre la pagina non va ravvivata in quanto non c'è nulla da fare affinché "resti nel browser". O forse non ho capito a cosa ci stiamo riferendo...

In termini di recupero "up/download", ci sono diversi strumenti già presenti nel protocollo HTTP per gestirli, come la possibilità di fare range request: è il server che poi dovrà capire quale porzione del file si sta trasferendo e organizzare lo storage dei dati in modo da renderli "ripristinabili" (resumable, in inglese).

Insomma, le complessità ci sono, ma secondo me sono molto diverse (e peggiori) da quelle che tu pensi di avere.

[alka]

Mi impensierisce di più lo strato sottostante, ovvero la tecnologia per velocizzare l'upload, riduzione di banda, mantenere la pagina viva durante le operazioni, recuperare l'up/download in caso di buco della rete e cose di questo tipo....

Non ci sono tecnologie particolari per "velocizzare" l'upload o ridurre la banda, salvo avere una connessione decente.

La maggior parte dei protocolli di trasporto supporta nativamente la compressione, quindi non è richiesta nemmeno farla "in locale". Certo, non si esclude che possano esserci espedienti per trasferire meno dati alla fonte, o algoritmi particolari e aggiuntivi di compressione, ma se questi vanno implementati da zero, entriamo in un ambito dove si applicano principi di ingegneria del software che esulano dalle problematiche dell'upload in sé, e richiedono senz'altro competenze molto specifiche e abilità particolari.

Il "mantenere la pagina viva" non capisco come sia un problema, in quanto... non c'è nessuna pagina da ravvivare: via JavaScript si effettua il trasferimento e basta segnalare in chiusura della pagina all'utente l'eventuale operazione in corso, mentre la pagina non va ravvivata in quanto non c'è nulla da fare affinché "resti nel browser". O forse non ho capito a cosa ci stiamo riferendo...

In termini di recupero "up/download", ci sono diversi strumenti già presenti nel protocollo HTTP per gestirli, come la possibilità di fare range request: è il server che poi dovrà capire quale porzione del file si sta trasferendo e organizzare lo storage dei dati in modo da renderli "ripristinabili" (resumable, in inglese).

Insomma, le complessità ci sono, ma secondo me sono molto diverse (e peggiori) da quelle che tu pensi di avere.