Asunto: Re: [CORBA-Comp] Re: reflective middleware
Fecha: Tue Mar 14 14:01:44 2000
De: Diego Sevilla Ruiz <dsevilla@ditec.um.es>
Miguel de Icaza wrote:
> > > 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).
>
> Aquí hay algo interesante que mencionar: la gente que especifica
> CORBA, le fascina especificar interfaces y nunca proveer detalles
> sobre la implementación.
>
> En la práctica, tienes que crear tu propio sistema de activación,
> tienes que crear tu propio sistema de localización y mucho más.
>
He visto los esfuerzos que habeis hecho en GNOME con el GOAD y el interfaz
Bonobo::GenericFactory, etc. Sin embargo, parece que la solución habría sido dotar a ORBit
de un Implementation Repository que asociara interfaces con servidores/shared
libs/loquesea que lance un servidor del tipo especificado. Ya que estamos, una pregunta:
¿por qué Bonobo::GenericFactory::create_object acepta unos parámetros como una secuencia
de strings? ¿No sería más razonable que aceptara una secuencia de "any" para poder enviar
a la creación de un objeto cualquier tipo de datos CORBA?
>
> Por lo menos DCOM tiene un sitio de donde partir y puedes escribir
> encima de esto.
>
Si, pero resulta ridículo tener que confirugar UNO A UNO cada componente, localización
remota, etc.
>
> Este problema lo tuvimos en GNOME. CORBA en papel suena maravilloso,
> pero cuando tratas de usarlo, resulta que no hay de donde empezar: asi
> que tuvimos que rellenar a diestra y siniestra todos los hoyos para
> poder tener un sistema de componentes en Unix.
>
> > > 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?
>
> A mi en particular me parece que C++ es un lenguaje malo (por mil
> razones que no vienen al caso). No dudo que las azúcar sintáctica
> de C++ de Microsoft sea pésima (como lo es su API nativo).
>
Sin embargo, debes reconocer que el mapping de IDL a C++ facilita la programación de
aplicaciones. En C es muy fácil perder algún CORBA_free, por ejemplo, mientras que en C++,
con las clases "_var" se ayuda mucho al programador previniendo este tipo de fallos.
>
> Pero mi versión de COM/OLE2 está hecha con buen gusto y facilita la
> programación de componentes masivamente.
>
> Saluditos,
> Miguel.
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/
--------------------------------------------------------------------------