On 02/18/2015 05:56 PM, Rafael Schloming wrote:
On Wed, Feb 18, 2015 at 11:18 AM, Gordon Sim wrote:
On 02/18/2015 03:44 PM, Rafael Schloming wrote:
I can't speak to the logic, but I believe the use of contrib to signal
pretty much *exactly* what we are talking about here is a pretty common
c
On Wed, Feb 18, 2015 at 10:53 AM, Justin Ross wrote:
> On Wed, Feb 18, 2015 at 9:28 AM, Rafael Schloming
> wrote:
>
> > A couple of comments in no particular order...
> >
> > The "Core user model and uitility classes" description could be
> > misinterpreted on a quick read. Maybe go with "Core p
On Wed, Feb 18, 2015 at 10:53 AM, Justin Ross wrote:
>
>
> On Wed, Feb 18, 2015 at 9:28 AM, Rafael Schloming
> wrote:
>
>> A couple of comments in no particular order...
>>
>> The "Core user model and uitility classes" description could be
>> misinterpreted on a quick read. Maybe go with "Core p
On Wed, Feb 18, 2015 at 11:18 AM, Gordon Sim wrote:
> On 02/18/2015 03:44 PM, Rafael Schloming wrote:
>
>> I can't speak to the logic, but I believe the use of contrib to signal
>> pretty much *exactly* what we are talking about here is a pretty common
>> convention. There's a post here that desc
On 02/18/2015 04:18 PM, Gordon Sim wrote:
On 02/18/2015 03:44 PM, Rafael Schloming wrote:
If we didn't already use the contrib convention I wouldn't actually care
all that much, but I feel like we should at least be consistent within
our
own codebase, so if we introduce python.extras, that's pre
On 02/18/2015 04:04 PM, Justin Ross wrote:
Right now Container is inside proton.reactor. Should it go into the core
classes (proton) instead?
Not unless Reactor also went into core. I don't think you want anything
in core that depends on something outside. Container is simply an
extension of
On 02/18/2015 03:44 PM, Rafael Schloming wrote:
I can't speak to the logic, but I believe the use of contrib to signal
pretty much *exactly* what we are talking about here is a pretty common
convention. There's a post here that describes django.contrib in much the
same terms:
http://jacobian
Right now Container is inside proton.reactor. Should it go into the core
classes (proton) instead? It's notionally a peer to the endpoint types,
and going by the examples, it has primary significance for users.
On Wed, Feb 18, 2015 at 9:28 AM, Rafael Schloming wrote:
> A couple of comments in no particular order...
>
> The "Core user model and uitility classes" description could be
> misinterpreted on a quick read. Maybe go with "Core protocol model..." or
> something like that? (Really all these APIs a
On Wed, Feb 18, 2015 at 9:52 AM, Gordon Sim wrote:
> On 02/18/2015 02:28 PM, Rafael Schloming wrote:
>
>> On Wed, Feb 18, 2015 at 4:18 AM, Gordon Sim wrote:
>>
>>> To amplify a little, the point was that the two things currently in the
>>> utils module are ways of adapting the reactive, non-bl
On 02/18/2015 02:28 PM, Rafael Schloming wrote:
On Wed, Feb 18, 2015 at 4:18 AM, Gordon Sim wrote:
To amplify a little, the point was that the two things currently in the
utils module are ways of adapting the reactive, non-blocking, event-driven
style to some other style (messenger is in my v
On Wed, Feb 18, 2015 at 4:18 AM, Gordon Sim wrote:
> On 02/17/2015 08:49 PM, Justin Ross wrote:
>
>> I've made a few changes to the api layout proposal:
>>
>>
>> https://cwiki.apache.org/confluence/display/qpid/
>> Proton+API+layout+proposal
>>
&
On 02/17/2015 08:49 PM, Justin Ross wrote:
I've made a few changes to the api layout proposal:
https://cwiki.apache.org/confluence/display/qpid/Proton+API+layout+proposal
- Renamed proton.reactors to proton.reactor
- Added proton.security, to clean up the "core" space. Thi
An update.
I've made a few changes to the api layout proposal:
https://cwiki.apache.org/confluence/display/qpid/Proton+API+layout+proposal
- Renamed proton.reactors to proton.reactor
- Added proton.security, to clean up the "core" space. This would be home
to future ad
On Wed, Feb 4, 2015 at 1:00 PM, Rafael Schloming wrote:
>
> > Here's a first attempt:
> >
> > http://people.apache.org/~jross/proton-apidoc-draft/modules.html
> >
> > To summarize the delta from the current docs:
> >
> > - The groups are a flat array; this relates to the next point of
> > diff
On Wed, Feb 4, 2015 at 10:16 AM, Justin Ross wrote:
> On Thu, Jan 29, 2015 at 12:08 PM, Rafael Schloming
> wrote:
>
> > On Thu, Jan 29, 2015 at 9:28 AM, Justin Ross
> > wrote:
> >
> > > This makes good sense on its own, but it doesn't help with our goal of
> > > naming and grouping together a "
On Thu, Jan 29, 2015 at 12:08 PM, Rafael Schloming wrote:
> On Thu, Jan 29, 2015 at 9:28 AM, Justin Ross
> wrote:
>
> > This makes good sense on its own, but it doesn't help with our goal of
> > naming and grouping together a "growable library of like things". In
> other
> > words, if we end up
Yes, quite a lot like contrib. I think that's a fine name. If no one else
objects, I'll add that to our api layout doc.
On Mon, Feb 2, 2015 at 4:20 PM, Rafael Schloming wrote:
> On Thu, Jan 29, 2015 at 9:56 AM, Justin Ross
> wrote:
>
> > On Wed, Jan 28, 2015 at 3:36 PM, Justin Ross
> > wrote
On Thu, Jan 29, 2015 at 9:56 AM, Justin Ross wrote:
> On Wed, Jan 28, 2015 at 3:36 PM, Justin Ross
> wrote:
> >
> > - Python is using utils, not util. I don't care whether we go util or
> > utils, but I'd very much like to avoid it being half one way and half the
> > other. If we decide utils
On Thu, Jan 29, 2015 at 9:28 AM, Justin Ross wrote:
> This makes good sense on its own, but it doesn't help with our goal of
> naming and grouping together a "growable library of like things". In other
> words, if we end up with many reactor implementations, it won't be very
> approachable to ha
On Thu, Jan 29, 2015 at 11:35 AM, Andrew Stitcher
wrote:
> On Thu, 2015-01-29 at 09:56 -0500, Justin Ross wrote:
> > ...
> > PROTON-805 adds more of the latter to proton/utils.py, and it already had
> > BlockingConnection. Having both types of util in one module ends up
> making
> > imports a me
On Thu, 2015-01-29 at 09:56 -0500, Justin Ross wrote:
> ...
> PROTON-805 adds more of the latter to proton/utils.py, and it already had
> BlockingConnection. Having both types of util in one module ends up making
> imports a mess because it contains at once quite low-level things and
> high-level
On Wed, Jan 28, 2015 at 3:36 PM, Justin Ross wrote:
>
> - Python is using utils, not util. I don't care whether we go util or
> utils, but I'd very much like to avoid it being half one way and half the
> other. If we decide utils, I'll update the wiki page.
>
Distinct from the naming consisten
qp-datatype types.
http://qpid.apache.org/releases/qpid-proton-0.8/protocol-engine/c/api/types_8h.html
On Wed, Jan 28, 2015 at 5:25 PM, Rafael Schloming wrote:
> On Wed, Jan 28, 2015 at 3:36 PM, Justin Ross
> wrote:
>
> >
> https://cwiki.apache.org/confluence/display/qpid/Pro
On Wed, Jan 28, 2015 at 3:36 PM, Justin Ross wrote:
> https://cwiki.apache.org/confluence/display/qpid/Proton+API+layout+proposal
>
> Please take a look. The intention:
>
> - Organize the API consistently across languages, allowing for deliberate
> exceptions
>
> -
https://cwiki.apache.org/confluence/display/qpid/Proton+API+layout+proposal
Please take a look. The intention:
- Organize the API consistently across languages, allowing for deliberate
exceptions
- Put more frequently used items closer to hand, and less frequently used
ones out of the way
26 matches
Mail list logo
