O &MCOP; é a norma que o &arts; usa para: A comunicação entre os objectos. A transparência na rede. A descrição das interfaces dos objectos. A independência da linguagem. Um aspecto importante do &MCOP; é a linguagem de descrição de interfaces, ou &IDL;, na qual muitas das interfaces do &arts; e as APIs estão definidas de forma independente da linguagem. Para usar as interfaces de &IDL; a partir do C++, é compilada pelo compilador de &IDL; em código de C++. Quando você implementar uma interface, você irá derivar da classe de esqueleto que o compilador de &IDL; gerou. Quando usar uma interface, você irá fazer isso através de uma classe envolvente ('wrapper'). Desta forma, o &MCOP; pode usar um protocolo se o objecto com quem você está a falar não estiver local - você obtém assim a transparência de rede. Este capítulo é suposto descrever as funcionalidades básicas do modelo de objectos que resulta da utilização do &MCOP;, o protocolo, como usar o &MCOP; no C++ (interface para a linguagem), e assim por diante. Muitos dos serviços fornecidos pelo &arts;, como os módulos e o servidor de som, são definidos com base em interfaces. As interfaces são especificadas num formato independente de linguagens: a &IDL;. Isto permite que muitos dos detalhes de implementação, como o formato das sequências de dados multimédia, a transparência de rede e as dependências de linguagens de programação, sejam escondidos da especificação da interface. Uma ferramenta, o &mcopidl;, traduz a definição da interface para uma linguagem de programação específica (de momento, só o C++ é que é suportado). A ferramenta gera uma classe-esqueleto com todo o código de 'cola' e a funcionalidade de base. Você pode derivar a partir dessa classe para implementar as funcionalidades que deseja. A &IDL; usada pelo &arts; é semelhante à usada pelo CORBA e pelo DCOM. Os ficheiros &IDL; podem conter: Directivas #include do estilo do C para outros ficheiros &IDL;. Definições de tipos enumerados e estruturas, como no C/C++. Definições de interfaces. Na &IDL;, as interfaces são definidas de forma muito semelhante à de uma classe de C++ ou de uma estrutura do C, ainda que com algumas restrições. Como no C++, as interfaces podem ser subclasses de outras interfaces através de herança. As definições de interfaces podem incluir três coisas: sequências, atributos e métodos. As sequências ou canais definem os dados multimédia, um dos componentes mais importantes de um módulo. As sequências são definidas no seguinte formato: [ async ] in|out [ multi ] tipo stream nome [ , nome ] ; As sequências têm uma direcção definida na referência do módulo, tal como é indicado pelos qualificadores necessários 'in' ou 'out'. O argumento 'tipo' define o tipo dos dados, o qual poderá ser qualquer um dos tipos descritos posteriormente para os atributos (nem todos são suportados de momento). Muitos dos módulos usam o tipo de sequência 'audio', o qual é um nome alternativo para o 'float' (vírgula-flutuante) dado que é o formato interno dos dados usados para o áudio. Podem ser definidas várias sequências do mesmo tipo na mesma definição se usar nomes separados por vírgulas. As sequências são síncronas por omissão, o que significa que elas são fluxos contínuos de dados a uma taxa constante, como o áudio PCM. O qualificador 'async' indica que é uma sequência assíncrona, a qual é usada para os fluxos de dados descontínuos. O exemplo mais comum de uma sequência assíncrona são as mensagens do &MIDI;. A palavra-chave 'multi', que só é válida para as sequências de entrada, indica que a interface suporta um número variável de entradas. Isto é útil para implementar os dispositivos, como as mesas de mistura, que possam aceitar qualquer número de sequências de entrada. Os atributos são os dados associados com uma instância de uma interface. Estes são declarados como as variáveis-membro do C++, e podem usar qualquer um dos tipos primitivos 'boolean', 'byte', 'long', 'string', ou 'float'. Você também poderá usar os tipos 'struct' ou 'enum' definidos pelo utilizador, assim como as sequências de tamanho variável, usando a sintaxe sequence<tipo>. Os atributos podem ser marcados opcionalmente como 'readonly' (apenas para leitura). Tal como no C++, os métodos podem ser definidos nas interfaces. Os parâmetros dos métodos estão restringidos aos mesmos tipos dos atributos. A palavra-chave 'oneway' indica um método que devolve valores imediatamente e é executado assincronamente. Já estão definidas várias interfaces-padrão de módulos para você no &arts;, como o StereoEffect e o SimpleSoundServer. Um exemplo simples de um módulo retirado do &arts; é o módulo de atraso constante, o qual se encontra no ficheiro tdemultimedia/arts/modules/artsmodules.idl. A definição da interface está indicada em baixo. interface Synth_CDELAY : SynthModule { attribute float time; in audio stream invalue; out audio stream outvalue; }; Este módulo herda de SynthModule. Essa interface, definida no artsflow.idl, define os métodos-padrão que são implementados em todos os módulos de síntese de música. O efeito CDELAY atrasa um canal estéreo pelo tempo indicado em 'time', o qual é um parâmetro de vírgula flutuante. A definição da interface tem um atributo do tipo 'float' para guardar o valor do atraso. Ele define duas sequências de áudio de entra e duas sequências de saída (o que é típico nos efeitos estéreo). Não são necessários mais métodos para além dos que ele já herdou. Esta secção cobre alguns tópicos adicionais relacionados com as sequências. Existem vários requisitos para a forma como um módulo pode fazer a transmissão. Para ilustrar isto, considere estes exemplos: Aumentar o sinal por um factor de 2. Efectuar uma conversão na frequência da amostra. Descomprimir um sinal codificado em RLE. Ler os eventos de &MIDI; do /dev/midi00 e introduzi-los numa sequência. O primeiro caso é o mais simples: depois de receber 200 amostras da entrada, o módulo produz 200 amostras de resultado. Só produz resultados à saída quando obtiver algo à entrada. O segundo caso produz números diferentes de amostras de resultado, quando são dadas 200 amostras de entrada. Isto depende de qual a conversão que é efectuada, mas o número é conhecido antecipadamente. O terceiro caso é ainda pior. Para o resultado, você nem sequer consegue adivinhar quantos dados as 200 amostras de entrada irão gerar (provavelmente muito mais do que 200 amostras à saída, mas...). O último caso é um módulo que se torna ele próprio activo e, de vez em quando, produz dados. No &arts;s-0.3.4, só as sequências do primeiro tipo eram tratadas, e a maioria das coisas funcionavam. Isto é provavelmente o que você necessita para criar os módulos que processem áudio. O problema com os outros tipos mais complexos de transmissão é que eles são difíceis de programar e que você não precisa das suas funcionalidades na maior parte das vezes. É por isso que o processamento pode ser feito com dois tipos diferentes de sequências: síncronas e assíncronas. As sequências síncronas têm estas características: Os módulos deverão ser capazes de calcular dados de qualquer dimensão, desde que sejam fornecidos em quantidade suficiente. Todas as sequências têm a mesma taxa de amostragem. A função calculateBlock() será chamada quando existirem dados suficientes disponíveis, e o módulo possa confiar nos ponteiros que referenciam os dados. Não existe nenhuma alocação e libertação de memória a ser feita. As sequências assíncronas, por outro lado, têm este comportamento: Os módulos poderão produzir dados algumas das vezes, ou com uma taxa de amostragem variável, ou apenas se eles tiverem dados de entrada de algum descritor de ficheiro. Eles não estão limitados pela regra deve ser capaz de atender pedidos de qualquer tamanho. As sequências assíncronas de um módulo poderão ter taxas de amostragem totalmente diferentes. Sequências de saída: existem funções explícitas para alocar pacotes, para enviá-los - e um mecanismo de pesquisa ('polling') opcional que lhe dirá quando deverá criar mais dados. Sequências de entrada: você obtém uma chamada sempre que recebe um novo pacote - você terá de dizer quando estiver a processar todos os dados desse pacote, o que não deverá acontecer de uma vez (você poderá dizer isso mais tarde e, se toda a gente já processou o pacote, este será libertado/reutilizado). Quando você declara as sequências, você poderá usar a palavra-chave async para indicar que quer criar uma sequência assíncrona. Por isso, por exemplo, assuma que quer converter uma sequência assíncrona de 'bytes' para uma sequência síncrona de amostras. A sua interface poderia ser algo semelhante a isto: interface SequenciaBytesParaAudio : SynthModule { async in byte stream entrada; // a sequência assíncrona de amostras de entrada out audio stream esquerda,direita; // a sequência síncrona de amostras de saída }; Imagine que decidiu criar um módulo para produzir som assincronamente. A sua interface seria algo parecido com o seguinte: interface UmModulo : SynthModule { async out byte stream saida; }; Como é que você envia os dados? O primeiro método é chamado de push delivery (tradução livre: 'entrega por empurrão'). Com as sequências assíncronas, você envia os dados como pacotes. Isto significa que você envia pacotes individuais com 'bytes', como no exemplo acima. O processo actual é: alocar um pacote, preenchê-lo, enviá-lo. Aqui está isso, em termos de código. Primeiro, é alocado um pacote: DataPacket<mcopbyte> *pacote = saida.allocPacket(100); Aí, será preenchido: // converter de modo a que o 'fgets' fique contente com um ponteiro (char *) char *dados = (char *)pacote->contents; // como pode ver, você pode encolher o tamanho do pacote depois da alocação, // se quiser if(fgets(dados,100,stdin)) pacote->size = strlen(dados); else pacote->size = 0; Agora, o mesmo é enviado: pacote->send(); Isto é muito simples, mas se precisar de enviar os pacotes à mesma rapidez com que o destinatário os consegue processar, é necessária outra aproximação, a pull delivery ('entrega por puxão'). Você pede para enviar os pacotes tão rapidamente quanto o destinatário está pronto para processar. Você começa com uma determinada quantidade de pacotes que envia. À medida que o destinatário vai processando um pacote a seguir ao outro, você começa a preenchê-los de novo com dados novos, enviando-os mais uma vez. Você inicia isso ao chamar o 'setPull'. Por exemplo: saida.setPull(8, 1024); Isto significa que você deseja enviar os pacotes pela 'saida'. Você irá querer começar a enviar 8 pacotes de cada vez e, à medida que o destinatário processar alguns deles, você poderá querer preenchê-los de novo. Aí, você precisa de implementar um método que preenche os pacotes, e que poderá se assemelhar ao seguinte: void request_saida(DataPacket<mcopbyte> *pacote) { pacote->size = 1024; // não deverá ser maior que 1024 for(int i = 0;i < 1024; i++) pacote->contents[i] = (mcopbyte)'A'; pacote->send(); } É tudo; quando não tiver mais dados, você poderá começar a enviar pacotes com tamanho nulo, o que irá parar a recepção. Repare que é essencial dar ao método o nome exacto request_nome-sequência. Foi então discutido o envio dos dados. A recepção dos mesmos é muito mais simples. Suponha que você tem um filtro ParaMinusculas, que simplesmente converte todas as letras para minúsculas: interface ParaMinusculas { async in byte stream entrada; async out byte stream saida; }; Isto é mesmo simples de implementar; aqui está a implementação completa: class ParaMinusculas_impl : public ParaMinusculas_skel { public: void process_entrada(DataPacket<mcopbyte> *pacote_entrada) { DataPacket<mcopbyte> *pacote_saida = saida.allocPacket(pacote_entrada->size); // convert to lowercase letters char *texto_entrada = (char *)pacote_entrada->contents; char *texto_saida = (char *)pacote_entrada->contents; for(int i=0;i<pacote_entrada->size;i++) texto_saida[i] = tolower(texto_entrada[i]); pacote_entrada->processed(); pacote_saida->send(); } }; REGISTER_IMPLEMENTATION(ParaMinusculas_impl); Mais uma vez, é importante dar o nome process_nome-sequencia ao método. Como pode ver, para cada pacote que chega, você obtém uma chamada a uma função ( a process_entrada no caso em questão). Você precisa de chamar o método processed() de um pacote para indicar que acabou de o processar. Aqui está uma sugestão de implementação: se o processamento levar mais tempo (&ie; se precisar de esperar pelo resultado da placa de som ou algo do género), não invoque o 'processed' logo, mas armazene o pacote de dados em si e invoque o 'processed' apenas quando você processar de facto esse pacote. Desta forma, os emissores têm uma hipótese de saber quanto tempo leva mesmo a efectuar o seu trabalho. Dado que a sincronização não é tão boa com as sequências assíncronas, você deverá usar as sequências síncronas sempre que possível e as assíncronas, só quando for necessário. Imagine que tem 2 objectos, como por exemplo um ProdutorAudio e um ConsumidorAudio. O ProdutorAudio tem uma sequência de saída e o ConsumidorAudio tem uma de entrada. De cada vez que os tentar ligar, você irá usar estas duas sequências. A primeira utilização da predefinição é permitir-lhe fazer a ligação sem indicar os portos nesse caso. Agora imagine que os dois objectos poderão lidar com o estéreo, e cada um possa ter um porto left (esquerdo) e right (direito). Você gostaria à mesma de os ligar de forma tão simples como anteriormente. Mas como é que o sistema de ligações saberia que porto de saída deveria ligar a que porto de entrada? Não tem nenhuma forma de mapear correctamente as sequências. A utilização de portos predefinidos poderá então ser adoptada para indicar várias sequências, com uma dada ordem. Desta forma, quando você ligar um objecto com 2 portos predefinidos a outro objecto com 2 portos predefinidos de entrada, não terá de indicar os portos e, nesse caso, o mapeamento será feito correctamente. Obviamente, isto não está limitado ao estéreo. Pode-se tornar qualquer número de sequências como predefinidas se necessário, e a função 'connect' irá verificar se o número de predefinições para os dois objectos correspondem (na direcção necessária), se você não indicar os portos a usar. A sintaxe é a seguinte: na &IDL;, você poderá usar a palavra-chave 'default' na declaração da sequência ou numa única linha. Por exemplo: interface MisturaDoisEmUm { default in audio stream entrada1, entrada2; out audio stream saida; }; Neste exemplo, o objecto irá esperar que os seus dois portos de entrada estejam ligados por omissão. A ordem é a indicada na linha 'default', por isso, um objecto do tipo: interface GeradorRuidoDuplo { out audio stream bzzt, cuic; default cuic, bzzt; }; Fará as ligações do cuic à entrada1 e do bzzt à entrada2 automaticamente. Repare que, dado que só há uma saída para o misturador, será tornada predefinida nesse caso (ver em baixo). A sintaxe usada no gerador de ruído é útil para declarar uma ordem diferente da declaração, ou seleccionando apenas alguns portos como predefinidos. As direcções dos portos nesta linha serão pesquisados pelo &mcopidl;, por isso não os indique. Você até poderá misturar os portos de entrada e de saída numa linha destas, onde só a ordem é que é relevante. Existem algumas regras que são seguidas ao usar a herança: Se for indicada uma lista 'default' na &IDL;, então use-a. Os portos-pai podem ser colocados também nesta lista, quer fossem predefinidos no 'pai' ou não. Caso contrário, herde as predefinições do 'pai'. A ordem é do tipo 'pai1 predefinicao1, pai1 predefinicao2..., pai2 predefinicao1... Se existir um ascendente comum em dois ramos-pai, é feita uma junção do tipo virtual public na primeira ocorrência da predefinição na lista. Se não existir à mesma nenhuma predefinição e existir uma sequência simples numa dada direcção, use-a como predefinida nessa direcção. As notificações de alteração de atributos são uma forma de saber quando é que um atributo foi alterado. Eles são ligeiramente compatíveis com os 'signals' e 'slots' do &Qt; e do Gtk. Por exemplo, se você tiver um elemento gráfico, como uma barra deslizante, que configura um número entre 0 e 100, você poderá ter normalmente um objecto que faça algo com esse número (por exemplo, poderá controlar o volume de um sinal de áudio). Por isso, você gostaria que, de cada vez que movesse a barra, o objecto que ajustasse o volume fosse notificado. Uma ligação entre um emissor e um receptor. O &MCOP; lida com isso, sendo capaz de oferecer notificações de cada vez que os atributos são alterados. Tudo o que for declarado como atributo na &IDL;, pode emitir essas notificações de alterações, e devê-lo-á fazer, sempre que for modificado. Tudo o que for declarado como atributo poderá também receber essas notificações de alteração. Por isso, se por exemplo tiver duas interfaces de &IDL;, como as seguintes: interface BarraDeslizante { attribute long min,max; attribute long posicao; }; interface ControloVolume : Arts::StereoEffect { attribute long volume; // 0..100 }; Você podê-las-á ligar com as notificações de alteração. Isto funciona usando a operação normal de 'connect' do sistema de fluxo. Neste caso, o código de C++ para ligar dois objectos deverá ser semelhante ao seguinte: #include <connect.h> using namespace Arts; [...] connect(barra,"posicao_changed",controlo_Volume,"volume"); Como pode ver, cada atributo oferece duas sequências diferentes, uma para enviar as notificações de alteração, chamada de nome-atributo_changed, e outra para receber as notificações de alteração, chamada nome-atributo. É importante saber que as notificações de alteração e as sequências assíncronas são compatíveis. São também transparentes na rede. Por isso, você consegue ligar uma notificação de alteração de um atributo 'float' de um elemento &GUI; a uma sequência assíncrona de um módulo de síntese a correr noutro computador. Isto, obviamente, implica que as notificações de alteração não sejam síncronas, o que significa que, depois de ter enviado a notificação de alteração, poderá levar algum tempo até que esta seja de facto recebida. Ao implementar objectos que tenham atributos, você precisa de enviar as notificações de alteração sempre que um dado atributo muda. O código para o fazer é semelhante ao seguinte: void KPoti_impl::valor(float novoValor) { if(novoValor != _valor) { _valor = novoValor; valor_changed(novoValor); // <- envia a notificação de alteração } } É bastante recomendado que use código deste género para todos os objectos que implementar, de modo a que as notificações de alterações possam ser usadas pelas outras pessoas. Você deverá, contudo, evitar o envio das notificações com demasiada frequências, por isso, se estiver a fazer processamento de sinal, é provavelmente melhor que você mantenha um registo de quando enviou a sua última notificação, para que não envie uma com cada uma das amostras que processar. Será especialmente útil usar as notificações de alteração em conjunto com os osciloscópios (as coisas que visualizam os dados de áudio, por exemplo), os elementos gráficos, elementos de controlo e na monitorização. O código que usa isto está em tdelibs/arts/tests e na implementação experimental do 'artsgui', que poderá encontrar em tdemultimedia/arts/gui. O ficheiro .mcoprc (na pasta pessoal de cada utilizador) poderá ser usado para configurar o &MCOP; em alguns aspectos. De momento, é possível o seguinte: GlobalComm O nome de uma interface a usar para a comunicação global. A comunicação global é usada para procurar os outros objectos e obter o 'cookie' secreto. Vários clientes/servidores de &MCOP; que deverão ser capazes de falar entre si precisam de ter um objecto 'GlobalComm' que seja capaz de partilhar informações entre eles. De momento, os valores possíveis são o Arts::TmpGlobalComm para comunicar através da pasta /tmp/mcop-utilizador (que irá funcionar apenas no computador local) ou o Arts::X11GlobalComm para comunicar através das propriedades da janela de topo do servidor X11. TraderPath Indica onde procurar pela informação do mediador. Você poderá indicar aqui mais do que uma pasta, separando as pastas com vírgulas, como no exemplo ExtensionPath Indica a partir de que pastas é que as extensões (na forma de bibliotecas dinâmicas) são carregadas. Podem ser indicados vários valores, separados por vírgulas. Um exemplo que usa tudo isso é o seguinte: # Ficheiro $HOME/.mcoprc GlobalComm=Arts::X11GlobalComm # se você é um programador, será útil adicionar uma pasta na sua área # para que a localização do(a) mediador/extensão sejam capazes de adicionar # componentes sem os instalar TraderPath="/opt/kde2/lib/mcop","/home/ze/mcop_desenvolvimento/mcop" ExtensionPath="/opt/kde2/lib","/home/ze/mcop_desenvolvimento/lib" Se já usou o CORBA antes, irá concluir que o &MCOP; é muito parecido, de facto. De facto, o &arts;, antes da versão 0.4 usava o CORBA. A ideia básica do CORBA é a mesma: você implementa os objectos (componentes). Se usar as funcionalidades do &MCOP;, os seus objectos não estão só disponíveis como classes normais do mesmo processo (através das técnicas normais do C++) - eles passam a estar disponíveis de forma transparente para os servidores remotos. Para isto funcionar, a primeira coisa que precisa de fazer é indicar a interface dos seus objectos num ficheiro &IDL; - tal como na &IDL; do CORBA. Existem apenas algumas diferenças. No &MCOP; não existem parâmetros in e out nas invocações dos métodos. Os parâmetros são sempre de entrada e o código devolvido é sempre de saída, o que significa que a interface: // idl de CORBA interface Conta { void depositar( in long quantia ); void levantar( in long quantia ); long saldo(); }; é escrito como // idl de MCOP interface Conta { void depositar( long quantia ); void levantar( long quantia ); long saldo(); }; no &MCOP;. Não existe o suporte de excepções. O &MCOP; não tem excepções - ele usa algo de diferente para o tratamento de erros. Não existem tipos 'union' nem 'typedef's. Não se sabe se é uma falha de facto, algo que uma pessoa necessitasse desesperadamente para sobreviver. Não existe suporte para passar referências a interfaces ou objectos Você declara as sequências como sequencetipo no &MCOP;. Não existe necessidade de um 'typedef'. Por exemplo, em vez de: // CORBA idl struct Linha { long x1,y1,x2,y2; }; typedef sequence<Linha> Linhas; interface Desenhador { void desenhar(in Linhas linhas); }; você iria descrever // IDL de MCOP struct Linha { long x1,y1,x2,y2; }; interface Desenhador { void desenhar(sequence<Linha> linhas); }; Você pode declarar as sequências que serão então avaliadas pela plataforma do &arts;. As sequências são declaradas de forma semelhante aos atributos. Por exemplo: // MCOP idl interface Synth_ADICIONAR : SynthModule { in audio stream sinal1,sinal2; out audio stream saida; }; Isto diz que o seu objecto irá aceitar duas sequências síncronas de áudio chamadas 'sinal1' e 'sinal2'. Por síncronas significa que são sequências que distribuem 'x' amostras por segundo (ou por outro período), de modo a que o escalonador garanta que lhe fornecerá uma quantidade balanceada de dados de entrada (⪚ existem 200 amostras de 'sinal1' para 200 amostras de 'sinal2'). Você garante que, se o seu objectivo for chamado com essas 200 amostras de 'sinal1' e 'sinal2', será capaz de produzir exactamente 200 amostras de 'saida'. Isto difere do CORBA principalmente: As cadeias de caracteres usam a classe de C++ do STL string. Quando é armazenado nas sequências, elas são armazenadas tal-e-qual, o que significa que são consideradas como sendo um tipo primitivo. Deste modo, elas precisam de ser copiadas. os 'long's são 'long's normais (contando que são de 32 bits). As sequências usam a classe de C++ do STL vector. As estruturas são todas derivadas da classe do &MCOP; Type, e são geradas no compilador de &IDL; do &MCOP;. Quando forem armazenadas em sequências, elas não serão guardadas tal-e-qual , mas sim como referências porque, caso contrário, iriam ocorrer várias cópias. Depois de passar as interfaces pelo compilador de &IDL;, você precisa de derivar da classe _skel. Por exemplo, assuma que definiu a sua interface da seguinte forma: // IDL do MCOP: ola.idl interface Ola { void Ola(string s); string concatenar(string s1, string s2); long somar2(long a, long b); }; Você pode passar isso pelo compilador de &IDL;, invocando o comando mcopidl ola.idl, o que por sua vez irá gerar o ola.cc e o ola.h. Para o implementar, você precisa de definir uma classe de C++ que herde do esqueleto: // ficheiro de inclusão de C++ - inclua o ola.h algures class Ola_impl : virtual public Ola_skel { public: void ola(const string& s); string concatenar(const string& s1, const string& s2); long somar2(long a, long b); }; Finalmente, você terá de implementar os métodos como C++ normal // ficheiro de implementação de C++ // como pode ver, as 'string's são passadas como referências de 'const string' void Ola_impl::ola(const string& s) { printf("Ola '%s'!\n",s.c_str()); } // quando têm um valor a devolver são passadas como cadeias de caracteres normais string Ola_impl::concatenar(const string& s1, const string& s2) { return s1+s2; } long Ola_impl::somar2(long a, long b) { return a+b; } Logo que faça isso, você terá um objecto que poderá comunicar usando o &MCOP;. Basta criar um (usando as funcionalidades normais do C++ para criar um objecto): Servidor do Ola_impl; E assim que dê a alguém a referência string referencia = servidor._toString(); printf("%s\n",referencia.c_str()); e ir à ciclo de inactividade do &MCOP; Dispatcher::the()->run(); As pessoas podem aceder à coisa usando // este código poderá correr em qualquer lado - não necessariamente no mesmo // processo (poderá também correr num computador/arquitectura diferentes) Ola *h = Ola::_fromString([a referência do objecto impressa acima]); e invocar os métodos: if(h) h->ola("teste"); else printf("O acesso falhou?\n"); Dado que os servidores de &MCOP; irão atender os pedidos num porto de TCP, potencialmente toda a gente (se você estiver na Internet) poderá tentar ligar-se aos serviços do &MCOP;. Por isso, é importante autenticar os clientes. O &MCOP; usa o protocolo 'md5-auth'. O protocolo 'md5-auth' faz o seguinte para garantir que só os clientes seleccionados (de confiança) se poderão ligar a um servidor: Ele assume que você dá a todos os clientes um 'cookie' secreto. De cada vez que um cliente se liga, ele verifica se o cliente conhece esse 'cookie' secreto, sem o transferir de facto (nem sequer de forma a que alguém que esteja a escutar o tráfego de rede o possa descobrir). Para dar a cada cliente esse 'cookie' secreto, o &MCOP; irá (normalmente) colocá-lo na pasta mcop (em /tmp/mcop-USER/secret-cookie). Claro, você podê-lo-á copiar para outros computadores. Contudo, se o fizer, use um mecanismo de transferência seguro, como o scp (do ssh). A autenticação dos clientes usa os seguintes passos: [SERVIDOR] gera um 'cookie' novo (aleatório) R [SERVIDOR] envia-o para o cliente [CLIENTE] lê o "cookie secreto" S de um ficheiro [CLIENTE] baralha os 'cookies' R e S para um 'cookie' baralhado M usando o algoritmo MD5 [CLIENTE] envia o M para o servidor [SERVIDOR] verifica que, ao baralhar o R e o S dará o mesmo resultado que o 'cookie' M recebido do cliente. Em caso afirmativo, a autenticação foi bem-sucedida. Este algoritmo deverá ser seguro, atendendo a que Os 'cookies' secretos e os aleatórios são aleatórios quanto baste e O algoritmo de dispersão do MD5 não permite descobrir o texto original, que é o 'cookie' secreto S e o 'cookie' aleatório R (o qual é conhecido, de qualquer forma), a partir do 'cookie' baralhado M. O protocolo &MCOP; irá começar todas as ligações novas com um processo de autenticação. Basicamente, assemelha-se ao seguinte: O servidor envia uma mensagem ServerHello que descreve os protocolos de autenticação conhecidos. O cliente envia uma mensagem ClientHello que inclui a informação de autenticação. O servidor envia uma mensagem AuthAccept. Para verificar se a segurança funciona de facto, deverá ver como é que as mensagens se processam nas ligações não-autenticadas: Antes de a autenticação ser bem sucedida, o servidor não irá receber outras mensagens da ligação. Em vez disso, se o servidor por exemplo estiver à espera de uma mensagem ClientHello e obtiver uma mensagem de 'mcopInvocation', irá quebrar a ligação. Se o cliente não enviar uma mensagem de &MCOP; válida de todo (sem o código especial do &MCOP; no cabeçalho da mensagem) na fase de autenticação, mas sim outra coisa qualquer, a ligação é quebrada. Se o cliente tentar enviar uma mensagem mesmo muito grande (> 4096 bytes na fase de autenticação, o tamanho da mensagem é truncado para 0 bytes, o que fará com que não seja aceite para a autenticação). Isto é para evitar que os clientes não-autenticados enviem mensagens de ⪚ 100 megabytes, o que faria com que fosse recebida e com que o servidor estoirasse com falta de memória. Se o cliente enviar uma mensagem ClientHello corrompida (uma, onde a descodificação falhe), a ligação é mais uma vez quebrada. Se o cliente não enviar nada de nada, então ocorrerá a expiração de um tempo-limite (ainda por implementar). Tem semelhanças conceptuais ao CORBA, mas pretende extendê-lo de todas as formas necessárias para as operações multimédia em tempo-real. Oferece um modelo de objectos multimédia, o qual poderá ser usado para: a comunicação entre os componentes num espaço de endereçamento (um processo) e entre componentes que existam em tarefas, processos ou mesmo máquinas diferentes. Tudo junto, será desenhado para uma performance extremamente alta (de modo a que tudo seja optimizado para ser extremamente rápido), o que é adequado para as aplicações multimédia bastante comunicativas. Por exemplo, a transmissão de vídeos é uma das aplicações do &MCOP;, onde a maioria das implementações de CORBA 'cairiam de joelhos'. As definições das interfaces conseguem lidar com as seguintes coisas nativamente: Sequências contínuas de dados (como os dados de áudio). Sequências de dados de eventos (como os eventos do &MIDI;). Contagem de referências real. e os truques mais importantes do CORBA, como As invocações síncronas de métodos. As invocações de métodos assíncronas. A construção de tipos de dados definidos pelo utilizador. Herança múltipla. A passagem de referências de objectos. Objectivos/ideias de desenho: A codificação deverá ser simples de implementar. A descodificação necessita que o destinatário saiba qual é o tipo que ele deseja descodificar. O destinatário está à espera de usar toda a informação - por isso, só são ignorados os dados no protocolo ao nível em que: Se você souber que vai receber um bloco de 'bytes', não precisa de olhar para cada 'byte', à procura de um marcador de fim. Se você souber que vai receber uma cadeia de caracteres, não precisa de a ler até encontrar o 'byte' zero para descobrir o seu tamanho, contudo, Se você souber que vai receber uma sequência de cadeias de caracteres, você precisa de saber o tamanho de cada uma delas para descobrir o fim da sequência, dado que as cadeias de caracteres têm tamanho variável. Mas se você usar as cadeias de caracteres para algo útil, você terá de o fazer à mesma, por isso não se perde nada. O mínimo de sobrecarga possível. A codificação dos diferentes tipos é mostrada na tabela em baixo: Tipo Processo de Codificação Resultado void Os tipos void são codificados, omitindo-os, de modo a que e não seja nada escrito no canal. long é codificado como 4 'bytes', em que o 'byte' mais significativo vem primeiro, de modo a que o número 10001025 (correspondente a 0x989a81) será codificado como: 0x00 0x98 0x9a 0x81 enums são codificados como longs byte é codificado como um único 'byte', de modo a que o 'byte' 0x42 será codificado como: 0x42 string é codificado como um long, contendo o tamanho da cadeia de caracteres seguinte, e pela sequência de caracteres propriamente dita, terminando com um 'byte' a zeros (que está incluído na contagem do tamanho). inclui o 'byte' 0 final na contagem do tamanho! O ola seria codificado da seguinte forma: 0x00 0x00 0x00 0x04 0x6f 0x6c 0x60 0x00 boolean é codificado como um 'byte', contendo 0 se for false (falso) ou 1 se for true (verdadeiro), de modo a que o valor booleano true é codificado como: 0x01 float é codificado na representação de 4 'bytes' do IEEE754 - a documentação detalhada de como o IEEE funciona estão aqui: http://twister.ou.edu/workshop.docs/common-tools/numerical_comp_guide/ncg_math.doc.html e aqui: http://java.sun.com/docs/books/vmspec/2nd-edition/html/Overview.doc.html. Deste modo, o valor 2,15 seria codificado como: 0x9a 0x99 0x09 0x40 'struct' Uma estrutura é codificada com base no seu conteúdo. Não existem prefixos ou sufixos adicionais, por isso a estrutura struct teste { string nome; // que é igual a "ola" long valor; // que é igual a 10001025 (0x989a81) }; seria codificada como 0x00 0x00 0x00 0x04 0x6f 0x6c 0x60 0x00 0x00 0x98 0x9a 0x81 sequência uma sequência é codificada através da listagem do número de elementos que se seguem e da descodificação dos elementos, um a um. Por isso uma sequência de 3 'longs' 'a', with a[0] = 0x12345678, a[1] = 0x01 e a[2] = 0x42 seria codificada como: 0x00 0x00 0x00 0x03 0x12 0x34 0x56 0x78 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x42 Se você precisar de fazer referência a um tipo, todos os tipos primitivos são referidos pelos nomes indicados acima. As estruturas e os enumerados têm nomes próprios (como Header). As sequências são referidas como um *tipo normal, de modo que uma sequência de 'longs' é um *long e uma sequência de estruturas Header é um *Header. O formato do cabeçalho das mensagens do &MCOP; está definido pela estrutura seguinte: struct Header { long magic; // o valor 0x4d434f50, que é codificado como MCOP long messageLength; long messageType; }; Os valores possíveis de messageTypes são, de momento mcopServerHello = 1 mcopClientHello = 2 mcopAuthAccept = 3 mcopInvocation = 4 mcopReturn = 5 mcopOnewayInvocation = 6 Algumas notas acerca das mensagens do &MCOP;: Todas as mensagens começam com uma estrutura Header. Alguns dos tipos de mensagens deverão ser ignorados pelo servidor, enquanto a autenticação não estiver completa. Depois de receber o cabeçalho, o tratamento do protocolo (ligação) poderá receber a mensagem por completo, sem olhar para o seu conteúdo. O 'messageLength' no cabeçalho é, obviamente em alguns casos, redundante, o que significa que esta aproximação não é minimalista no que respeita ao número de 'bytes'. Contudo, conduz a uma implementação simples (e rápida) do processamento não-bloqueante de mensagens. Com a ajuda do cabeçalho, as mensagens poderão ser recebidas pelas classes de tratamento do protocolo em segundo plano (não-bloqueante), se existirem demasiadas ligações ao servidor, todas elas poderão ser servidas em paralelo. Você não precisa de olhar para o conteúdo da mensagem para a receber (e para determinar que terminou), basta olhar para o cabeçalho, por isso o código para isso é relativamente simples. Logo que esteja lá uma mensagem, esta poderá ser descodificada e processada num único passo, sem se preocupar com os casos em que nem todos os dados foram recebidos (porque o 'messageLength' garante que está lá tudo). Para invocar um método remoto, você precisa de enviar a seguinte estrutura no corpo de uma mensagem de &MCOP; com o messageType = 1 (mcopInvocation): struct Invocation { long objectID; long methodID; long requestID; }; depois disso, você envia os parâmetros como uma estrutura, ⪚ se você invocar o método 'concatenar(string s1, string s2)', você envia uma estrutura do tipo struct InvocationBody { string s1; string s2; }; se o método foi declarado como 'só de ida0 - o que significa que é assíncrono sem código devolvido - então é tudo. Caso contrário, você iria receber como resposta uma mensagem com o messageType = 2 (mcopReturn) struct ReturnCode { long requestID; <tipo-a-devolver> result; }; em que o <tipo-a-devolver> é o tipo do resultado. Como os tipos 'void' são omitidos na codificação, você também poderá só escrever o 'requestID' se regressar de um método 'void'. Por isso o nosso método 'string concatenar(string s1, string s2)' iria originar um código de resultado do tipo struct ReturnCode { long requestID; string result; }; Para fazer as invocações, você teria de conhecer os métodos que um objecto suporta. Para o fazer, o 'methodID' 0, 1, 2 e 3 estão pré-destinados a certas funcionalidades. Isto é long _lookupMethod(MethodDef defMetodo); // methodID sempre a 0 string _interfaceName(); // methodID sempre a 1 InterfaceDef _queryInterface(string nome); // methodID sempre a 2 TypeDef _queryType(string nome); // methodID sempre a 3 para ler isso, você obviamente precisa de struct MethodDef { string methodName; string type; long flags; // posto a 0 por agora (será necessário na transmissão) sequence<ParamDef> signature; }; struct ParamDef { string name; long typeCode; }; o campo 'parameters' contém os componentes do tipo que indicam os tipos dos parâmetros. O tipo do valor devolvido é indicado no campo 'type' do MethodDef. De forma restrita, só os métodos _lookupMethod() e _interfaceName() são diferentes de objecto para objecto, enquanto que o _queryInterface() e o _queryType() são sempre os mesmos. O que são esses methodIDs? Se você fizer uma invocação de &MCOP;, irá ficar à espera de passar um número para o método que você está a invocar. A razão para tal é que os números podem ser processados muito mais depressa do que as cadeias de caracteres ao executar um pedido de &MCOP;. Por isso, como é que obtém esses números? Se você souber a assinatura do método, existe um MethodDef que descreve o método (e que contém o nome, o tipo, os nomes e os tipos de parâmetros, entre outras coisas) e você poderá passar isso ao '_lookupMethod' do objecto onde deseja invocar um método. Dado que o '_lookupMethod' está pré-associado ao 'methodID' 0, você não deverá ter problemas ao fazê-lo. Por outro lado, se você não souber a assinatura do método, você poderá descobrir os métodos que são suportados, usando o '_interfaceName', o '_queryInterface' e o '_queryType'. Os tipos de dados definidos pelo utilizador são descritos com a estrutura TypeDef: struct TypeComponent { string type; string name; }; struct TypeDef { string name; sequence<TypeComponent> contents; }; Dado que o &kde; largou o CORBA por completo e está a usar o &DCOP; em todo o lado, naturalmente a questão levantar-se-á: 'porque é que o &arts; não o faz também?'. No fim de tudo, o suporte do &DCOP; está no TDEApplication, é bem-mantido, supostamente integra-se bem com a libICE, entre outras coisas. Dado que existirá (potencialmente) uma grande quantidade de pessoas a perguntar se ter o &MCOP; para além do &DCOP; é realmente necessário, aqui está a resposta. Não levem o autor a mal, porque não está a dizer o &DCOP; é mau. Simplesmente quer dizer o &DCOP; não é a solução adequada para o &arts; (embora seja uma boa solução para outras coisas). Primeiro, você precisa de compreender para que é que o &DCOP; foi criado. Desenvolvido em dois dias durante o encontro &kde;-TWO, pretendia ser o mais simples possível, um protocolo de comunicações realmente leve. Especialmente, a implementação descartou tudo o que pudesse envolver complexidade, como por exemplo um conceito completo de como os tipos de dados seriam codificados. Ainda que o &DCOP; não se preocupe com certas coisas (por exemplo: como é que se envia uma cadeia de caracteres de forma transparente na rede?) - isso precisa de ser feito. Por isso, tudo o que o &DCOP; não faz, fica a cargo do &Qt; nas aplicações do &kde; que usam o &DCOP; hoje em dia. Isto é em grande parte gestão de tipos (usando o operador de serialização do &Qt;). Por isso, o &DCOP; é um protocolo mínimo que permite perfeitamente às aplicações do &kde; enviarem mensagens simples do tipo abrir uma janela a apontar para http://www.kde.org ou os seus dados de configuração mudaram. Contudo, dentro do &arts; o foco situa-se noutras coisas. A ideia é que alguns pequenos 'plugins' do &arts; irão comunicar, trocando algumas estruturas de dados como eventos MIDI e ponteiros de posição na música ou grafos de fluxo. Estes são tipos de dados complexos, os quais deverão ser enviados entre objectos diferentes e passados como sequências ou parâmetros. O &MCOP; fornece um conceito de tipos para definir dados complexos a partir de dados mais simples (de forma semelhante às estruturas ou vectores no C++). O &DCOP; não se preocupa com os tipos de todo, por isso este problema seria deixado para o programador - como: criar classes de C++ para os tipos, certificando-se que eles pudessem serializar-se correctamente (por exemplo: suportar o operador de transmissão do &Qt;). Mas desta forma, eles seriam inacessíveis a tudo o que não fosse codificação directa de C++. Especificamente, você não poderia desenhar uma linguagem de 'scripting' que conhecesse todos os 'plugins' de tipo que poderão estar expostos, dado que eles não se descrevem a si próprios. O mesmo argumento se aplica também às interfaces. Os objectos do &DCOP; não expõem as suas relações, hierarquias de herança, etc. - se você fosse criar um navegador de objectos que lhe mostrasse que atributos tem tido este objecto, seria mal-sucedido. Embora o Matthias tenha dito que existe uma função especial functions em cada objecto que lhe indica os métodos que um dado objecto suporta, isto deixa de fora coisas como os atributos (propriedades), as sequências e as relações de herança. Isto quebra seriamente as aplicações como o &arts-builder;. Mas lembre-se. o &DCOP; não pretendia ser um modelo de objectos (dado que o &Qt; já tem um com o moc e semelhantes), nem pretende ser algo semelhante ao CORBA, mas simplesmente uma forma de fornecer comunicação entre aplicações. Porque ainda o &MCOP; existe é: deverá funcionar perfeitamente com canais entre objectos. O &arts; faz um uso intensivo de pequenos 'plugins', que se interligam entre si com as sequências. A versão em CORBA do &arts; tinha de introduzir uma divisão muito incómoda entre os objectos SynthModule, os quais eram os módulos de trabalho internos que faziam a transmissão e a interface CORBA, que era algo externo. Muito do código preocupava-se em fazer a interacção entre os objectos SynthModule e a interface CORBA parecer natural, mas não o era, porque o CORBA não sabia nada de nada sobre as sequências. O &MCOP; sabe. Olhe para o código (algo como o simplesoundserver_impl.cc). Muito melhor! As sequências podem ser declaradas na interface dos módulos e implementadas de forma natural. Ninguém o pode negar. Uma das razões pela qual o &MCOP; foi feito foi a velocidade. Aqui estão alguns argumentos porque é que o &MCOP; será definitivamente mais rápido que o &DCOP; (sem sequer mostrar imagens). Uma invocação do &MCOP; terá um cabeçalho com seis longs. Isto é: o código do MCOP o tipo da mensagem (invocação) o tamanho do pedido em 'bytes' ID do pedido ID do objecto de destino ID do método de destino Depois disso, seguem-se os parâmetros. Repare que a descodificação destes é extremamente rápida. Você poderá usar pesquisas em tabelas para encontrar o objecto e a função de descodificação do método, o que significa que a complexidade é O(1) (levará a mesma quantidade de tempo, independentemente de quantos objectos estão vivos, ou de quantas funções existem). Comparando isto com o &DCOP;, verá que existem, pelo menos uma cadeia de caracteres para o objecto de destino - algo do tipo aMinhaCalculadora um texto do tipo adicionarNumero(int,int) para indicar qual o método muita mais informação do protocolo adicionada pela 'libICE', e outros detalhes do DCOP que o autor desconhece Tudo isto é muito doloroso para descodificar, dado que você irá necessitar de processar o texto, procurar a função, &etc;. No &DCOP;, todos os pedidos são passados através de um servidor (o DCOPServer). Isto significa que o processo de uma invocação síncrona se assemelha a: O processo do cliente envia o pedido. O DCOPserver (o homem-no-meio) recebe a invocação e procurar onde precisa de ir, enviando para o servidor real. O processo do servidor recebe a invocação, efectua o pedido e envia o resultado. O DCOPserver (o homem-no-meio) recebe o resultado e ... envia-o para o cliente. O cliente descodifica a resposta. No &MCOP;, a mesma invocação assemelha-se ao seguinte: O processo do cliente envia o pedido. O processo do servidor recebe a invocação, efectua o pedido e envia o resultado. O cliente descodifica a resposta. Digamos que ambos foram implementados correctamente, a estratégia ponto-a-ponto do &MCOP; deverá ser mais rápida por um factor de 2, do que a estratégia do 'homem-no-meio' do &DCOP;. Repare contudo que existiam razões para escolher a estratégia do &DCOP;, nomeadamente: se você tiver 20 aplicações a correr, se cada uma estiver a falar com outra, você precisa de 20 ligações no &DCOP;, e de 200 com o &MCOP;. Contudo, no caso do multimédia, isto não suposto ser a configuração normal. Tentou-se comparar o &MCOP; com o &DCOP;, fazendo uma invocação do tipo 'adicionar dois números'. Alterou-se o 'testdcop' para conseguir isto. Porém, o teste pode não ter sido fidedigno do lado do &DCOP;. Invocou-se o método no mesmo processo que fez a chamada para o &DCOP;, e não se soube como se ver livre de uma mensagem de depuração, pelo que foi feita redireccionamento do resultado. O teste só usava um objecto e uma função, esperando que os resultados do &DCOP; começassem a descer com mais objectos e funções, enquanto os resultados do &MCOP; se deveriam manter iguais. Também, o processo do dcopserver não estava ligado a nenhumas outras aplicações, pelo que, se estivessem outras aplicações ligadas, a performance do encaminhamento iria decrescer. O resultado obtido foi que, enquanto o &DCOP; obteve cerca de 2000 invocações por segundo, o &MCOP; obteve um pouco mais de 8000 invocações por segundo. Isto resulta num factor de 4. Sabe-se que o &MCOP; não está ajustado para o máximo possível, ainda. (Comparação: o CORBA, implementado no 'mico', faz algo entre 1000 e 1500 invocações por segundo). Se você quiser dados mais em bruto, pense em fazer alguma aplicação de medida de performance para o &DCOP; e envie-a para o autor. O CORBA tinha a funcionalidade interessante de que você poderia usar os objectos que você implementou uma vez, como processos de servidor separados ou como bibliotecas. Você poderia usar o mesmo código para tal, e o CORBA iria decidir de forma transparente o que fazer. Com o &DCOP;, não é realmente pretendido, e tanto quanto se sabe não é possível realmente. O &MCOP;, por outro lado, deverá suportá-lo logo desde o início. Por isso, você poderá correr um efeito dentro do &artsd;. Mas se você for um editor de ondas, você poderá optar por correr o mesmo efeito dentro do espaço do processo. Embora o &DCOP; sej, em grande medida, uma forma de comunicar entre as aplicações, o &MCOP; também o é. Especialmente para a transmissão multimédia, o que é importante (dado que você poderá correr vários objectos &MCOP; em paralelo, para resolver uma tarefa de multimédia na sua aplicação). Ainda que o o &MCOP; não o faça de momento, as possibilidades estão em aberto para implementar as funcionalidades de qualidade de serviço. Algo do género aquele evento &MIDI; é mesmo MUITO importante, em comparação com esta invocação. Ou algo do tipo necessita de estar ali a tempo. Por outro lado, a transferência de sequências poderá ser integrada no protocolo &MCOP; sem problemas e ser combinada com elementos de QoS. Dado que o protocolo poderá ser alterado, a transferência de sequências do &MCOP; não deverá ser mais lenta do que uma transmissão convencional de TCP, mas: é mais fácil e mais consistente de usar. Não existe necessidade de basear uma plataforma de multimédia no &Qt;. Ao decidir isso, e usando toda aquela serialização e outras funcionalidades giras do &Qt;, iria conduzir facilmente a que a plataforma se tornasse apenas para o &Qt; ou (para apenas para o &kde;). Quer dizer: assim que se vir que os GNOMEs comecem a usar o &DCOP;, também, ou algo do género, provavelmente o autor ficará errado. Enquanto se sabe que o &DCOP; basicamente não sabe nada sobre os tipos de dados que envia, de modo que você poderia usar o &DCOP; sem usar o &Qt;, veja como é que é usado na utilização do dia-a-dia do &kde;: as pessoas enviam tipos como o TQString, o QRect, o QPixmap, o QCString, ..., de um lado para o outro. Estes usam a serialização do &Qt;. Por isso, se alguém optar por suportar o &DCOP; num programa do GNOME, ele teria de afirmar que usava os tipos TQString,... (ainda que não o faça, de facto) e emular a forma como o &Qt; faz a transmissão, ou então teria de enviar outros tipos de cadeias de caracteres, imagens e rectângulos, o que deixaria de ter possibilidades de interoperabilidade. Bem, seja o que for, o &arts; pretendeu sempre funcionar com ou sem o &kde;, com ou sem o &Qt;, com ou sem o X11, e talvez com ou sem o &Linux; (e não há problema nenhum com as pessoas que o transpõem para um sistema operativo proprietário conhecido). É a posição do autor que os componentes não&GUI; deverão ser criados de forma independente da &GUI;, para possibilitar a partilha destes pelas quantidades maiores de programadores (e utilizadores) possível. É óbvio que o uso de dois protocolos de IPC pode causar problemas. Ainda mais, se ambos não forem normas. Contudo, pelas razões indicadas acima, a mudança para o &DCOP; não é uma opção. Se existir um interesse significativo em encontrar uma forma de unir os dois, ok, poderemos tentar. Até poderemos tentar fazer com que o &MCOP; 'fale' IIOP, onde então poderemos passar a ter um ORB de CORBA. Falou-se com o Matthias Ettrich um pouco sobre o futuro dos dois protocolos e encontraram-se montes de formas como as coisas poderão seguir daqui para a frente. Por exemplo, o &MCOP; poderia tratar da comunicação de mensagens no &DCOP;, colocando os protocolos um pouco mais juntos entre si. Por isso, algumas soluções possíveis seriam: Criar uma 'gateway' de &MCOP; - &DCOP; (o qual deverá ser possível, e possibilitaria a interoperabilidade) - nota: existe um protótipo experimentar, se quiser ver algo sobre o assunto. Integrar tudo o que os utilizadores do &DCOP; esperam no &MCOP;, e tentar apenas usar o &MCOP; - uma pessoa até poderia adicionar uma opção de homem-no-meio no &MCOP;, também ;) Basear o &DCOP; no &MCOP; em vez da 'libICE', e começar a integrar lentamente as coisas em conjunto. Contudo, poderá não ser a pior possibilidade para usar cada protocolo em tudo em que se pensou usar (existem algumas grandes diferenças nos objectivos de desenho), e não vale a pena tentar juntá-los num só.