How about it if I just store the metadata as a literal string and return it
as such for now and submit a patch to the metadata branch with that and move
on to another Jira ticket ?
Then, when we all agree on something final for the output format and
representation of message metadata we can look at further work on ESME-242.
Imtiaz
----- Original Message -----
From: "Ethan Jewett" <[email protected]>
To: <[email protected]>
Sent: Wednesday, July 21, 2010 7:01 PM
Subject: Re: Metadata handling (was "Release planning")
Imtiaz,
Excellent! That's good progress.
Any idea what the API response is still getting HTML entity-encoded?
That's what all of those < and > things are. Does the API do
this for all of its responses or is it just the metadata ones? We
probably don't need to be entity-encoding since we're returning XML,
not HTML.
Also, I just created a branch called "metadata". Can you work against
this branch and feel free to submit patches against that branch to the
Jira ticket. Vassil, Anne, or I can then apply the patches directly to
the branch without the level of review that would be needed for a
patch against trunk. This should help allow us to try out your changes
and come to consensus and understanding more quickly.
Thanks!
Ethan
On Wed, Jul 21, 2010 at 7:20 AM, Imtiaz Ahmed H E <[email protected]>
wrote:
By the way, all I did was,
in Message.scala,
replace,
lazy val metadata: String = originalXml \ "metadata" text
by...
lazy val metadata: String = (originalXml \ "metadata").toString
to get the results you see in my previous mail...
Imtiaz
----- Original Message ----- From: "Imtiaz Ahmed H E"
<[email protected]>
To: <[email protected]>
Sent: Wednesday, July 21, 2010 10:34 AM
Subject: Re: Metadata handling (was "Release planning")
Hi,
In the absence of decisive consensus yet, I made a small change in
Message.scala as a first step in fixing ESME-242.
Here's curl output for the Jira ticket examples given there by
Ethan...There is maybe obvious unacceptable stuff here, but let me
know...
imt...@imtiaz-20100131 /cygdrive/d/temp
$ curl --dump-header headers -d "token=HEZTQKM525SAMIPN4EDVRUOGHI40AKBL"
http:/
/localhost:8080/esme-server-apache-esme-1.0-RC1-incubating/api2/session
<?xml version="1.0" encoding="UTF-8"?>
<api><session><user><id>3</id><nickname>imtiaz2</nickname><image>None</image><wh
ole_name>I A 2 H E</whole_name></user></session></api>
imt...@imtiaz-20100131 /cygdrive/d/temp
$ cat headers
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=C7B688BAF8E99B2A638EF432885E310E;
Path=/esme-server-apach
e-esme-1.0-RC1-incubating
Expires: Wed, 21 Jul 2010 04:56:51 UTC
Date: Wed, 21 Jul 2010 04:56:51 GMT
Pragma: no-cache
Cache-Control: no-cache; private; no-store
X-Lift-Version: 2.0-SNAPSHOT
Content-Type: text/xml;charset=utf-8
Content-Length: 178
imt...@imtiaz-20100131 /cygdrive/d/temp
$ curl -b headers -d
'message=test200&metadata=<outer><meta><metameta>Hello</me
tameta></meta><onlymeta>Meta</onlymeta></outer>'
http://localhost:8080/esme-ser
ver-apache-esme-1.0-RC1-incubating/api2/user/messages
<?xml version="1.0" encoding="UTF-8"?>
<api><message>
<id>28</id>
<date>Wed, 21 Jul 2010 04:57:05 UTC</date>
<source>api2</source>
<body>test200</body>
<metadata><metadata><outer><meta><metameta>Hello</m
etameta></meta><onlymeta>Meta</onlymeta></outer></
metadata></metadata>
<author><nickname>imtiaz2</nickname><id>3</id></author>
<tags></tags><replyto></replyto><conversation></conversation>
</message></api>
imt...@imtiaz-20100131 /cygdrive/d/temp
$ curl -b headers -d
'message=test201&metadata=<anytag>"meta":[{"place":{"place
_type":"city","region":"CA+"}},{"song":{"artist":"Prince","songtitle":"Never+Le
t+Me+Down"}}]</anytag>'
http://localhost:8080/esme-server-apache-esme-1.0-RC1-i
ncubating/api2/user/messages
<?xml version="1.0" encoding="UTF-8"?>
<api><message>
<id>29</id>
<date>Wed, 21 Jul 2010 04:57:39 UTC</date>
<source>api2</source>
<body>test201</body>
<metadata><metadata><anytag>&quot;meta&quot;:[{&quot;p
lace&quot;:{&quot;place_type&quot;:&quot;city&quot;,&quo
t;region&quot;:&quot;CA
&quot;}},{&quot;song&quot;:{&quo
t;artist&quot;:&quot;Prince&quot;,&quot;songtitle&quot;:&
;quot;Never Let Me
Down&quot;}}]</anytag></metadata></metadata>
<author><nickname>imtiaz2</nickname><id>3</id></author>
<tags></tags><replyto></replyto><conversation></conversation>
</message></api>
imt...@imtiaz-20100131 /cygdrive/d/temp
$ curl -b headers -d
'message=test202&metadata="meta":[{"place":{"place_type":"
city","region":"CA+"}},{"song":{"artist":"Prince","songtitle":"Never+Let+Me+Dow
n"}}]'
http://localhost:8080/esme-server-apache-esme-1.0-RC1-incubating/api2/us
er/messages
<?xml version="1.0" encoding="UTF-8"?>
<api><message>
<id>30</id>
<date>Wed, 21 Jul 2010 04:58:02 UTC</date>
<source>api2</source>
<body>test202</body>
<metadata></metadata>
<author><nickname>imtiaz2</nickname><id>3</id></author>
<tags></tags><replyto></replyto><conversation></conversation>
</message></api>
imt...@imtiaz-20100131 /cygdrive/d/temp
$ curl -b headers
http://localhost:8080/esme-server-apache-esme-1.0-RC1-incubat
ing/api2/user/messages
<?xml version="1.0" encoding="UTF-8"?>
<api><messages><message>
<id>30</id>
<date>Wed, 21 Jul 2010 04:58:02 UTC</date>
<source>api2</source>
<body>test202</body>
<metadata></metadata>
<author><nickname>imtiaz2</nickname><id>3</id></author>
<tags></tags><replyto></replyto><conversation></conversation>
</message><message>
<id>29</id>
<date>Wed, 21 Jul 2010 04:57:39 UTC</date>
<source>api2</source>
<body>test201</body>
<metadata><metadata><anytag>&quot;meta&quot;:[{&quot;p
lace&quot;:{&quot;place_type&quot;:&quot;city&quot;,&quo
t;region&quot;:&quot;CA
&quot;}},{&quot;song&quot;:{&quo
t;artist&quot;:&quot;Prince&quot;,&quot;songtitle&quot;:&
;quot;Never Let Me
Down&quot;}}]</anytag></metadata></metadata>
<author><nickname>imtiaz2</nickname><id>3</id></author>
<tags></tags><replyto></replyto><conversation></conversation>
</message><message>
<id>28</id>
<date>Wed, 21 Jul 2010 04:57:05 UTC</date>
<source>api2</source>
<body>test200</body>
<metadata><metadata><outer><meta><metameta>Hello</m
etameta></meta><onlymeta>Meta</onlymeta></outer></
metadata></metadata>
<author><nickname>imtiaz2</nickname><id>3</id></author>
<tags></tags><replyto></replyto><conversation></conversation>
</message></messages></api>
imt...@imtiaz-20100131 /cygdrive/d/temp
$
----- Original Message ----- From: "Vassil Dichev" <[email protected]>
To: <[email protected]>
Sent: Tuesday, July 20, 2010 11:27 AM
Subject: Re: Metadata handling (was "Release planning")
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:
"annotations":
[{"type":{"another_attribute":"value", "attribute":"value"}}]
This comes out:
<annotations type="array">
<annotation>
<type>foo</type>
<attributes>
<attribute>
<name>bar</name>
<value>baz</value>
</attribute>
</attributes>
</annotation>
</annotations>
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:
"annotations":
[{"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">
<annotation>
<type>foo</type>
<attributes>
{"another_attribute":"value", "attribute":"value"}
</attributes>
</annotation>
</annotations>
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"
