tracer avec du tampon de protocole et d'économie de pointe?

Question

J'ai deux questions ici:

Question 1:

- peut Thrift fournir une fonctionnalité de classe interne? (Voir mon exemple suivant)

- si elle peut, peut utiliser cette fonctionnalité Thrift facilement

Voici l'interface scribe (scribe / if / de scribe.thrift). Mais son champ de message ne peut pas être une chaîne, que je crois pas assez souple.

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

Ce serait bien si je peux faire la chose suivante (je ne sais même pas si Thrift lui-même fournit la fonctionnalité de classe interne en fonction de son tampon document-- mais le protocole peut certainement).

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

---

Question 2:

- Peut tracer utiliser le tampon de protocole que la représentation interne des données facilement? (Sans trop de modification du code)

- Si la réponse à la question ci-dessus est "non", a fait Google open source de sa mise en œuvre sribe

Answer 1

Oui, Thrift struct peuvent inclure d'autres struct, et votre définition (actes répétés) travaillerait:

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 vous redéfinissez les interfaces de Scribe comme ça, vous auriez probablement modifier le code de Scribe pour gérer votre nouveau type en fonction de ce qu'il fait en interne avec string message.

Bien sûr, vous pouvez toujours sérialiser votre objet MyLogStructure à une chaîne et d'éviter ce problème tout à fait.

Non, je ne pense pas Scribe serait en mesure d'utiliser Buffers Protocole comme représentation interne des données facilement. Tout le code RPC a été généré à partir de ces définitions, et vous pourriez redéfinir la méthode Log pour prendre un objet quelconque (le faire, par exemple, un objet Protocol Buffers), mais ce serait tout aussi difficile que ci-dessus.

A ma connaissance Google n'a pas open source tout système d'enregistrement distribué. Chukwa de Yahoo / Hadoop est une alternative.