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

[Renato Cerqueira]

hehe... essa discussão é bem interessante considerando que estamos  
falando de
uma linguagem que oferece um tipo de dado bem flexível para esse tipo
de problema (tabelas...) ;-)

abraços,
Renato

On Apr 18, 2008, at 9:49 AM, Renato Maia wrote:

> Olá pessoal.
>
> Obrigado por todas as respostas. Já que vocês foram unânimes sobre a  
> opção (b), vou tentar implementá-la. Mas vou restringi-la a API mais  
> externa do OiL, ou seja, não vou alterar API da faceta  
> 'ServantBroker.broker'.
>
> Não há nada de errado no que o Amadeu disse, pelo contrário.  
> Qualquer componente da arquitetura do OiL pode ser substituído, como  
> mudar a implementação do ServerBroker só para alterar a ordem dos  
> parâmetros. Entretanto, quanto mais genéricos conseguirmos modelar  
> os componentes, mais poderá ser reutilizado. Por exemplo, acredito  
> que como a arquitetura do OiL está hoje, é possível reutilizar todos  
> os componentes da arquitetura com suporte a definição de tipos em  
> todos os protocolos que precisem desse suporte. Não acho que ficaria  
> legal, fazer com que cada protocolo implementasse um 'ServerBroker'  
> ligeiramente diferente toda vez. O que eu quero dizer é que quanto  
> mais componentes conseguirmos deixar no 'oil.arch. 
> {base,cooperative,typed}', melhor, pois eles formam a base  
> reutilizável do framework e portanto menos trabalho para quem for  
> implementar suporte para um novo protocolo no OiL. O ideal é  
> analisar as necessidades mais comuns de diferentes protocolos e  
> fatorá-las em componentes genéricos que possam ser reutilizados.
>
> Sem dúvida a opção (a) é péssima para os usuários de protocolos que  
> exijam alguma informação na criação do servant, tal como a interface  
> dele. Isso eu já sabia e por isso não mandei para 'oil-users at ...',  
> pois lá todos seriam unânimes contra a opção (a) como foi com vocês.  
> O meu problema aqui, que eu não sei se consegui ser claro o  
> suficiente no último mail, é que a única informação que pode ser  
> dada na criação de um servant, independente de qualquer protocolo, é  
> a chave ou identificador do objeto. Como o Amadeu comentou muito  
> bem, há várias outras informações que podem ser associadas a um  
> servant que permitam implementar protocolos mais elaborados. Por  
> exemplo, CORBA usa informações de interface para enviar dados  
> codificados sem precisar informar os tipos desses dados, permitindo  
> um stream menor. Porém é necessário garantir que a mesma descrição  
> de interface esteja corretamente presente nos dois pontos da  
> comunicação.
>
> Portanto o fato é: informar a chave de um servant é um recurso  
> presente em absolutamente todos os "flavors" do OiL. Entretanto  
> especificar a interface, apesar de unânime em todos os protocolos  
> "mainstream", não é necessário em todos os protocolos. O LuDO é um  
> protocolo de mentira, mas que ilustra várias possibilidades para  
> protocolos reais, em particular protocolos "dinâmicos", ou seja,  
> feitos para linguagens dinâmicas. Portanto não é de estranhar que  
> ele seja diferente de protocolos como CORBA, SOAP, JavaRMI que são  
> projetados para ser utilizados com linguagens mais estáticas. Um  
> exemplo de protocolo que é parecido com o LuDO em vários aspectos é  
> o Pyro que é projetado para Python, outra linguagem dinâmica. Bom,  
> para resumir, o meu problema é como estender a operação 'newservant'  
> para incluir novos parâmetros. Pensando na generalidade da  
> arquitetura básica do OiL, o ideal é estender uma operação como a  
> 'newservant' incluindo parâmetros adicionais ao seu final, pois  
> assim fica fácil escrever implementações genéricas como o Amadeu  
> comentou:
>
> function ServerBroker.broker:object(impl, key, ...)
> -- manipula o parâmetro key para que isso não precise ser
> -- feito novamente para cada protocolo, pois esse é um
> -- recurso fatorado para implementação básica do OiL.
> if key == nil then key = self:generate_unique_id(impl) end
>
> -- registra o servant com a chave e repassa quaisquer
> -- informações adicionais
> return self.dipatcher:register(impl, key, ...)
> end
>
> Entretanto, essa forma de extensão fica ruim para o caso de CORBA e  
> outros protocolos tipados, porque quem usa um protocolo não está  
> interessado na arquitetura interna do OiL ou na sua generalidade.  
> Por isso é um problema para mim e resolvi fazer essa discussão com  
> vocês. Mas depois das respostas de vocês, acho que o problema é mais  
> em como oferecer um açúcar para não irritar os usuários CORBA e cia.  
> com os detalhes sobre a generalidade da implementação do OiL. Por  
> isso vou fazer algum bacalhau na API externa do OiL, tal como:
>
> if ORB.requiresTypeInfo then -- ainda não sei como descobrir isso.
> function ORB:newservant(impl, iface, key)
>   assert(type(key) == "string", "invalid object key")
>   return self.ServerBroker.broker:object(impl, key, iface)
> end
> else
> function ORB:newservant(impl, key, ...)
>   assert(type(key) == "string", "invalid object key")
>   return self.ServerBroker.broker:object(impl, key, ...)
> end
> end
>
> Sei que é uma solução porca, mas não sei como fazer isso melhor.  
> Sugestões?
>
> Obrigado mais uma vez pelas respostas.
> Um abração!
>
>
> --
> Renato Maia
> PhD student at PUC-Rio
> __________________________
> http://www.inf.puc-rio.br/~maia/
>
>
>
> _______________________________________________
> OiL-Devel mailing list
> OiL-Devel at lists.luaforge.net
> http://lists.luaforge.net/cgi-bin/mailman/listinfo/oil-devel