httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From TOKI...@aol.com
Subject Re: Apache 2 mutiple pools feature request
Date Thu, 04 Mar 1999 03:51:31 GMT
In a message dated 99-03-04 03:02:38 EST, you write:

> Ummm, no it isn't.  Among the things not included in the CORBA design
>  are streaming data transfers, polymorphic access control, and preemptive
>  negotiation -- figuring out what you need to do and what is available to
>  be done before there is something needing to be done (i.e., outside the
>  critical path).  Some of these were being worked on in OMG a while back,
>  but CORBA is already so full of stuff that it is in danger of not being
>  usable by any application, let alone what it was originally designed to do.
>  
>  CORBA is a reasonably efficient, exceptionally generic RPC.  To see many of
>  the things that CORBA did wrong, look at the enhancements to ILU that were
>  needed to enable an HTTP-NG prototype.  And the best feature of ILU is
>  the flexible binding of IPC, not its speed as a generic RPC.  The only
>  thing that IIOP does is add a few bytes identifying the IIOP version and
>  specific orb/object of the destination, hardly the recipe for an efficient
>  application protocol, unless the application uses short control messages
>  over low latency connections with very little data flow.
>  
>  >So I think it will be tough for a custom protocol to beat corba - many 
> smart
>  >people spent lots of time designing it.
>  
>  You'd be surprised how easy it is.  HTTP/1.0 beats CORBA for any operation
>  involving serious data transfer (>2KB payload), because HTTP doesn't have
>  to discover the interface before using it, doesn't have to buffer data
>  into smaller interactions, doesn't need to wait until the parameters are
>  complete before the stub returns, and doesn't have to perform data
>  marshalling beyond the header fields.  Any working API that is designed
>  for simultaneous streaming data transfer of control data, representation
>  data, representation metadata, resource metadata, and meta-metadata will
>  outperform one that requires multiple interactions to achieve the same
>  results, and that is before the performance tuning.  The cost of setting
>  up and performing an IPC interaction far exceeds anything you can get out
>  of tuning a working interface, unless the tuning includes avoidance of the
>  interaction itself (e.g., caching).
>  
>  This doesn't mean CORBA is a bad thing -- it just means it wasn't designed
>  for distributed hypermedia.  There are hundreds of other applications for
>  which CORBA-like protocols are better than large-grain data transfer 
> protocols.
>  
>  ....Roy

Roy... I am no fan of CORBA myself nor do I often find any situation
where OOP amounts to either swatting a fly with a Buick or going to
New York via China... but perhaps you should familiarize yourself with
some of the work going on at IBM and other places to solve 2 of the
long standing fatal flaws surrounding all Object Oriented programming
designs with regards to their application to communciations environments.
1. The inability to guarantee that all elements and data collections of an
object will occupy a contiguous area of memory in order to reduce the
complexity of transaction preloading for streaming transmit.
2. The inability to dissect relative class elements and reduce the object
components to their critical weight. ( In other words... drop the bloat! ).

Once these 2 fatal OOP design flaws are managed then this Object Oriented
stuff might finally begin to make an appearance in the world of serialzed
data communications.

I still think it will be like swatting a fly with a Buick... but you gotta
love
these college kids for trying to force OOP into places where it was never
meant to go.




Mime
View raw message