Schreiber mit Protokollpuffer und fortgeschrittener Sparsamkeit?

Question

Ich habe hier zwei Fragen:

Frage 1:

-Kann Sparsamkeit eine Funktionalität der inneren Klasse liefern? (Siehe mein Beispiel als nächstes)

- Wenn es kann, kann die Sparsamkeit solche Funktionen leicht verwenden?

Hier ist die Schreiberschnittstelle (Scribe/if/scribe.Thrift). Aber sein Nachrichtenfeld kann nur eine Zeichenfolge sein, von der ich glaube, dass sie nicht flexibel genug ist.

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

Es wäre großartig, wenn ich das Folgende machen kann (ich weiß nicht einmal, ob Thrift selbst die Funktionalität der inneren Klasse gemäß seinem Dokument liefert-aber Protokollpuffer kann es definitiv kann).

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

---

Frage 2:

- Kann Schreiber Protokollpuffer wie die interne Datendarstellung leicht verwenden? (ohne zu viel Codeänderung)

-Wenn die Antwort auf die obige Frage "Nein" lautet, hat Google Open-Source seine Sribe-Implementierung?

Answer 1

Ja, Sparsamkeitsstrukturen können andere Strukturen umfassen, und Ihre Definition (wiederholte folgende) würde funktionieren:

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

Wenn Sie die Schnittstellen von Scribe wie diese neu definiert haben, müssten Sie wahrscheinlich den Code von Scribe ändern, um Ihren neuen Typ zu verarbeiten, je nachdem, was er intern macht string message.

Natürlich könnten Sie Ihre immer serialisieren MyLogStructure Objekt gegen eine Zeichenfolge und vermeiden Sie dieses Problem insgesamt.

Nein, ich kann mir nicht vorstellen, dass Schreiber in der Lage sein würde, Protokollpuffer als die interne Datendarstellung leicht zu verwenden. Der gesamte RPC -Code wurde aus diesen Definitionen generiert, und Sie könnten die neu definieren Log Methode zur Einnahme eines willkürlichen Objekts (beispielsweise ein Protokollpufferobjekt), aber dies wäre genauso schwierig wie die oben genannten.

Meines Wissens hat Google kein verteiltes Protokollierungssystem offen geöffnet. Chukwa Von Yahoo/Hadoop ist eine Alternative.