Cool. I was wondering why some things were added into brubeck.io. Does
the planned work include better decorators. For instance in bottle.py I
can do things like:
@app.get('/mypath/<arg1>/<whatever>)
def do_it(arg1, whatever):
pass
and it just works. Currently in brubeck I would have to make my own reqex
to split out the arguments as I understand it and the one wrapper requires
the function to have a couple of extra arguments. Or did I miss an easier
way to do a simple wrapped function implementation for a message pattern?
I know about subclassing brubeck classes but it seem a bit of hassle to
create a bunch of classes for it too.
I am being tempted to lift the relevant bottle implementation code and
paste it in to brubeck.io implementation.
Am I missing a better way?
- samantha
On Thu, Sep 19, 2013 at 1:36 PM, James Dennis <[email protected]> wrote:
> Hello.
>
> Brubeck actually offers the function decorators too.
>
> I am the author of Brubeck. The team and I have decided that we need to
> change some things over there, but we felt we should start with Schematics.
> We are wrapping that work up and will be dusting off Brubeck after.
>
> We intend to do a few things. First, we're going to remove the dependency
> on just about everything, except for some concurrency choice. That means
> we'll remove the dependency on Schematics. This implies the querysets will
> be removed too, which is what started the Tobin project. The Querysets
> will be in Tobin instead, and Tobin can be described as a data layer for
> Schematics.
>
> From that point, Brubeck is basically gevent + mongrel2. WSGI is
> supported, but not well documented.
>
> I realize Brubeck hasn't been active lately. We are gearing up to pick
> things up again. I am certainly to blame for most of this. I started a
> new company and it took some time to adjust and figure out how to keep
> active development in my day.
>
> I am interested in hearing opinions. I want to make Brubeck very lean and
> have clearly defined paths for doing things rather than trying to support
> many methods of the same thing. For example, Brubeck does support the
> decorators, but it generally learns towards using classes. Not only have I
> seen this perform about 33% faster, I much prefer simple functions for
> everything over classes.
>
> If you find you prefer something else, so be it. I apologize for the
> current unclear status of the project.
>
> James
>
>
> On Thu, Sep 19, 2013 at 4:21 PM, Samantha Atkins <[email protected]>wrote:
>
>> I have a fairly substantial in-house python web app. I used bottle.py in
>> development to get something up and running quickly to flesh out all the
>> functionality. I am looking at mongrel2 for deployment server.
>>
>> I have been looking at brubeck.io for a few days. I see how to make it
>> work but I am not overly enamored of the way it does things. In particular
>> its routing mechanism to a class or a wrapped function are less friendly
>> than the function decorators provided by bottle.py.
>>
>> I am also a tiny bit concerned that there is very little geek traffic I
>> can find on brubeck.io that was not project internally generated.
>>
>> Is there something better? Does it make sense to just roll my own. I
>> don't need thinks in brubeck.io like its auth helpers or db
>> connectivity. I already have those things covered in the existing code
>> base. (mongrel2 with custom limited orm-ish stuff for db).
>>
>> Recommendations? Opinions?
>>
>> thanks!
>>
>> - samantha
>>
>
>
