[Montellese]

Thursday, September 1th 2011: I'm back after a long holiday trip
Commits: ae691d390c87365087ff, 491764e6aa4f8a96ab7b

• Added optional parameter "albumartistsonly" to AudioLibrary.GetArtists. If the parameter is not passed or is passed with a value of null the result will consider the GUI setting "Include artists who appear only on compilations" (Settings -> Music -> Library). Providing the parameter with a boolean value (true/false) overrides the GUI setting. If the GUI setting is unchecked or the parameter is passed with a value of false, the returned list will contain an artist named "Various artists". That artist has an "artistid" which cannot be used in AudioLibrary.GetArtistDetails but it can be used in AudioLibrary.GetAlbums and AudioLibrary.GetSongs.
  
• Changed the return value of the "set" field, which can be requested for movies. Up until now the return value was a comma-seperated string of set names. It has now been changed into an array of set names which should make parsing the sets a lot easier for clients.
  
• The following optional fields have been added to some media objects:
  • "setid" to movies
    
  • "tvshowid" to episodes
    
  • "artistid" to albums
    
  • "artistid" and "albumid" to songs
    
  This will make it easier to access "parent objects" of a retrieved media objects.
  

Monday, September 5th 2011: Major cleanup
Commits: 8 commits from 2a33c5f4696d2c079625 to 2968c9b8faf821f70e97
Ok these 8 commits contain all kinds of cleanup in the jsonrpc API to make it more future-proof. From now on everything that resides in the XBMC namespace is either very XBMC-specific or is something that is more of a hack than anything else (like GetInfoLabels and GetInfoBooleans)

• JSONRPC.GetNotificationFlags and JSONRPC.SetNotificationFlags have been refactored and renamed to JSONRPC.GetConfiguration and JSONRPC.SetConfiguration
  
• XBMC.Log has been removed
  
• GetProperties has been added to the System namespace. It currently provides the values of the properties "canshutdown", "cansuspend", "canhibernate" and "canreboot".
  
• SetVolume, ToggleMute and Quit have been moved from the XBMC to the new Application namespace
  
• XBMC.GetVolume has been replaced by Application.GetProperties which currently provides the values of the properties "volume" and "muted".
  
• GetInfoLabels and GetInfoBooleans have been moved from the System to the XBMC namespace and are considered deprecated. Please let us know which data you retrieve most using these methods so that we can provide better access to those values.
  
• The field album_label for albums has been renamed to albumlabel to match the naming convention
  
• The field streamDetails for videos has been renamed to streamdetails to match the naming convention
  

Tuesday, September 13th 2011:
Commits: 6 commits from 0f12ea73fcef4b65ac89 to c93ea68b5428a9109140
Although there is no change in the functionality and the feature set of the jsonrpc API I finally found the time to further improve xbmc's implementation of JSON schema by covering more parts of the JSON schema specification. The newly added functionality include

• minLength and maxLength properties for JSON schema definitions of type "string" (no further explanation needed as they are pretty self-explaining)
  
• additionalProperties property for JSON schema definitions of type "object". This property can either have the value "false", which means that it is not allowed to provide additional properties (i.e. properties that are not explicitly defined in the types JSON schema definition) as part of the defined JSON object, or it can be a JSON schema definition which must be valid for any property that has not been explicitly defined.
  
• extends property for JSON schema definitions of any type. This new functionality is a bit more complicated than the others already present in xbmc's JSON schema implementation. It is similar to inheritance in object-oriented programming languages as it allows one type to extend the JSON schema definition of one or multiple already existing types. The specialty about "extends" is that an actual JSON object must validate both against the extended JSON schema definition(s) and against the extending JSON schema definition. That an extended type should never use "additionalProperties": false because otherwise the extending type cannot provide additional parameters.
  As a simple example let's look at the optimized JSON schema definition of "Player.State" and "Player.State.Extended":
  
  Code:

  "Player.State": {
    "type": "object",
    "properties": {
      "playing": { "type": "boolean", "required": true, "description": "" },
      "paused": { "type": "boolean", "required": true, "description": "" }
    }
  },
  "Player.State.Extended": {
    "extends": "Player.State",
    "properties": {
      "partymode": { "type": "boolean", "required": true, "description": "" }
    }
  }
  As you can see using the "extends": "Player.State" feature the "Player.State.Extended" definition inherits the "playing" and "paused" properties of "Player.State" and therefore won't have to define them itself (which up until now was necessary so that resulted in quite a bit of duplicate code).
  
• union type definitions: Up until now the "type" property of a JSON schema definition could either be a string defining a single type (boolean, integer, number, string, array, object, null) or an array of single types (e.g. [ "integer", "string" ] which means that the type is either an integer or a string). Additionally to that functionality it is now possible to use whole JSON schema definitions as part of the "type" property. To explain this let's look at the definition of "Playlist.Id":
  
  Code:

  "Playlist.Id": {
    "type": [
      { "type": "object", "properties": { "id": { "type": "string", "minLength": 1, "description": "Identification of a virtual playlist", "required": true } }, "additionalProperties": false },
      { "type": "object", "properties": { "file": { "type": "string", "minLength": 5, "description": "File from which to load a playlist", "required": true } }, "additionalProperties": false }
    ]
  }
  As you can see the definition only consists of the "type" property which is an array of two differing JSON schema definitions. That means that any JSON object which must be a "Playlist.Id" type can now either have a property "id" or a property "file" but a JSON object having both an "id" AND a "file" property is not a valid "Playlist.Id" object. Up until now this kind of definition was not possible and it was possible to provide both an "id" and a "file" property although it doesn't make any sense to provide both. This feature is also used in "Playlist.Item.Video" where (up until now) it was possible to provide an object containing not only a "movieid" property but also a "musicvideoid" property although "VideoPlaylist.Add" (which takes a parameter of type "Playlist.Item.Video") only allows to add a single video to the playlist.
  

For all those who find my explanations confusing (including myself) you can also take a look at the official JSON schema specification to read up on what those properties really do.

Thursday, September 15th 2011:
Commits: 44b94fac978ef101d442

• Renamed "shares" to "sources" in the return value of Files.GetSources