topfs2 Wrote:Anyone having access to the database can both read, edit and completely destroy the database at a there leisure. This is something which is not at all good, something which should be sandboxed and impossible for a client to do unless explicitly allowed to do, which is what jsonrpc sets out the fix.
The database is either in a sqlite db file or in mysql. The client has access to it.
Quote:It is, but why should a client need to do this at every release. i.e. it needs to first parse out what version XBMC is then it needs to create the select statement. XBMC handles this perfectly in the GUI code and a client should ideally be able to just ask "Get all movies" and the it should get them, no matter what version the database is. This is why jsonrpc is design how it is.
I used perl via http GET like so
xbmc.pl?genre=horror&type=moviesbygenre
xbmc.pl?type=moviesbydate
And format the output in a way that is readily split on a delimeter and parsed w/ a regex by the controller. Having the response formatted how I need it outweighs any effort required to tweak my select statements should XBMC change the DB table structures around.
Not sure how that exposes the database to mre risk than a json call.
I'm strictly pulling metadata
I could just as well use a JSON library in Perl and translate responses from XBMC into something readily parsable in iViewer.
well i wont read the raw JSON stream, i will do as Fiasco insted.
@
Fiasco, you want to share your xbmc.pl?
Regards
Pr.Sinister Wrote:#2) What is the proper syntax for VideoPlayer.SeekPercentage ? I have tried pretty much everything i can think of including :
Code:
{"jsonrpc": "2.0", "method": "VideoPlayer.SeekPercentage", "params": {"": "50"}, "id": "1"}
{"jsonrpc": "2.0", "method": "VideoPlayer.SeekPercentage", "params": {"": 50}, "id": "1"}
{"jsonrpc": "2.0", "method": "VideoPlayer.SeekPercentage", "params": {"parameter": "50"}, "id": "1"}
{"jsonrpc": "2.0", "method": "VideoPlayer.SeekPercentage", "params": [50], "id": "1"}
{"jsonrpc": "2.0", "method": "VideoPlayer.SeekPercentage", ["50"], "id": "1"}
You haven't tried all the possibilities
Currently you'll have to use
Code:
{"jsonrpc": "2.0", "method": "VideoPlayer.SeekPercentage", "params": 50, "id": "1"}
and yes this is not the way it is described in the json rpc 2.0 specification. I'm currently working on getting this changed/fixed so that you can either use
Code:
{"jsonrpc": "2.0", "method": "VideoPlayer.SeekPercentage", "params": [50], "id": "1"}
or
Code:
{"jsonrpc": "2.0", "method": "VideoPlayer.SeekPercentage", "params": {"value": "50"}, "id": "1"}
Fiasco Wrote:The database is either in a sqlite db file or in mysql. The client has access to it.
I used perl via http GET like so
xbmc.pl?genre=horror&type=moviesbygenre
xbmc.pl?type=moviesbydate
And format the output in a way that is readily split on a delimeter and parsed w/ a regex by the controller. Having the response formatted how I need it outweighs any effort required to tweak my select statements should XBMC change the DB table structures around.
Not sure how that exposes the database to mre risk than a json call.
I'm strictly pulling metadata.
This may be all good and well if YOU run a custom script for YOURSELF on YOUR system when it's only YOUR database that is lost when you do something wrong. But as soon as someone wants to write a third-party software which shall be distributed for others to use the risk and possible damage is a lot higher. Furthermore installation instructions like "Install Apache on your computer" etc tend to get people with less computer experience lost and won't allow them to use the software. That's why there's a json rpc api which can be used in combination with already existing json (rpc) parsers. I agree there is a lot of missing functionality but if noone says the out loud topfs2 will have to get his crystal ball from the cellar and try to read everyone's mind
Fiasco Wrote:The database is either in a sqlite db file or in mysql. The client has access to it.
If you give the outside world access to your mysql it is your setup not XBMC which gives access to it. The same if you give remote access to the sqldb file, its a big difference between YOU giving remote programs all access to the database and XBMC ALWAYS giving all access to the database. JSONRPC gives access based on what the client requests and on a per client basis, so a nfo editor may change the data but your phone may only read.
Also you should not assume it will either be sqlite or mysql, there have been talks about switching to other databases before and is something which is a likely scenario. Besides, forcing a client to write both for sqlite and mysql has been shown problematic (the differences are small but they are there). If you force a client to also write to couchdb or whatever because we switch to it for eden, it just becomes unmanageable. Why should the client _need_ to care for it, makes no sense.
You may use it for now but it is clear that giving full access to the database is not future proof, there is no room for arguing on that point. It is deprecated and will at some point be removed. If you wish to give full access to your mysql or sqlitedb file, this is your choice.
Cheers,
Tobias
Perhaps in some future upgrade iViewer will support JSON and what I have to do currently will be unnecessary. Having the return feedback in a format that is readily parsible by iViewer as it is now trumps all other considerations.
topfs2 Wrote:If you give the outside world access to your mysql it is your setup not XBMC which gives access to it. The same if you give remote access to the sqldb file, its a big difference between YOU giving remote programs all access to the database and XBMC ALWAYS giving all access to the database. JSONRPC gives access based on what the client requests and on a per client basis, so a nfo editor may change the data but your phone may only read.
Also you should not assume it will either be sqlite or mysql, there have been talks about switching to other databases before and is something which is a likely scenario. Besides, forcing a client to write both for sqlite and mysql has been shown problematic (the differences are small but they are there). If you force a client to also write to couchdb or whatever because we switch to it for eden, it just becomes unmanageable. Why should the client _need_ to care for it, makes no sense.
You may use it for now but it is clear that giving full access to the database is not future proof, there is no room for arguing on that point. It is deprecated and will at some point be removed. If you wish to give full access to your mysql or sqlitedb file, this is your choice.
Cheers,
Tobias
Montellese Wrote:You haven't tried all the possibilities Currently you'll have to use
Code:
{"jsonrpc": "2.0", "method": "VideoPlayer.SeekPercentage", "params": 50, "id": "1"}
Code:
{"jsonrpc": "2.0", "method": "VideoPlayer.SeekPercentage", "params": [50], "id": "1"}
Code:
{"jsonrpc": "2.0", "method": "VideoPlayer.SeekPercentage", "params": {"value": "50"}, "id": "1"}
Do you plan to leave the old syntax available for backwards compatibility?
wuench Wrote:Do you plan to leave the old syntax available for backwards compatibility?
I don't think so because it would leave us with an implementation of the json rpc 2.0 specification which does not conform to that very specification. Following the specification a json rpc request containing a "params" value which is neither an array of values nor an object containing sub-elements as name/value pairs is an invalid request. It is very unfortunate that this has not been considered at the very beginning and it will cause all current third party applications to break BUT it will finally allow third party developers to use already existing json rpc libraries (which currently isn't possible).
But of course we will let everyone know about the changes so that third party developers will have time to release new versions of their software.
Is there a way to get the allseasons info from JSON ?
I don't find a way to get it nor to get the infolabel for all seasons in users language to calculate the correct crc in all language
What exactly do you mean by "allseasons info"? The path to the "season-all.tbn" or what else?
The label
to calc the crc it's seasonsmbpath* All Seasons
but in french it's seasonsmbpath* Toutes les saisons
So i can"t calculate the correct crc without the text in user language
Montellese Wrote:I don't think so because it would leave us with an implementation of the json rpc 2.0 specification which does not conform to that very specification. Following the specification a json rpc request containing a "params" value which is neither an array of values nor an object containing sub-elements as name/value pairs is an invalid request. It is very unfortunate that this has not been considered at the very beginning and it will cause all current third party applications to break BUT it will finally allow third party developers to use already existing json rpc libraries (which currently isn't possible).
But of course we will let everyone know about the changes so that third party developers will have time to release new versions of their software.
If you break third parties there is a real impact, it will take time to update those interfaces and there is now way to support both old and new XBMC versions since there is no common interface that will work. Not all users are on the same version. We need to somehow come up with a way to support both.
I can think of a couple of ways to resolve this. 1.) Release the new changes first and have a period of time where both are supported, then remove the old. 2.) Increment the version on your interface or come up with some other indicator, so that we can determine which version a user is using so we do not break our users.
I know you guys don't get paid (I don't get paid either), and a scheme for backwards compatibility is not the simplest solution. But some third parties are commercial products and need to play by different rules. I would think coming up with some sort of solution would help to spread the use of the JSON interface and XBMC faster.
Montellese Wrote:I don't think so because it would leave us with an implementation of the json rpc 2.0 specification which does not conform to that very specification. Following the specification a json rpc request containing a "params" value which is neither an array of values nor an object containing sub-elements as name/value pairs is an invalid request. It is very unfortunate that this has not been considered at the very beginning and it will cause all current third party applications to break BUT it will finally allow third party developers to use already existing json rpc libraries (which currently isn't possible).
But of course we will let everyone know about the changes so that third party developers will have time to release new versions of their software.
If you break third parties there is a real impact, it will take time to update those interfaces and there is no way to support both old and new XBMC versions since there is no common interface that will work. Not all users are on the same version.
I can think of a couple of ways to resolve this. 1.) Release the new changes first and have a period of time where both are supported, then remove the old. 2.) Increment the version on your interface or come up with some other indicator, so that we can determine which version a user is using so we do not break our users.
I know you guys don't get paid (I don't get paid either), and a scheme for backwards compatibility is not the simplest solution. But some third parties are commercial products and need to play by different rules. I would think coming up with some sort of solution would help to spread the use of the JSON interface and XBMC faster. If you can come up with something it would be much appreciated.
wuench Wrote:If you break third parties there is a real impact, it will take time to update those interfaces and there is now way to support both old and new XBMC versions since there is no common interface that will work. Not all users are on the same version. We need to somehow come up with a way to support both.
I can think of a couple of ways to resolve this. 1.) Release the new changes first and have a period of time where both are supported, then remove the old. 2.) Increment the version on your interface or come up with some other indicator, so that we can determine which version a user is using so we do not break our users.
I know you guys don't get paid (I don't get paid either), and a scheme for backwards compatibility is not the simplest solution. But some third parties are commercial products and need to play by different rules. I would think coming up with some sort of solution would help to spread the use of the JSON interface and XBMC faster.
Sorry but no, we won't be having backwards compability at this point. JSONRPC is still very young and is not considered feature complete. The version in dharma should be considered a pre-release version and when we feel that the overall organization is good we might not change the API to much. So when we feel that the API is good, we might have some form of backwards compability but at this point we have decided not to as the API will still change quite a bit (and as said previously supporting something which is not even jsonrpc 2.0 spec is not a good idea).
Hopefully version 4 will be more ready.
Also, we have the JSONRPC.Version method for something, client gets the version and if its a version it does not support it should warn or error
topfs2 Wrote:Also, we have the JSONRPC.Version method for something, client gets the version and if its a version it does not support it should warn or error
That will work, if you plan to update the JSONRPC.Version when you make this change it would be very helpful. Otherwise I guess we could check the XBMC build number InfoLabel if you can give out that info when it is time.
But please keep us updated when you plan to make breaking changes.....
On a different topic, is there any way to determine if an external player is active? I can get the current window info label and the result is OK Dialog, but I am not sure that is sufficient.
wuench Wrote:That will work, if you plan to update the JSONRPC.Version when you make this change it would be very helpful. Otherwise I guess we could check the XBMC build number InfoLabel if you can give out that info when it is time.
But please keep us updated when you plan to make breaking changes.....
On a different topic, is there any way to determine if an external player is active? I can get the current window info label and the result is OK Dialog, but I am not sure that is sufficient.
we have already bumped version number multiple times, odd number refer to in development and even refers to "stable", however as said we don't refer it to really stable yet
And why do you need to know if its external or not? I thought about adding it but I couldn't find any reason for it.