On 11/07/2013 07:28 AM, Jay Pipes wrote:
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 <jaypi...@gmail.com

        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

Jay,

+1

This is a great point. Best for new projects to focus on key problems in their mission, rather then dealing with dependency management which can always be addressed later as some OpenStack programs like nova are doing in their planned migration for Icehouse.

Regards
-steve

Best,
-jay

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to