RE: Protect XMLPlatformUtils::Initialize and XMLPlatformUtils::Te rminate

[Ma...@VerizonWireless.com]

In principle, I agree that a well-designed consumer of Xerces-C would have
some methods of its own which call the initialization methods of Xerces-C.
That just seems like the right thing to do. But, my one question is, what do
you do about this?:

          Application
               |
      -------------------
      |                 |
   Library 1        Library 2
      |                 |
      -------------------
               |
           Xerces-C

In essence, what do you do when 1 & 2 expose initialization methods, both of
which are initializing the same copy of Xerces upon which both tools have
independent dependencies? Would it be possible to encapsulate the Xerces-C
global state information in such a way that Library 1 and Library 2 each
possess their own separate copy?

Thanks for considering this point,
Matt

-----Original Message-----
From: david_n_bertoni@us.ibm.com [mailto:david_n_bertoni@us.ibm.com]
Sent: Thursday, May 19, 2005 2:15 PM
To: c-dev@xerces.apache.org
Subject: RE: Protect XMLPlatformUtils::Initialize and
XMLPlatformUtils::Terminate


> You're right that for simple applications, this would be entirely
> acceptable. But what happens when the app you're talking about uses
> several components in-proc that use Xerces for entirely different
> and separate reasons. Those components do not have any knowledge
> of the other components and what they use Xerces for (and they
> _shouldn't_ have to know. It's internal to the logic of the component.).
> This isn't a hypothetical example. It's a situation that occurs in the
> software that I work on right now.

If you get the components from other parties, then you should ask them 
what their initialization strategy is.  If they are your own, you should 
enforce a consistent strategy.

> Okay, so your argument after reading this might be, well, you just
> need to ensure that your application calls initialize/terminate before
> loading the libs. But my argument to that would be: why should my
> application have to know ahead of time that libs lib1.dll and lib2.dll
> use Xerces? To me, that defeats the whole purpose of creating component
> software. You're not _supposed_ to know the details of how a library 
works,
> just the interface to it. 

Yes, but a well-designed library that use Xerces-C will understand its 
initialization/termination requirements and expose similar requirements to 
you as the user of that library.  You don't need to know that your library 
is using Xerces-C, you just need to know it's requirements.

Dave

---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
___________________________________________________________________
The information contained in this message and any attachment may be
proprietary, confidential, and privileged or subject to the work
product doctrine and thus protected from disclosure.  If the reader
of this message is not the intended recipient, or an employee or
agent responsible for delivering this message to the intended
recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited.
If you have received this communication in error, please notify me
immediately by replying to this message and deleting it and all
copies and backups thereof.  Thank you.


---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org