A small new feature

[ro...@us.ibm.com]

Some requested a little feature that seemed very reasonable and very low
risk so I added it. The transcoding and netaccess abstractions now include
a new virtual method called getId(). This method returns a const XMLCh
pointer that holds a string that indentifies which transcoder or network
accessor it actually is. This will allow client code to check these if they
require a particular implementation.

The factory objects for these two abstractions are public static members of
XMLPlatformUtils. So you can check them like this:

XMLPlatformUtils::fgNetAccessor.getId()
XMLPlatformUtils::fgTransService.getId()

I updated the Win32, Iconv, and ICU transcoders to support this new call. I
couldn't compile the Iconv one, so someone make sure it works ok. But the
change was trivial enough that I probably didn't flub it. There currently
is no blessed implementation of the network access API, so there was
nothing to do there but add the new virtual to the abstract base class.

Those of you who are taking on the work of doing your own implementations
of these abstractions, you'll need to add support for this simple query
method when you update to the latest code.

The ids of the ones I just did are:

L"Iconv"
L"Win32"
L"ICU"

which should be obvious enough I guess :-) Though of course I actually
defined in the portable way as an array of char constants, not as actual
L"" type strings. You can provide whatever id for your own implementations
that you want, but just don't conflict with any of the official ones. And
make it nice and unique so it won't accidentally conflict with anybody
else's.

I didn't add this type of support to the other major pluggable abstraction,
the message loading mechanism. Partly this was for technical reasons, since
it would have require more changes to the code, and partly because it has
no optional behavior and should be indistinguisable from the outside. The
other two, OTOH, might have slightly different characteristics because they
are based on relatively complex system services over which we have no
control.

----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
roddey@us.ibm.com