RE: [oil-devel] Parâmetros do 'newservant'

[Leonardo S. A. Maciel]

> -----Original Message-----
> From: oil-devel-bounces at lists.luaforge.net [mailto:oil-devel-
> bounces at lists.luaforge.net] On Behalf Of Renato Maia
> Sent: quinta-feira, 17 de abril de 2008 09:16
> To: OiL Devel
> Subject: [oil-devel] Parâmetros do 'newservant'
> 
> Olá pessoal.
> 
> Estou com problema na API do OiL. A operação 'newservant' é
> implementada internamente pela operação 'object' da faceta
> 'ServerBroker.broker'. Mas esse componente tem duas implementações no
> OiL: uma sem suporte a interfaces, cuja assinatura é:
> 
>    <servant> = object(<implementation> [, <key>])
> 
> E outra, com suporte a interfaces, que estende essa operação de forma
> que ela receba um novo parâmetro indicando a interface do servant
> sendo criado:
> 
>    <servant> = object(<implementation>, <key>, <interface>)
> 
> Eu gostaria de imitar esses mesmos parâmetros na operação
> 'newservant' da API do OiL. Mas o problema é que na versão com
> suporte a interfaces, o parâmetro 'key' é opcional e o parâmetro
> interface é obrigatório. Estou considerando seguintes opções (em
> ordem de preferência):
> 
> a) Deixar o parâmeto opcional no meio, obrigando as aplicações que
> usem CORBA ou outro protocolo com interfaces (e.g. SOAP, ICE,
> JavaRMI) fazerem 'newservant(impl, nil, interface)' quando não
> quiserem especificar um 'object key'.
> 
> LuDO:
>    orb:newservant(MyObject)
> 
> CORBA:
>    orb:newservant(MyObject, nil, "MyInterface")


Não gosto, pois se a maior parte das aplicações usa protocolos tipados, esta
não é a abordagem mais natural.


> b) Definir que a estensão que implementa a operação 'object' da
> faceta 'ServerBroker.broker' adiciona um parâmetro novo no meio, ao
> invés do final como seria mais natural. Isso implicaria que, em ORBs
> com suporte a tipos como CORBA, o segundo parâmetro seria a interface
> e nos ORBs sem suporte a interfaces, o segundo parâmetro seria a
> chave do objeto. Acredito que isso pode causar algumas confusões:
> 
> LuDO:
>    orb:newservant(MyObject, "MyObject") -- MyObject é a chave do
> servant
> 
> CORBA:
>    orb:newservant(MyObject, "MyObject") -- MyObject é a interface do
> servant


Pode gerar confusão mesmo, mas somente para aqueles que irão usar os dois
protocolos. Provavelmente não serão muitos, serão?


> c) Fixar a assinatura desse método da API com os parâemtros
> <implementação>, <interface> e <chave>, mesmo que para protocolos sem
> suporte a interfaces o segundo parâmetro seja totalmente desnecessário.
> 
> LuDO:
>    orb:newservant(MyObject, nil, "MyObjKey')
> 
> CORBA:
>    orb:newservant(MyObject, "MyInterface", "MyObjKey")
> 
> Nessa abordagem poderíamos até imitar essa interface na faceta
> 'ServerBroker.broker' também, onde a implementação ficaria:
> 
> No Type Support:
>    function ServerBroker.broker:object(impl, _, key) -- second
> parameter is reserved for future use (e.g. type specification).
>      ...
>    end
> 
> With Type Support:
>    function ServerBroker.broker:object(impl, type, key)
>      ...
>    end

Prefiro esta a primeira, pelo mesmo motivo que não gosto da primeira.


> O que vocês escolhem: (a), (b) ou (c) ?

Minha ordem é b, c, a