Mailing-List: contact esme-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: esme-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of hirsch.dick@gmail.com
 designates 216.239.58.188 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=s7o5UzOGVTw/Q12Ab7IEX7y6UzG8Msu/wsiQRCEIHd0jXG6SKp0Vce/nr5DTVcs+DS
         VLaSa/dMEhmLbzqstyzgfOwSiLSOUGSXu+YDm/CR7YnYf4iV8zb96nz02Z/qqYF1nTP2
         3c/IS5psacngzlKNYfeopvyhblHPaS+LV/z30=
MIME-Version: 1.0
In-Reply-To: <68f4a0e80910290751i213585b0i132d2d81cb52149c@mail.gmail.com>
References: <68f4a0e80910251728te9c1248j10f1aa99c9f7cd2e@mail.gmail.com>
	 <fa2d9f450910260009g111c7cc1yfa8fdf5093cc2736@mail.gmail.com>
	 <fa2d9f450910270041r7abe9bdbq1cd106131d6ae977@mail.gmail.com>
	 <68f4a0e80910270917r408588fbva0f47e73125afa4d@mail.gmail.com>
	 <fa2d9f450910290719x36f0ae9bh456ec3e44aadec1c@mail.gmail.com>
	 <68f4a0e80910290751i213585b0i132d2d81cb52149c@mail.gmail.com>
Date: Thu, 29 Oct 2009 15:58:17 +0100
Message-ID: <fa2d9f450910290758i7e940a87yf57e199b15e1b041@mail.gmail.com>
Subject: Re: Patch submitted, working towards API design
From: Richard Hirsch <hirsch.dick@gmail.com>
To: esme-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1

Looking forward to seing the next version. I'll do a deplyoment after
I see the code updated in Jira.

D.

On Thu, Oct 29, 2009 at 3:51 PM, Ethan Jewett <esjewett@gmail.com> wrote:
> I'm hoping to be able to expand on that this weekend a bit. I'm
> updating http://cwiki.apache.org/confluence/display/ESME/API+2.0+-+Design
> to keep track a bit, and if people want more resources in the API they
> should add them there (and discuss on this list).
>
> Currently Tags have been left out, Searches are an item that we might
> want to add, and there are no stream-based interfaces to message
> queues, which I now agree are very important. Lots of work to do there
> :-) I'll try to get this stuff written up and into Jira over the
> weekend.
>
> Ethan
>
> On Thu, Oct 29, 2009 at 10:19 AM, Richard Hirsch <hirsch.dick@gmail.com> wrote:
>> I've committed the changes - what is missing in the API?
>>
>> D.
>>
>> On Tue, Oct 27, 2009 at 5:17 PM, Ethan Jewett <esjewett@gmail.com> wrote:
>>> This is working on Stax!
>>>
>>> On Tue, Oct 27, 2009 at 3:41 AM, Richard Hirsch <hirsch.dick@gmail.com> wrote:
>>>> The new api is deployed on stax.
>>>>
>>>> D.
>>>>
>>>> On Mon, Oct 26, 2009 at 8:09 AM, Richard Hirsch <hirsch.dick@gmail.com> wrote:
>>>>> I don't see any probs with putting this in the trunk. The existing
>>>>> rest api remains unchanged.
>>>>>
>>>>> D.
>>>>>
>>>>> On Mon, Oct 26, 2009 at 1:28 AM, Ethan Jewett <esjewett@gmail.com> wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> This has been cooking for a little while (I think it was about 6 month
>>>>>> ago that I mentioned I should put my money/code where my mouth was),
>>>>>> but I finally submitted a patch for the ESME-14 Jira issue
>>>>>> (https://issues.apache.org/jira/browse/ESME-14). This patch creates a
>>>>>> new branch called "new_api". The sole purpose of this branch is to
>>>>>> create a new API endpoint /api2/ where we can start converting the API
>>>>>> to a format that aligns with discussions occurring on the wiki
>>>>>> (http://cwiki.apache.org/confluence/display/ESME/API+2.0+-+Design).
>>>>>>
>>>>>> The current diff has a working API at /api2/ that has pretty much the
>>>>>> same methods as the old one (I just copied them after all), but
>>>>>> arranged in the resource/object hierarchy outlined on the wiki. I've
>>>>>> also moved some parameters out of the query (part of the URL after the
>>>>>> ?) and into the path of the URL, when these parameters actually refer
>>>>>> to resources/objects.
>>>>>>
>>>>>> The diff should actually exist nicely alongside the existing API and
>>>>>> functionality, but I figured the easiest and safest way to get it in
>>>>>> initial was in a branch.
>>>>>>
>>>>>> Here's what I'm looking at doing next, not necessarily in this order:
>>>>>>
>>>>>> 1. Create new handlers to fill out the object/resource hierarchy
>>>>>> 2. Fix up the existing code in the API2.scala file so that it all
>>>>>> behaves the same way
>>>>>> 3. Work on aligning and documenting the naming of parameters that API
>>>>>> handlers expect
>>>>>> 4. Work on accepting XML or JSON representations of new or changed
>>>>>> resources, rather than using query parameters
>>>>>> 5. Write tests/specs (I'm working on figuring out how to do this. Any
>>>>>> pointers on how to make an HTTP request from Scala/Lift would be
>>>>>> extremely helpful, as I think this is level at which I need to test
>>>>>> the API.)
>>>>>>
>>>>>> See the wiki page for longer-term discussions and approaches.
>>>>>>
>>>>>> Any comments or questions? I've got to note that this is the first
>>>>>> Scala I've ever written (though truly, it's mostly copied and adjusted
>>>>>> at this point) outside of examples from books, so please please please
>>>>>> tell me how I should be doing things differently.
>>>>>>
>>>>>> Thanks,
>>>>>> Ethan
>>>>>>
>>>>>
>>>>
>>>
>>
>