Waiting for remote audio extraction in Java

0

In my college project I have a small Java API that extracts audio from video files, where the URL of the video is passed and an MP3 file is returned, 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 occur as follows: the user informs the link, the server low on itself and extracts the audio, after that, and made the audio available to the user.

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

    
asked by anonymous 07.07.2014 / 09:25

3 answers

1

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

The Jan Cássio option is very good, since you would already send the link to the client and would make that treatment on the file have been processed or not.

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

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

Atte;

    
08.07.2014 / 16:34
1

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

Thinking in a simple way, you can already generate the audio access link, 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) and in this way you will never have the link broken, the client will not wait for a response from the server and the server will only respond on demand. When the audio is ready, either you return a link to it, or return the changed location to the audio. As you are going to implement the client (I imagine), it is better to return a structured data (json, xml) with the result / status of the audio, because it gives you more flexibility to do whatever you want with it.

A good reference is Dropbox, try putting a very heavy file in your local Dropbox folder, letting it sync and creating 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 "uploading". If you want to go deeper, try doing this using the Dropbox API so you can see what is returned by your server.

    
08.07.2014 / 16:03
0

Sometimes simple solutions can be effective, I thought of something extremely simple, if I were you besides asking the URL of the video 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 the extraction in MP3, you will generate a single url can be random or incremental for each email with a link sent, you will need the http server to each client can connect and download the audios.

Customers have no impact at all, they just need to have a browser read the email and click on your link.

    
07.07.2014 / 12:58