sho Wrote:Sorry, I thought as soon as something was on the public wiki it was open for discussion.
But it's not like it's the outline of the next stealth bomber
Hehe, was mostly joking with you
. I did not link to it mostly because I was thinking it might have been good to wait until if our community got a spot but discussion is always good so it really doesn't matter
And what are you saying, this is a stealth bomber !!!
@
pecinko
Well what you are proposing is still a hack/workaround IMO and isn't it enough with one already? Can't keep taking the short way out anymore
Also if you read my proposal the main goal is NOT to create a finished and all together perfect server but to iron out libraries which could be used and to create a proper base (and create the server as a testground for the libraries, so it will work but far from finished). It is GSoC, you are supposed to do somewhat crazy stuff during that. Most projects are a bit out of there and are to spur development. They should be usable when complete but its often more important (IMO) that they start something which will (keyword) become something used in the future, and continues to be developed.
EDIT: The classical saying comes to mind "aim for the stars and you might hit the sky"
grajen3 Wrote:@topfs2
I was really interested in this topic and tried to do a little research and found out that using upnp standards may be problematic (or I'm missing something). Essentially what I want to say - upnp docs don't say anything about "Library scheme" - it seems that it's "vendor specific" (or simply I couldn't find how it should be implemented).
I used this doc: http://www.upnp.org/specs/av/UPnP-av-Con...ervice.pdf
Yeah this is something I'm worried about myself, I haven't done enough research on the matter and this are stuff which definitely needs to get ironed out before we decide on the project. There are lots of other small problems which is that there is no standard for the metadata either, in this case however I was hoping to set a standard which could be used by other media centers as well (media portal, myth (who already uses uPnP besides their main protocol) and even if its vendor specific we can perhaps iron out enough so that its perfect for the media centers which uses that scheme but works for those which is not (by works I mean its possible to navigate etc.)
This brings me onto this:
hippojay Wrote:I thought there was a JSON interface now, so you could probably wirte a similar plugin as we did for Plex to get the library using VideoLibrary.GetMovies)?
I don't see anything which would allow a file to be downloaded from XBMC (there is Files.Download but not sure what this provided) but if XBMC knows the location, then surely it can serve out the file fairly easily?
I could be talking rubbish though...
You could for sure use JSON RPC to do much of this and a matter of fact my idea (have not written that yet) is to use that for managing, i.e. so it can be used to control the server. This means a) can piggy back on webinterfaces done for XBMC and b) xbmc can piggy back on normal GUIs made for the server and c) it gives us a chance to make JSON RPC (our spec, our api) outside xbmc and to iron out the managing part which we want in the API no matter.
Files.Download is a method which gives information about how to acquire the file, i.e. it depends on the transport. HTTP will give you a url you can get the file from and TCP (when implemented) might give you a port you can download it from. JSON RPC lets the transport be in charge of the downloading which means that its standard HTTP, i.e. what many uPnP implementations afaik use. This means you can for sure use JSON RPC to stream files so if uPnP turns out to not work we can just use JSON RPC, however I'd prefer to use something which is less XBMC-specific but it is a fallback.