|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: Phil Reynolds (preynolds_at_RIDGEWAYSYSTEMS.COM)
Date: Tue Jul 09 2002 - 04:16:20 CDT
Much as I don't want to argue with such an august list of folks... why not I
have never worried about it before :-)
Connection points do provide a STANDARD way of setting up bi-directional
communication. Thus they are good, as any client language should be able to
deal with them.
It is not beyond the whit of any moderately competent programmer to extend
(or provide a different mechanism) to allow a faster setup for those
languages that can be tailored to handle it whilst still maintaining
compatibility with the standard.
> -----Original Message-----
> From: Peter SQ [mailto:shirlep1
MISYS.COM]
> Sent: 09 July 2002 10:00
> To: DCOM
DISCUSS.MICROSOFT.COM
> Subject: Re: [DCOM] DispEventAdvise across machines
>
>
> One commonly cited reason why connection points may not be
> ideal is given
> in the following extract from the excellent article,
> Effective COM Programming: Seven Tips for Building Better COM-based
> Applications, Don Box, Keith Brown, Timothy J. Ewald, Chris Sells
> Periodicals 1998 in MSDN Library
>
> A common misconception among COM programmers is that connection points
> enable bidirectional communication between clients and
> objects. They don't.
> What connection points provide is a standard mechanism for
> establishing
> bidirectional communication. Bidirectional communication is
> enabled when
> the client has an interface pointer to the object and vice
> versa. While you
> can use connection points to establish this bidirectional
> communication
> channel, you shouldn't for one important reason: round-trips.
> It takes five
> logical round-trips to establish bidirectional communication using
> connection points and four round-trips to tear it down; it
> really should
> only take one.
>
> ----
>
> My own view is that this cost is sometimes acceptable.
> However with DCOM I
> have run into a number of security issues related to the
> business of making
> a COM call back to the client when that client has not been configured
> using DCOMCNFG. A tricky business, particularly when using VB.
>
> ----------------------------------------------------------------
> Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
> contains important info. Save time, search the archives at
> http://discuss.microsoft.com/archives/index.html .
> To unsubscribe, mailto:DCOM-signoff-request
DISCUSS.MICROSOFT.COM
>
----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-request
DISCUSS.MICROSOFT.COM
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]