escriba con tampón de protocolo y ahorro avanzado?

Question

Tengo dos preguntas aquí:

Pregunta 1:

-¿Puede la ahorro proporcionar una funcionalidad de clase interna? (Vea mi ejemplo a continuación)

- Si puede, ¿puede el ahorro usar tal funcionalidad fácilmente?

Aquí está la interfaz de escriba (escriba/if/scribe.thrift). Pero su campo de mensaje solo puede ser una cadena, que creo que no es lo suficientemente flexible.

#!/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);
}

Sería genial si puedo hacer lo siguiente (ni siquiera sé si Thrift en sí mismo proporciona la funcionalidad de clase interior de acuerdo con su documento, pero el búfer de protocolo definitivamente puede).

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);
}

---

Pregunta 2:

- ¿Puede el búfer de protocolo de escribas de escriba como la representación de datos internos fácilmente? (sin demasiada modificación del código)

-Si la respuesta a la pregunta anterior es "No", ¿Google Open-Source su implementación SRIBE?

Answer 1

Sí, las estructuras de segunda mano pueden incluir otras estructuras, y su definición (seguimiento repetido) funcionaría:

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);
}

Si redefinió las interfaces de Scribe como esta, probablemente tendrá que modificar el código de Scribe para manejar su nuevo tipo dependiendo de lo que haga internamente con string message.

Por supuesto, siempre puedes serializar tu MyLogStructure Objeto a una cadena y evite este problema por completo.

No, no me imagino que Scribe pueda usar búferes de protocolo como su representación de datos internos fácilmente. Todo el código RPC se ha generado a partir de estas definiciones, y podría redefinir el Log Método para tomar un objeto arbitrario (hazlo, por ejemplo, un objeto de protocolo de amortiguación) pero esto sería tan difícil como lo anterior.

Que yo sepa, Google no ha obtenido ningún sistema de registro distribuido. Chukwa De Yahoo/Hadoop es una alternativa.