Ciao, On Thu, Sep 5, 2019 at 12:08 PM [email protected] [it-torino-java-jug] <[email protected]> wrote: > WebSocket.Listener può essere implementata come una specializzazione di > Flow.Subscriber con il metodo onNext() che ritorna un CompletitionStage, cioé > un onNext() capace di notificare quando il messaggio è stato consumato, > esattamente quello che ha chiesto Luigi.
E' il contrario. Puoi implementare Flow.Subscriber in termini di WebSocket.Listener, ma ovviamente perdi l'efficienza di WebSocket.Listener. Flow.Subscriber.onNext() ritorna void, quindi non puoi ritornare un CompletionStage. > Se fosse possibile rilasciare esplicitamente le risorse di tipo ByteBuffer e > CharSequence (come per Netty) non ci sarebbe stato bisogno di questa > specializzazione e Luigi avrebbe potuto semplicemente utilizzare un > ByteBufferPool (similmente a Netty). Se mia nonna avesse le ruote... Sono le applicazioni che possono dire quando non usano più un ByteBuffer. Netty wrappa ByteBuffer in una classe propria. Nulla vietava ad Amazon di progettare una API che invece di prendere un ByteBuffer prendeva una classe propria che wrappava ByteBuffer e a quel punto poteva aggiungere una API di "release()" come fa Netty (o come facciamo noi in Jetty). > I WebSocket potrebbero essere consumati come Stream Reattivi, invece è stata > riscritta una interfaccia ad-hoc incompatibile con Subscriber. Meno male! Questo è stato discusso e bocciato. Meglio una API potente ed efficiente come WebSocket.Listener che una API minimale ed inefficiente come Flow.Subscriber che mi *obbliga* ad allocare nuovi oggetti per ogni dato. Se proprio vuoi usare Flow.Subscriber, è triviale wrappare WebSocket.Listener in un Flow.Subscriber. WebSocket.Listener è più generica e copre più casi di Flow.Subscriber e pertanto è stato deciso che era meglio questa API che una più limitata. > Inoltre non è neanche possibile scrivere un adattatore di Flow.Subscriber per > WebSocket.Listener poiché non è possibile comunicare quando la risorsa sia > consumata, a meno di non farsi una copia di tutti i messaggi ricevuti. Certo che è possibile scrivere un adattatore di Flow.Subscriber per WebSocket.Listener (ed è anche triviale). Il fatto che tu debba farti una copia di tutti i dati (o di allocare nuovi oggetti) è una limitazione di Flow.Subscriber: stai cercando di adattare una API più potente ad una più limitata e per forza devi pagare qualcosa. -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
