Java clients: Why is the key/qos on xmlBlaster method invocations a String instead of some “QosWrapper” object?
To avoid to “force” clients to use these wrappers if they don’t want it. In any case, if you have the PublishQos.java object (lets call an instance of it qosWrapper), then you can pass qosWrapper.toXml() to the method publish(String qos, String qos). All method invocations of xmlBlaster have simple strings as arguments. The strings are usually xml encoded. This allows future changes and enhancements without braking the client/server contract. (An older client may still talk to a newer server without need to recompile). If we would pass objects (or structs) as arguments, the CORBA IDL would change with every small modification, for example adding a new QoS ‘ForceUpdate’ would change the object and could lead that an older client somewhere suddenly couldn’t talk to the updated xmlBlaster server anymore. Having the arguments as xml encoded strings, allows simple access, if you use Perl, Python, C++ or whatever. The Java class PublishQos is just a simple helper class for Java clients, it i