[N3MIS15]

Well technically it's certainly possible but there are two issues:

1. I don't like it because it may leave users with invalid or outdated information on the screen.
   
2. Adding such a parameter to the SetFooDetails method definitions in the JSON schema is no problem in general but it will mess up the parameter ordering if we ever have to add an additional parameter to these methods. This is no problem for anyone using "by-name" parameters but will be for anyone using "by-position" parameters. Moving it right after the "fooid" parameter would break backwards compatibility.
   

1. Should not be of XBMC's concern. If there are any user issues they should be with the third party author (unless XBMC uses this internally of course)
2. How would it break backwards compatibility if its optional? Does it need to return data? (Have I misunderstood this?)

[Montellese]

1. The problem is that users which run into this issue will come to us for support and not the the third party author (maybe they don't even know that it's a third party addon that does the changes in the background). Furthermore IMO it should be of XBMC's concern. We also update the info on the screen after refreshing an item in the video library using a scraper. We don't leave it up to the scraper to update the GUI.
   
2. It only breaks backwards compatibility if we want to do it the nice and clean way and not kind of mess up the order of the parameters.
   

[Tolriq]

Then why not use what is already at our disposal

The better way to have all satisfied is simply to add a new refreshGUI in JSONRPC.SetConfiguration, extend IClient to get this boolean and act correspondingly.
(This does not change some other optimizations needs)

Since batch command are handled in the correct order this correct the problem and is easy to do.

And yes a badly coded plugin can still forget to toggle on at the end, but a badly one can also delete all database content nothing can be do against those

[topfs2]

1. The problem is that users which run into this issue will come to us for support and not the the third party author (maybe they don't even know that it's a third party addon that does the changes in the background). Furthermore IMO it should be of XBMC's concern. We also update the info on the screen after refreshing an item in the video library using a scraper. We don't leave it up to the scraper to update the GUI.
   
2. It only breaks backwards compatibility if we want to do it the nice and clean way and not kind of mess up the order of the parameters.
   

TBH It feels like something xbmc should be able to handle without client trying to control it.

e.g. If update requests happen faster than X then wait until it settles down (or a maximum of Y). That would most likely work just fine and wouldn't change the API at all Obviously a bit harder to implement (not sure where it would go? CDatabase or the implementation Video/MusicDatabase?)

[topfs2]

Since batch command are handled in the correct order this correct the problem and is easy to do.

Nope, batch commands aren't guaranteed to execute in the right order. Not even that the result is in correct order.

From JSON-RPC 2.0 spec

The Server MAY process a batch rpc call as a set of concurrent tasks, processing them in any order and with any width of parallelism.

The Response objects being returned from a batch call MAY be returned in any order within the Array. The Client SHOULD match contexts between the set of Request objects and the resulting set of Response objects based on the id member within each Object.

EDIT: The only thing it guarantees is that when returned it has executed (or atleast tried) them all

[Tolriq]

In current Xbmc implementation it is on execution order and I hope it will stay, since without that it's nearly impossible to use batch efficiently for most of the stuff that currently use it

Like no way to work on playlists for example.

[topfs2]

Its modeled after the JSON-RPC 2.0 spec. So don't make that assumption. If any other app decides to use our JSON-RPC api they might do it differently. For example I have started on a server which uses it and it might do them parallellised.

And even if it doesn't it makes no sense to assume it as we might rewrite the internals of xbmc where the execution is not order garantued.

If there are commands which needs order then those should probably be discussed and remade so they can be made in a single command.

[Montellese]

1. The problem is that users which run into this issue will come to us for support and not the the third party author (maybe they don't even know that it's a third party addon that does the changes in the background). Furthermore IMO it should be of XBMC's concern. We also update the info on the screen after refreshing an item in the video library using a scraper. We don't leave it up to the scraper to update the GUI.
   
2. It only breaks backwards compatibility if we want to do it the nice and clean way and not kind of mess up the order of the parameters.
   

TBH It feels like something xbmc should be able to handle without client trying to control it.

e.g. If update requests happen faster than X then wait until it settles down (or a maximum of Y). That would most likely work just fine and wouldn't change the API at all Obviously a bit harder to implement (not sure where it would go? CDatabase or the implementation Video/MusicDatabase?)

The problem with that is that you need some independent task/thread that does these checks and then actually executes the action Z milliseconds/seconds after no other such update request has been triggered.

[Tolriq]

A simple example still waiting for answers: http://forum.xbmc.org/showthread.php?tid=161770

Or for example :
Clear a playlist add items in order and start the playlist ?

There's lot's of cases where queuing commands in JSON is useful to avoid unnecessary requests

[topfs2]

1. The problem is that users which run into this issue will come to us for support and not the the third party author (maybe they don't even know that it's a third party addon that does the changes in the background). Furthermore IMO it should be of XBMC's concern. We also update the info on the screen after refreshing an item in the video library using a scraper. We don't leave it up to the scraper to update the GUI.
   
2. It only breaks backwards compatibility if we want to do it the nice and clean way and not kind of mess up the order of the parameters.
   

TBH It feels like something xbmc should be able to handle without client trying to control it.

e.g. If update requests happen faster than X then wait until it settles down (or a maximum of Y). That would most likely work just fine and wouldn't change the API at all Obviously a bit harder to implement (not sure where it would go? CDatabase or the implementation Video/MusicDatabase?)

The problem with that is that you need some independent task/thread that does these checks and then actually executes the action Z milliseconds/seconds after no other such update request has been triggered.

I planed on adding such a mechanic in the ServiceBase stuff. Obviously that would be quite a while from now until its useable

[Tolriq]

The fact that the discussion digress to JSON RPC 2.0 specification it does not change the value of the proposal that does solve the problem in an efficient way.

Acting like a database begin commit that is solving the exact same pattern.

About throttling allowing discard of queue items already there to limit unneeded refresh queuing if the system don't have enough power but still allowing realtime updating for more powerful sounds alos like a better approach for database modification driven refreshes. (Does not remove the need of a begin / commit pattern.)

[topfs2]

The fact that the discussion digress to JSON RPC 2.0 specification it does not change the value of the proposal that does solve the problem in an efficient way.

Acting like a database begin commit that is solving the exact same pattern.

About throttling allowing discard of queue items already there to limit unneeded refresh queuing if the system don't have enough power but still allowing realtime updating for more powerful sounds alos like a better approach for database modification driven refreshes. (Does not remove the need of a begin / commit pattern.)

Maybe JSON RPC 3.0 will do it differently. Or you could implement a new server but until then I cite http://xkcd.com/927/

Why stray from a standard when what you want is already perfectly doable, albeit requires a bit of waiting. Either this is done on client or server. In JSON RPC its done in client. IMO the benefit of following the standard out weight the disadvantage of maintaining our own.

[Tolriq]

My last post have nothing to do with JSON RPC specifications

I've heard your remark about the standard and I hope that we could find a solution if you decide later to break the current implementation but this is not the subject
I was talking about the enable /disable gui Refresh from a configuration flag client based, to act like database transaction (the initial proposal).
The fact that it can't be used in a batch but will need a query then the batch then a query is not a problem.

This is the same when you wan to add tons of items in a playlist and want to disable notifications during this time for now I can use batch but to respect 2.0 RPC this should be 3 requests.

About implementing things I have no problem about that but I find the discussion with the Team quite hard
Since all time is precious I work for Xbmc on a : Will this done like this accepted ? and then go.

But having feedback and Go / No Go on proposals is really hard (see http://forum.xbmc.org/showthread.php?tid=161770 for example and all other post stayed without answers).
I've asked for the TODO list for JSON to see if I can handle things but no answers too.
I've asked what I can do to help on JSON part but no answers too.

I've already had 9 PR accepted and my Xbmc skill are growing, I usually do what I decide to do the best I can, and seeing the return on my websites or apps I guess this is not so bad
And I have some time to give to Xbmc but previous points makes that quite hard

[topfs2]

I've heard your remark about the standard and I hope that we could find a solution if you decide later to break the current implementation but this is not the subject
I was talking about the enable /disable gui Refresh from a configuration flag client based, to act like database transaction (the initial proposal).
The fact that it can't be used in a batch but will need a query then the batch then a query is not a problem.

Ah, would be nice to not force this upon the clients as Montellese states. It opens up a bit of problem as it leaves xbmc in a semi state (unless the entire core is changed around this). e.g. if you send begin, and while sending the X requests through a batch, what should happen if the user goes out and back in (refreshing the window). Should he a) see only what is before begin, i.e. what databases do, or b) should he see it half refreshed.
b) has the in between state problems and a) effetively forces a complete rewrite of the databases afaik.

About implementing things I have no problem about that but I find the discussion with the Team quite hard
Since all time is precious I work for Xbmc on a : Will this done like this accepted ? and then go.

But having feedback and Go / No Go on proposals is really hard (see http://forum.xbmc.org/showthread.php?tid=161770 for example and all other post stayed without answers).
I've asked for the TODO list for JSON to see if I can handle things but no answers too.
I've asked what I can do to help on JSON part but no answers too.

I've already had 9 PR accepted and my Xbmc skill are growing, I usually do what I decide to do the best I can, and seeing the return on my websites or apps I guess this is not so bad
And I have some time to give to Xbmc but previous points makes that quite hard

Yeah this is a known problem and we are working on it. We are fully aware we need to alter the process for non-team devs, so they clearly knows what features is wanted and not, essentially so that the long term goals are known to the entire community. This is partly why we made the read-only forum.

I reread my last post and I sounded a bit harsh (English is my second langauge). I mostly wanted to state that there are 3 options (all with advantages and disadvantages) a) pick a spec and go with it b) write one our of our own or c) pick one and mod it. b and c here have the same problems but c is a bit less work. c) disadvantage against b) is that documentation gets loooots harder, and its somewhat confusing for new developers. a) advantage is that bindings comes for free and its generally easier to get answers outside our community (i.e. on stack overflow etc.). So I personally favour a) and out of the available ones I found json-rpc one of the simplest, while being very powerful.

[Tolriq]

No problem for English mine is way worse and I always sound a lot harsh :p

The main problem around multiple queries is quite specific to mobiles and low power device like rpi the overhead is quite big, so if one day Xbmc does change the current ordered handling this would have quite some impact, or force the move to direct tcp but way harder for most devs and poses problems for some basics real advanced remote devices.
So if a solution can be found before it's better.

Queuing commands in order is not a fancy need .

For the refresh part, yes commit type have it's flows but for me should act as if read uncommited is done since in the background database is not in transaction mode and will not rollback.
So having the GUI refreshing if the users ask with the current data handled is normal behavior and keep all it's sense
The flag is only for a JSON client view state so does not impact other clients or GUI just a way for a client to better control it's impact on Xbmc CPU.

Having the database throwing the refresh only if the GUI is binded to the modified data would need tons of rewrite and would not correct the too fast refresh problem.
And throttling refresh with arbitrary values when computer is powerful enough to handle is not good either.
Replacing already queued but not handled message in the ThreadMessageQueue should also do the trick a little better but don't know impact on the rest. (? Add a new param replace on duplicate ?)

And to finish on the communication problem I hope you find a solution I'd really like to contribute more to benefit all remote makers and leading to a better Xbmc ecosystem