Return-Path: Delivered-To: apmail-incubator-esme-dev-archive@minotaur.apache.org Received: (qmail 29483 invoked from network); 21 Jul 2010 05:21:17 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 21 Jul 2010 05:21:17 -0000 Received: (qmail 56318 invoked by uid 500); 21 Jul 2010 05:21:16 -0000 Delivered-To: apmail-incubator-esme-dev-archive@incubator.apache.org Received: (qmail 56253 invoked by uid 500); 21 Jul 2010 05:21:14 -0000 Mailing-List: contact esme-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: esme-dev@incubator.apache.org Delivered-To: mailing list esme-dev@incubator.apache.org Received: (qmail 56245 invoked by uid 99); 21 Jul 2010 05:21:14 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Jul 2010 05:21:14 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FAKE_REPLY_C,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of in.imtiaz@gmail.com designates 209.85.160.47 as permitted sender) Received: from [209.85.160.47] (HELO mail-pw0-f47.google.com) (209.85.160.47) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Jul 2010 05:21:04 +0000 Received: by pwi10 with SMTP id 10so2755981pwi.6 for ; Tue, 20 Jul 2010 22:20:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:subject :date:mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:x-mailer:x-mimeole; bh=MDu/YR70tppDeHLRagBwo9GNTGDaRqVh5wfUFuVzHK0=; b=A/G5haJbcrOp3c3SxjTtnuY4XgwX4j9SYdiXfL0wKWE6C5xKMc6ylhamOtWl4X606a 9E9sJw5fyGsjdJ9h9KGkO1pRBq3LEHT/KJJ3Pjea0a5syc+hMg9Rs3cr32jovP85tFVg yN69fILEXXk+KpkL/Nk5UNJJGPQ90w8U7bl/Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:mime-version:content-type :content-transfer-encoding:x-priority:x-msmail-priority:x-mailer :x-mimeole; b=oVLk3ufKgsNmahJhYVN6gbHCoCoYyRkRxRM51/NHEyxRjuIhWH6lFFxz5ZdU1OM3yu Y+FSbksUd1bWjcigRw6dtpQVBFV8eBwpBXVjbkqBcuUeSp3zI3bMsbgSW00c4GjBMfzJ iSvm3zf2sHPlbFSd+ydYu6yT60SY7U1jjUllw= Received: by 10.142.204.17 with SMTP id b17mr10520557wfg.71.1279689643030; Tue, 20 Jul 2010 22:20:43 -0700 (PDT) Received: from imtiaz20100131 ([122.171.4.127]) by mx.google.com with ESMTPS id 33sm8634720wfg.9.2010.07.20.22.20.40 (version=SSLv3 cipher=RC4-MD5); Tue, 20 Jul 2010 22:20:42 -0700 (PDT) Message-ID: <386EE54BF3C4414A9F637165C0ED9F8B@imtiaz20100131> From: "Imtiaz Ahmed H E" To: Subject: Re: Metadata handling (was "Release planning") Date: Wed, 21 Jul 2010 10:50:36 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Virus-Checked: Checked by ClamAV on apache.org 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" To: 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... > > imtiaz@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 > > 3imtiaz2None ole_name>I A 2 H E > > imtiaz@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 > > > imtiaz@imtiaz-20100131 /cygdrive/d/temp > $ curl -b headers -d > 'message=test200&metadata=Hello tameta>Meta' > http://localhost:8080/esme-ser > ver-apache-esme-1.0-RC1-incubating/api2/user/messages > > > 28 > Wed, 21 Jul 2010 04:57:05 UTC > api2 > test200 > > <metadata><outer><meta><metameta>Hello</m > etameta></meta><onlymeta>Meta</onlymeta></outer></ > metadata> > imtiaz23 > > > > imtiaz@imtiaz-20100131 /cygdrive/d/temp > $ curl -b headers -d > 'message=test201&metadata="meta":[{"place":{"place > _type":"city","region":"CA+"}},{"song":{"artist":"Prince","songtitle":"Never+Le > t+Me+Down"}}]' > http://localhost:8080/esme-server-apache-esme-1.0-RC1-i > ncubating/api2/user/messages > > > 29 > Wed, 21 Jul 2010 04:57:39 UTC > api2 > test201 > > <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> > > imtiaz23 > > > > imtiaz@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 > > > 30 > Wed, 21 Jul 2010 04:58:02 UTC > api2 > test202 > > imtiaz23 > > > > imtiaz@imtiaz-20100131 /cygdrive/d/temp > $ curl -b headers > http://localhost:8080/esme-server-apache-esme-1.0-RC1-incubat > ing/api2/user/messages > > > 30 > Wed, 21 Jul 2010 04:58:02 UTC > api2 > test202 > > imtiaz23 > > > 29 > Wed, 21 Jul 2010 04:57:39 UTC > api2 > test201 > > <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> > > imtiaz23 > > > 28 > Wed, 21 Jul 2010 04:57:05 UTC > api2 > test200 > > <metadata><outer><meta><metameta>Hello</m > etameta></meta><onlymeta>Meta</onlymeta></outer></ > metadata> > imtiaz23 > > > > imtiaz@imtiaz-20100131 /cygdrive/d/temp > $ > > ----- Original Message ----- > From: "Vassil Dichev" > To: > 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: >> >> >> >> foo >> >> >> bar >> baz >> >> >> >> >> >> >>> 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":{" bar >> baz "}}] >> >> or, inversely, do we want JSON inside an XML reply? Something like: >> >> >> >> foo >> >> {"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" >