писец с протокольным буфером и продвинутой бережливостью?

Question

Здесь у меня есть два вопроса:

Вопрос 1:

-- может ли thrift обеспечить функциональность внутреннего класса?(смотрите мой пример далее)

-- если это возможно, может ли thrift легко использовать такую функциональность?

Вот интерфейс scribe (scribe/if/scribe.thrift).Но его поле сообщения может быть только строковым, что, на мой взгляд, недостаточно гибко.

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

Было бы здорово, если бы я мог сделать следующее (я даже не знаю, обеспечивает ли сам thrift функциональность внутреннего класса в соответствии со своим документом, но protocol buffer определенно может).

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

---

Вопрос 2:

-- Может ли scribe легко использовать protocol buffer в качестве внутреннего представления данных?(без особых изменений кода)

-- Если ответ на вышеприведенный вопрос "нет", открыла ли Google исходный код для реализации sribe?

Answer 1

Да, структуры бережливости могут включать в себя другие структуры, и ваше определение (повторенное ниже) будет работать:

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

Если бы вы переопределили интерфейсы Scribe подобным образом, вам, вероятно, пришлось бы модифицировать код Scribe для обработки вашего нового типа в зависимости от того, с чем он работает внутри string message.

Конечно, вы всегда можете сериализовать свой MyLogStructure возразите против строки и вообще избегайте этой проблемы.

Нет, я не думаю, что Scribe смог бы легко использовать буферы протокола в качестве своего внутреннего представления данных.Весь код RPC был сгенерирован на основе этих определений, и вы могли бы переопределить Log метод, позволяющий взять произвольный объект (сделать его, скажем, объектом буферов протокола), но это было бы так же сложно, как и вышеописанное.

Насколько мне известно, у Google нет какой-либо распределенной системы ведения журнала с открытым исходным кодом. Чуква из Yahoo / Hadoop - одна из альтернатив.