Escriba com buffer de protocolo e economia avançada?

Question

Eu tenho duas perguntas aqui:

Questão 1:

-A Thrift pode fornecer uma funcionalidade de classe interna? (Veja meu exemplo a seguir)

- Se puder, a economia pode usar essa funcionalidade facilmente?

Aqui está a interface do Scribe (Scribe/If/Scribe.Thrift). Mas seu campo de mensagem pode ser apenas uma corda, o que acredito que não é flexível o suficiente.

#!/usr/local/bin/thrift --cpp --php

##  Copyright (c) 2007-2008 Facebook
...
...
## See accompanying file LICENSE or visit the Scribe site at:
## http://developers.facebook.com/scribe/

include "fb303/if/fb303.thrift"

namespace cpp scribe.thrift

enum ResultCode
{
  OK,
  TRY_LATER
}

struct LogEntry
{
  1:  string category,
  2:  string message
}

service scribe extends fb303.FacebookService
{
  ResultCode Log(1: list<LogEntry> messages);
}

Seria ótimo se eu pudesse fazer a seguinte coisa (eu nem sei se a própria Thrift fornece a funcionalidade da classe interna de acordo com seu documento-mas o buffer de protocolo definitivamente pode).

enum ResultCode
{
  OK,
  TRY_LATER
}

struct MyLogStructure {
  1: string field_name;
  2: string value;
}

struct LogEntry
{
  1:  string category,
  2:  MyLogStructure message
}

service scribe extends fb303.FacebookService
{
  ResultCode Log(1: list<LogEntry> messages);
}

---

Questão 2:

- O Scribe pode usar o buffer de protocolo como a representação de dados interna facilmente? (sem muita modificação de código)

-Se a resposta para a pergunta acima é "não", o Google de código aberto da implementação do SRIBE?

Answer 1

Sim, as estruturas de economia podem incluir outras estruturas, e sua definição (seguidores repetidos) funcionaria:

enum ResultCode { OK, TRY_LATER }

struct MyLogStructure {
  1: string field_name;
  2: string value;
}

struct LogEntry {
  1: string category,
  2: MyLogStructure message 
}

service scribe extends fb303.FacebookService {
  ResultCode Log(1: list messages);
}

Se você redefiniu as interfaces do Scribe como essa, provavelmente teria que modificar o código do Scribe para lidar com seu novo tipo, dependendo do que ele faz internamente com string message.

Claro, você sempre pode serializar em serializar seu MyLogStructure Objeta -se a uma string e evite completamente esse problema.

Não, não imagino que o Scribe seria capaz de usar buffers de protocolo como sua representação de dados internos facilmente. Todo o código RPC foi gerado a partir dessas definições, e você pode redefinir o Log Método para tomar um objeto arbitrário (faça, digamos, um objeto de buffers de protocolo), mas isso seria tão difícil quanto o acima.

Que eu saiba, o Google não foi de código aberto nenhum sistema de registro distribuído. Chukwa Do Yahoo/Hadoop é uma alternativa.