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" >> > >
