While starting to develop Remoting 3 services in earnest, it occurs to me that the term "group name" is a bit confusing. It identifies a unique instance of a service within an endpoint more than anything. So I'd like to put the idea of changing this method name on the table, before we lock in to a final release in AS.
The reason "group name" was chosen was that it was intended that same-named instances of services located on different endpoints could act as a "group" of which the service is a member. However in most actual use cases I think this is going to be a secondary application; generally the name will be used to distinguish between more than one instance of the same service type on a single endpoint.
The change is mainly a documentation-only change, however a few public members are affected. The get/setGroupName methods in the service builder and service listener APIs would be renamed, and the ServiceURI.getGroupName() and validateGroupName() methods would be renamed. Finally, the remoting-3.1 XML schema would have the group-name attributes renamed.
Unless anyone has any screaming objections to this, I'll plan on it for Beta3.
No objections.
So, service type and group (instance) name are analogous to interface and implementation, I guess, so the name could be derived from that analogy, as well. But "instanceName" seems OK, too.
-Ron