esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vassil Dichev <>
Subject Re: Metadata handling (was "Release planning")
Date Tue, 20 Jul 2010 05:57:19 GMT
> I'd prefer option 1 (separate attribute from text). Within this
> separate attribute there is the question of how data is
> stored/represented. I'm ok with either raw string or a tuple-based
> structure like Twitter's. I kind of like the tuple (key-value)
> approach.

I'm not too interested in how the data is stored, because it's fairly
trivial to implement either way. It's currently not yet clear to me
what the requirements for the output format are.

> What I'm insisting on and what I was saying we got wrong is that what
> goes in needs to be the same as what comes out. If it's tuple-based
> and I send in a tuple, then I should get that tuple (key and value)
> back out when I request the metadata for a message. Right now I think
> we only get a concatenated list of values from the metadata and
> metaData methods and we're bound to an XML format.

I don't get it. A tuple is an abstraction which might be expressed in
a specific format. So what goes in is not what comes out depending on
the format. Let me quote the specific example Twitter provides.

This comes in:

    [{"type":{"another_attribute":"value", "attribute":"value"}}]

This comes out:

<annotations type="array">

> As far as requiring a particular format, I think the internal format
> should be either a raw string or a immutable hashmap with raw strings
> as keys and values. We can handle converting this to XML or JSON in
> the API or view code.

Again, it's not so interesting what's internally there, let's just
treat it as a black box. What I want to know is, do we want to have
for instance XML in a JSON reply returned:

    [{"type":{"<attributes> <attribute> <name>bar</name>
<value>baz</value> </attribute> </attributes>"}}]

or, inversely, do we want JSON inside an XML reply? Something like:

<annotations type="array">
      {"another_attribute":"value", "attribute":"value"}

because the latter will need to be escaped.

Sorry for being too dense, but in any case, we either have to escape
the metadata or we have to transform the structure to XML/JSON when we
return it back to the user. None of these is "what goes in needs to be
the same as what comes out"

View raw message