With the choice to require wholeResource objects when updating, the Friendly Name becomes even more problematic than it already is. I propose that the Friendly Name be removed from the Resource altogether. It is information that can (and likely should) be managed by clients. If a client application wishes to display a human-readable name associated with a given resource, the application can store that name, along with the id and any other relevant information locally. This would not prevent an application from creating a data object that contains both friendly name and the core resource data, but the fundamental faststatus service should not include it.
This has a few particularly nice effects on the implementation.
The size of the binary representation of a Resource is now absolutely constant. The only variable-length field was the FriendlyName, so with that gone, the length of a message is now static.
Clients can now pass around only and exactly the relevant data.
jessecarl
commented
7 years ago
With the choice to require whole
Resourceobjects when updating, the Friendly Name becomes even more problematic than it already is. I propose that the Friendly Name be removed from the Resource altogether. It is information that can (and likely should) be managed by clients. If a client application wishes to display a human-readable name associated with a given resource, the application can store that name, along with the id and any other relevant information locally. This would not prevent an application from creating a data object that contains both friendly name and the core resource data, but the fundamental faststatus service should not include it.This has a few particularly nice effects on the implementation.
FriendlyName, so with that gone, the length of a message is now static.