If we're going to do this, I guess we're going to do it properly. Nixed the

notion of a global group (though we implicitly define one in InvocationCodes)
added a mechanism for directors (which generally handle the client side of
invocation services) to register their interest in bootstrap service groups so
that the whole goddamned complex business can happen magically behind the
scenes.

If you instantiate a director, it will automatically register interest in the
service group it needs and everything will work. If you don't use the director
code, you don't get the services and you can safely exclude all of that code
from your client even though the services are still in use on the server (and
presumably used by some other types of clients).

This is going to break all the builds, which I'll soon fix. Then I'll go write
all this in ActionScript. Yay!


git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4552 542714f4-19e9-0310-aa3c-eee0fc999fb1

src/java/com/threerings/presents/data/InvocationCodes.java

@@ -29,6 +29,10 @@ package com.threerings.presents.data;
  */
 public interface InvocationCodes
 {
+    /** Defines a global invocation services group that can be used by clients and services that do
+     * not care to make a distinction between groups of invocation services. */
+    public static final String GLOBAL_GROUP = "presents";
+
     /** An error code returned to clients when a service cannot be performed because of some
      * internal server error that we couldn't explain in any meaningful way (things like null
      * pointer exceptions). */