Calvin Wan <calvinwan@xxxxxxxxxx> writes: > Currently on the server side of object-info, if the client does not send > any object ids in the request or if the client requests an attribute the > server does not support, the server will either not send any packets > back or error out. Consider the scenario where the client git version is > ahead of the server git version, and the client can request additional > object-info besides 'size'. There needs to be a way to tell whether the > server can honor all of the client attribute requests before the client > sends a request with all of the object ids. This part explains the problem... > In a future patch, if the > client were to make an initial command request with only attributes, the > server would be able to confirm which attributes it could return. ...and this part explains what we want to do in the future, but this commit message doesn't explain what this commit does. (The commit subject has something related, but does not have enough detail. For example, is it an empty attribute packet?) Having said that, the way we usually communicate client-server version differences is through capabilities - is there a reason why we can't use that here?
