Hey Doug, following up, but realize you are likely very busy at the
summit :)
On 11/04/2013 10:20 PM, Doug Hellmann wrote:
On Tue, Nov 5, 2013 at 10:37 AM, Jay Pipes <[email protected]
The "models" defined in WSME are completely different from the
database
models, and should not be used outside of the API code. Think of
them as
declaring the models for the consumer of the API, rather than the
implementer of the API.
I don't really see the point of the distinction. At the end of the
day, the consumer of the API is using the API to manipulate and
retrieve data. That data is really the model, with some syntactic
sugar like Atom links, etc. Even in a control API -- as opposed to a
data API like Glance, Ceilometer or Swift -- the benefits of a heavy
API layer like Pecan and WSME are pretty small, IMO.
That approach binds your API tightly to the database representation,
which we were trying to avoid.
I wasn't referring to the database representation, actually. I was
referring to the data model, which is different in that it abstracts
away any underlying schema or storage engine...
I would much rather see the Ceilometer models [1] actually be models
that can validate the data that is used to construct the model
object instead of having duplicated WSME "models" repeated in the
WSGI controller code [2]. The reason is because if/when I decide to
make a Ceilometer API that uses a different protocol, say AMQP,
instead of HTTP, now I need to duplicate all of the validation code
that WSME is providing on the data model layer... however if the
validation was in the models themselves, I could easily create an
API on a different protocol using just the models for validation.
We do that in some cases. However, there is also a difference in some
cases between the validation at the API layer (a value must be a number,
or a UUID, etc.) and the validation in the database layer (a number must
fall within a range or a UUID must refer to an existing object). So
there is a place for both, and the validation done in the WSME classes
is not meant to be the only validation performed.
OK, understood.
The benefits of declaring WSME classes include automatic
serialization
in JSON and XML, generating WADL files to be included in the API
docs
(work is already happening to make this available for everyone), and
consistent input and output types for API endpoints (making it
easier
for consumers of the API to use it and for implementers to validate
inputs and assume consistent defaults).
I can't stand XML. I believe it should be retired to the dustbin of
coding history, like Basic.
You've made that clear in the past. :-) I agree, for what it's worth.
Some of our users do seem to want it, and with WSME *you don't have to
care*.
Also understood. :)
That said, consumers of a RESTful API don't care how the API is
implemented. They care that it's documented and consistent, and if
WSME makes API documentation easier, then that's A Good Thing, agreed.
It's true that WSME includes some stuff to make validating inputs
"easier", but it does so, IMHO, at the expense of readability
because everything is decorated and hidden away somewhere other than
the models themselves. See note above...
I'm not sure what that means. Hidden where? The validation is either
described in the attribute specifier for the model, or in the model's
class, or in the controller (depending on the scope of the rule being
applied).
Sorry, "hidden" wasn't the best word to describe that. I meant more
"it's less obvious to folks who expect to find validation of the data
model at the data model layer" :)
And, to be clear, Pecan and WSME are integrated by Pecan can
definitely
be used without WSME. I included WSME in the proposal to replace the
home-grown WSGI framework because I thought it added significant
benefits, but it is not going to be appropriate for all situations
(streaming large image files is one example).
Yes, in one way it's a bit unfortanate that we're now comparing Falcon
with Pecan + WSME as opposed to just comparing Falcon with Pecan and
then evaluating whether WSME should be used (on top of either one...).
It's unfortunate because we've spent all this email thread actually
talking about WSME and not much at all about Pecan ;)
Here's a third reason I don't care for Pecan/WSME: it uses Webob.
Other than eventlet, I don't know of a single library that OpenStack
projects have used over the years that we've had more issues with
than Webob.
Yes, I felt the pain of updating us to the latest WebOb. The project has
evolved since those days, and the current maintainers are committed to
not breaking the API. That new attitude, combined with the long history
of addressing edge cases from misbehaving web client libraries makes m e
less reluctant to use WebOb than in the past.
OK, that's good to hear. However, I remain guarded and
pessimistic...it's my nature I suppose :)
Secondly, it is the sign of strength that a contributor community
consider -- and continually consider -- alternative libraries or
implementations of various things. Change is good, and projects that
are just starting off are a good place to experiment with newer
libraries and see if something is better than what existed
previously. I seem to remember that was your position on Pecan when
the community was considering whether to standardize on some WSGI
pipeline. Why didn't you just use what was in other projects instead
of Pecan and WSME? Likely the same reasons that I'm saying "let's
give Falcon a chance".
My main arguments were "do not build something new from scratch when
there are working tools" and "the existing library is too hard to use".
We can argue about whether Falcon or Pecan solves the second issue
better, but Pecan was used in production deployments far earlier than
Falcon even existed.
Yes, that is a very fair point.
I suppose at the end of the day, a lot of this does come down to
personal preference/opinion for me. I just prefer the style of Falcon
over Pecan. That said, I'm a community member that does not wish to see
Solum's early pace slowed down just because I personally prefer a
different library! So, I'll back down if the direction that the Solum
contributors want to take is to go with Pecan. I'll still likely bitch
and moan about WSME though... :P
Best,
-jay
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
