Mailing-List: contact esme-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: esme-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of esjewett@gmail.com designates
 209.85.220.224 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:content-transfer-encoding;
        b=WuAHE9QmwJ30837lXkH2KfRJsjzEUVWNlb8PPh2AVjIRYJv0TkoLupZ6GxlUxU65au
         SLcDWc5XE7hiBVfM0jlQ5bB97dNKZUxs0HPPcIHZot9AW8Tu+wM90y0DQT0Ju3tdbRBq
         S75uv5otUuwVQMXm4Xc61HM65ojDoDxkaQ2HM=
MIME-Version: 1.0
In-Reply-To: <c7fc82820908031420s7a95bb62o58488b052ed678ed@mail.gmail.com>
References: <68f4a0e80908020845s6607d2e6y2eb64d193e6fac5f@mail.gmail.com>
	 <c7fc82820908022344v3d6ad906y1c16d561d1ed4e67@mail.gmail.com>
	 <68f4a0e80908030829h764ed714v57f168bfab88ab60@mail.gmail.com>
	 <c7fc82820908031420s7a95bb62o58488b052ed678ed@mail.gmail.com>
Date: Mon, 3 Aug 2009 18:26:26 -0400
Message-ID: <68f4a0e80908031526l44712f56q50c118dcc0f85bd5@mail.gmail.com>
Subject: Re: Current REST-API - Sessions
From: Ethan Jewett <esjewett@gmail.com>
To: esme-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Mon, Aug 3, 2009 at 5:20 PM, Vassil Dichev<vdichev@apache.org> wrote:
> Noted. Maybe it's not even on the old page, but in a mail somewhere in
> the old mailing list, which I agree is next to useless.

I'd be interested to see whatever we have. Nothing comes up when I
google the old esme-dev google group, but maybe someone has something
somewhere. I checked the old REST API documentation page and didn't
see anything. Do you think I would be able to figure it out from
looking at the source code?

>
> I'm sorry if it sounded like I'm disparaging your efforts to stick to
> the REST principles- I didn't mean to. I just recalled that the "whole
> RPC vs. REST uproar" was caused by a guy who had some valid points but
> in the end wasn't aware of how ESME works and the reasons it's
> designed this way. So if I was a bit bitter, it was because of this
> case when someone jumps to conclusions and condemns ESME as being all
> wrong because we called it REST instead of RESTful or REST-like.
> Sheesh...

That guy may have been me. I'm slowly having it explained to me that
the design principles of ESME don't necessarily match up to the design
principles of HTTP and to a certain extent REST. You'll have to bear
with me as I work through the cognitive dissonance of an HTTP
(document-focused) API to a stream-focused tool. :-)

At root I think the issue is that we are talking about an HTTP
programming interface to a tool that is conceived in a way that is
totally different from HTTP. An interesting problem, and one that I
had not realized existed until now. I think it would be nice to
provide a way to expose all ESME objects as traditional HTTP resources
in a RESTful manner, but I need to go back to the drawing board to
think about whether this is even reasonable.

> Let us know about the use case (what do you want to achieve?), so we
> are better prepared to help. If it's not in the Twitter API, then it
> must be pretty specific to ESME. What are you trying to use- actions,
> pools, tagclouds, tracking...?

What I'd like to do is expose as much of the ESME API as possible
through YQL. I'm not sure this is always going to be reasonable, but
I'd like to do it anyway, both as an exercise, and to make ESME more
mashable and exposed to possible use-cases we had not thought of
before. I'm specifically looking to make the ESME API accessible
through Yahoo! Pipes and through Webhook interfaces. A YQL wrapper
should make this possible with relatively little effort.

> For me the takeaway point of the rant was that we shouldn't try to fit
> everything into a mold. Not all apps should conform completely to a
> design pattern at all costs. One should understand the underlying
> reasons for sticking to a best practice before trying to apply it
> everywhere, otherwise one might be trying to fit square pegs into
> round holes. What this means for ESME- it's fine to use some of the
> advice regarding REST, but the prescription that all interaction is
> stateless doesn't fit with ESME, where state is important and is
> central to the application design.
>
> Maybe as a result of this old discussion we should have outlined the
> things that we can do to improve things and stuff that we are not
> going to change, because it doesn't make sense. This way there should
> be no false expectations regarding what we wanted to do.

I think what is most helpful is that exceptions have justifications
that are documented unemotionally somewhere accessible. I had not
understood the idea of ESME as stream-based until today due to this
conversation with you and another offline conversation with David. I
now realize that I had seen these very same justifications written
about multiple times before, but never in a way I personally could
understand. Hopefully on my next flight I'll be able to write a blog
and/or wiki page on the topic that may help out others with this
problem in the future.

Thanks for taking the time to work with me on this!

Ethan