[Koying]

Hi,

I'm implementing downloads thru JSON RPC and I face an issue regarding how to get the actual filename (without the path) of a file I download.

In the items details, we have "file", which is a server path, really, not easily usable on a remote client because it could be anything, depending on the source.

Then, with Files.PrepareDownload, we receive another path which is transport dependent, and not manipulable by a client because it could be anything, really.

My suggestion would be to return the filename (without the path) in the details returned from Files.PrepareDownload, together with "path".

I assume:
1) it would be easier for the server to extract a source independent filename than for a client.
2) every client using download would need a filename, so it seems logic to try to avoid that every client must implement complex regexp to extract the filename from the "file" field.

[Montellese]

Hi,

I'm implementing downloads thru JSON RPC and I face an issue regarding how to get the actual filename (without the path) of a file I download.

In the items details, we have "file", which is a server path, really, not easily usable on a remote client because it could be anything, depending on the source.

Then, with Files.PrepareDownload, we receive another path which is transport dependent, and not manipulable by a client because it could be anything, really.

My suggestion would be to return the filename (without the path) in the details returned from Files.PrepareDownload, together with "path".

I assume:
1) it would be easier for the server to extract a source independent filename than for a client.
2) every client using download would need a filename, so it seems logic to try to avoid that every client must implement complex regexp to extract the filename from the "file" field.

Please in the future either create a feature request ticket on Trac (and CC me) or post in the JSON-RPC Development Thread instead of opening a new thread for every idea because the "XBMC Development" board is not the place to post feature requests/ideas and I don't get notified everytime someone creates a JSON-RPC related thread in here (but I do get notified if someone creates a ticket on trac and CCs me or when someone posts in the JSON-RPC Development Thread).

Concerning your proposal. Why do you need a complex regular expression to extract the filename? It's as simple as:

1. Get the position of the last "/" (slash) in the "file" property
2. Extract everything after the position retrieved in step 1

No "complex" logic involved IMO. Futhermore the "details" object in Files.PrepareDownload is not standardized as it highly depends on the transport being used.

[Koying]

Please in the future either create a feature request ticket on Trac (and CC me) or post in the JSON-RPC Development Thread instead of opening a new thread for every idea because the "XBMC Development" board is not the place to post feature requests/ideas and I don't get notified everytime someone creates a JSON-RPC related thread in here (but I do get notified if someone creates a ticket on trac and CCs me or when someone posts in the JSON-RPC Development Thread).

Noted.

Concerning your proposal. Why do you need a complex regular expression to extract the filename? It's as simple as:

1. Get the position of the last "/" (slash) in the "file" property
2. Extract everything after the position retrieved in step 1

No "complex" logic involved IMO. Futhermore the "details" object in Files.PrepareDownload is not standardized as it highly depends on the transport being used.

Well, not quite. My XBMC is on Windows, so I get "\" for local paths and "/" for basically every other sources.
So I (and every other clients) would have to implement logic to check if it is a windows path. And I don't know if it is possible to have backspace escaped filenames if it is a unix path.
Generally, the "file" field is a server path, so it could contain anything depending on the source, so the client would have to take into account every single XBMC path type as they are added.

Work would be the same on the server, just that the server has the knowledge about the source types.

Re "depends on the transport being used", indeed, but we can assume a filename is something universal, not depending on source type or transport.

[topfs2]

Well, not quite. My XBMC is on Windows, so I get "\" for local paths and "/" for basically every other sources.
So I (and every other clients) would have to implement logic to check if it is a windows path. And I don't know if it is possible to have backspace escaped filenames if it is a unix path.
Generally, the "file" field is a server path, so it could contain anything depending on the source, so the client would have to take into account every single XBMC path type as they are added.

Work would be the same on the server, just that the server has the knowledge about the source types.

Re "depends on the transport being used", indeed, but we can assume a filename is something universal, not depending on source type or transport.

You cannot assume what you are streaming even has a "file". Consider PVR etc, then you might be streaming from live tv.

What you want to get is binary data, not limited to something stored on disk. So what you input in PrepareDownload is something the server knows, it will return an ID (and details) on how you can obtain that data. We could extend PrepareDownload with transcoding options and then what you receive is not the same as what is stored on disk either.

I'm not sure I understand why you need to know the server file, I can't find a single reason why it would be relevant for the client to know?. If you are missing data you try to parse from the file name please feature request that we add that as metadata instead.

Cheers,
Tobias

[Koying]

You cannot assume what you are streaming even has a "file". Consider PVR etc, then you might be streaming from live tv.

Indeed, but we are talking downloads, not streaming. Then just put the filename to blank if it doesn't have one.

I'm not sure I understand why you need to know the server file, I can't find a single reason why it would be relevant for the client to know?

For a first, the methods are named "...Download", so I assume they are there to download, not to stream, which implies, in wget terms, a destination filename.
Obviously, if the methods are actually only meant to stream, this discussion has no point.
I'd just open a new suggestion regarding the methods naming

The use case is to download music from my XBMC box directly to my phone, using XBMC JSON-RPC, from anywhere I am, assuming the proper network config.
It'd be good to know the original filename, obviously, but quite mandatory to know the file type, which I can only deduct from the filename.

What is returned from Files.PrepareDownload is an url path like "vfs/V%xx%xxmusic%xxfile%xxmp3" (don't remember the percent encoding for ":", "\" and ".") which is obviously hard to parse and the point is that every single client will have to implement the same code to parse it.

If it seems a better idea, just indicating the file type would be sufficient, I guess...

Regards
- Chris -

[topfs2]

Indeed, but we are talking downloads, not streaming. Then just put the filename to blank if it doesn't have one.

Download and streaming is essentially the same thing, download is just a stored stream. What you are referring to as a stream is something manipulative I guess? Seekable etc? This is all possible here but it is transport dependent.

What is done is probably more correctly streaming but we opted for the "download" naming as its easier to understand. I guess renaming to PrepareStream could be done, not sure if its worth it though.

For a first, the methods are named "...Download", so I assume they are there to download, not to stream, which implies, in wget terms, a destination filename.
Obviously, if the methods are actually only meant to stream, this discussion has no point.
I'd just open a new suggestion regarding the methods naming

The use case is to download music from my XBMC box directly to my phone, using XBMC JSON-RPC, from anywhere I am, assuming the proper network config.
It'd be good to know the original filename, obviously, but quite mandatory to know the file type, which I can only deduct from the filename.

What is returned from Files.PrepareDownload is an url path like "vfs/V%xx%xxmusic%xxfile%xxmp3" (don't remember the percent encoding for ":", "\" and ".") which is obviously hard to parse and the point is that every single client will have to implement the same code to parse it.

If it seems a better idea, just indicating the file type would be sufficient, I guess...

Regards
- Chris -

The filetype (or mimetype) could be returned in PrepareDownload if the transport wants to. Some transports do this in the redirect (as thats when it will check the file and can return the type of the file in the transports supposed way.) HTTP for example will give mimetype in the headers IIRC.

The problem with downloads and binary data is that its very very transport dependent unless we want to add a wrapper ontop of it (which was done in httpapi with base64 encoding) and wrapping it ontop is generally never a good idea as it adds lots of parsing on client side.

So from what I can gather here is that you want the original filename so you know what to store the downloaded file as?

[Koying]

What is done is probably more correctly streaming but we opted for the "download" naming as its easier to understand.

I understand the misunderstanding, then

The filetype (or mimetype) could be returned in PrepareDownload if the transport wants to. Some transports do this in the redirect (as thats when it will check the file and can return the type of the file in the transports supposed way.) HTTP for example will give mimetype in the headers IIRC.

Indeed, mimetype is the way to go, then.

Even for http streaming, I see a user case where you'd need to have the mimetype returned from "...Prepare...":
In a mobile environment, the url of the stream returned from "Prepare" would be passed to a specialized player (at least video vs. audio; possibly different video players depending on the type). Based on the mimetype returned from "Prepare", the app would be capable of launching the right player and pass it the url.

So from what I can gather here is that you want the original filename so you know what to store the downloaded file as?

Indeed, but a default filename could be created from the metadata. My real issue is to put a proper file extension.

[topfs2]

Sure adding mimetype in the return of Prepare would be a good addition, please make a feature request for it on trac. Stuff which needs to be discussed is if its transport dependent or not.