Asunto: Re: [CORBA-Comp] Re: reflective middleware
Fecha: Fri Mar 10 13:57:16 2000
De: Diego Sevilla Ruiz <dsevilla@ditec.um.es>
Miguel de Icaza wrote:
> Creo que el contexto es "Como implementar un sistema de componentes
> para Unix" y "vamos a basarlo en OpenDoc, por que como lo hizo alguien
> que no es Microsoft debe ser bueno":
Bueno, lo primero si. Lo segundo no.
>
>
> > OLE2 tiene de malo: lo primero COM, lo segundo DCOM (y la configuración
> > demoníaca) y lo tercero y más importante es que es sólo Windows. Además,
> > programar OLE/COM es compilcado realmente, a no ser que utilices VisualBasic (que
> > no es plan). El IDL de DCOM es indescifrable (al menos para mi): cosas como los
> > dispinterfaces, "pointer unique", etc. Además, hacer componentes COM/OLE con
> > Visual C++ es complejo, ¿no?
>
> Bonobo está basado en las interfaces de OLE2. Nota: Las Interfaces.
> No la implementación.
>
> 1. No dices que tiene COM de malo. Debemos de asumir que "sabes" algo
> que nosotros no sabemos o que tienes muchísimas experiencia en algo
> que es intangible.
>
Ni mucho menos. Todos los sabeis. COM, como todo tiene cosas buenas y cosas malas. Las
malas: Se piden referencias a "interfaces", y no a objetos (es decir, hay IIDs y no OIDs),
con lo que hay que utilizar "Monikers" (corrígeme si me equivoco). En CORBA, sin embargo,
las referencias son a objetos (lo cual es más lógico). Esto tiene la desventaja de que si
se pierde la conexión con un "objeto" (por ejemplo, si utilizamos DCOM) no tenemos la
posibilidad de volver a conectarnos al mismo objeto (¿se tendrían que utilizar monikers?).
Por otro lado, tiene mucho de bueno, como es la conexión en una misma entidad (componente)
de varios interfaces en principio no relacionados. Esto da mucha flexibilidad.
>
> 2. "lo segundo DCOM". Buena retórica, pero poco contenido real.
>
A lo que me refiero es que (por ejemplo) hay que especificar a mano el host que ejecutará
la DLL remota que da servicio a cada interfaz con el DCOMCFG (esto no es escalable). No
hay registro distribuido, por ejemplo para que las aplicaciones puedan encontrar y usar
sus componentes de forma transparene de forma remota (esto es, que no se necesite
DCOMCFG). Además está el problema del IDL/ODL de DCOM (¿cuál usar?).
>
> 3. OLE/COM no es complicado. La infraestructura básica es muy
> sencilla, y una vez que entiendes eso, ya la hiciste.
>
Tienes razón. La estudiaré más a fondo. Sin embargo, su programación sigue siendo
complicada, al menos con VC++ ¿no?
>
> 4. Efectivamente el IDL extendido de COM es muy feo. I los
> dispinterfaces son un error que CORBA corrige.
>
En esto estoy de acuerdo.
>
> Miguel.
Gracias por tus comentarios.
Saludos.
diego.
--
Diego Sevilla Ruiz -- http://www.ditec.um.es/~dsevilla/
Departamento de Ingeniería y Tecnología de Computadores
Facultad de Informática. Universidad de Murcia
Campus de Espinardo - 30080 Murcia (SPAIN)
Tel.: +34-968-367570
E-mail: dsevilla@ditec.um.es
$_="\\l/) (>". "_'\n<";@@= /.|\n/g;$_=
"\@". "\007f". "DDq". "DD5". "\204".
"\@". "DT4CE". "D54E". "DD". "\244".
"\021". "dBDTC". "\010DD". "\200\$FD\024".
"GDAG". "DAGDT". "CqI";$c =0;$p =5;for$q
(/./g) {$q= ord$q; for(a, b){$z[$c]
=$@[$p+=($q&15) -4];$q>>=4;$c+=33 ;$c>98 &&($c-=98);}};print@z;
--------------------------------------------------------------------------
Esta es la lista de discusión de CORBA y Componentes Software (corba-comp)
--------------------------------------------------------------------------
Suscripcion: Envie un correo a mailto:Majordomo@ditec.um.es?body=subscribe%20corba-comp
Eliminar su suscripcion: mailto:Majordomo@ditec.um.es?body=unsubscribe%20corba-comp
Informacion de la lista: mailto:Majordomo@ditec.um.es?body=info%20corba-comp
Problemas: mailto:corba-comp-owner@ditec.um.es
Indices de la lista: http://www.ditec.um.es/~dsevilla/corba/
--------------------------------------------------------------------------