Waiting for remote audio extraction in Java

Question

In my college project I have a small API in Java that extracts audio from video files, where is passed the URL of the video and is returned an MP3 file, so far so good.

I would like to keep a server performing the tasks of downloading the video and then extracting the audio and on the other side a client waiting for the link to download the MP3 file. This would happen as follows: the user informs the link, the server downloads it itself and extracts the audio, after that, and made audio available to the user.

But how would I do that to the client? I would like to implement the client on Android, but how to keep it waiting for the download of the video and extraction to then deliver the MP3 link to download? It’s like I’m a Listener, but there is a communication between client and server. RMI, SOAP, WSDL? I would like a solution that does not impact a possible implementation for iOS or WP.

Answer 1

I think letting the client wait for audio processing is not a good idea, as you should consider larger files and probably worryif this on the client side would force him to implement something native and this would go against his concern about the project being cross-platform.

The Jan Cassio option is very good, because you would already send the link to the client and would make this treatment about the file have been processed or not.

There are other ways to do this but each requires more complexity in implementation.

If the tips of the above colleagues are not enough we will reopen the possibilities.

Atte;

Answer 2

You can keep communication active between two points (client and server), through sockets, in your case a simpler and cheaper solution to implement works just as well.

Thinking in a simple way, you can already generate the access link to the audio, from the moment the video is delivered to the server to process, even without having the audio ready. When the link is accessed, you can return an audio status (Processing, complete, error, or anything of the kind) and this way you will never get the link broken, the client will not be waiting for a server response and the server will only respond on demand. When the audio is ready, either you return a link to it, or you return the changed Location to the audio. As you will implement the client (I imagine), it is better to return a structured data (json, xml) with the result/audio status, why give more flexibility to you do what you want with it.

A good reference is Dropbox, try putting a very heavy file in your local Dropbox folder, let it sync and create a sharing link, when you try to open the link before the file is ready, it returns in the browser a page saying that the file is "rising". If you want to go deeper, try this using the Dropbox API to see what’s returned by its server.

Answer 3

Sometimes simple solutions can be effective, I thought of something extremely simple, if I were you apart from asking for the video URL I would ask for the user’s email, and also on the server side would open an http server(apache, ISS, etc).

For each video received from a user I would send an email with the download link after extraction in MP3, you will generate a unique url can be random or incremental for each email with link sent, you will need the http server so each client can connect and download the audios.

Customers have no impact whatsoever, they just need to have a browser read the email and click on its link.