On Wed, Feb 18, 2015 at 9:28 AM, Rafael Schloming <r...@alum.mit.edu> 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 are for users, so it seems > weird to mention it.) Also the utility classes mentioned here sound like > they overlap with the util package. What is that actually referring to? > Yes, good point. I'll go with protocol instead. If I could, I'd make util go away. It's for low-level things (not Proton extensions, but language library extensions) that we wish to make public. The best example we currently have is URL. > I like the proton.security addition, I think that makes sense as security > is generally handled in one contained place in any application. > > I'm not so hot on the types subpackage. I don't think it actually buys us a > lot in terms of uncluttering core since there are only a few very simple > things in that category. It basically consists of about 5 or so pure > constructors that extend builtin python types with extra information, e.g. > timestamp which is just a subclass of long that gets encoded on the wire as > a timestamp. It's implementation is literally just this[1], as you can see > it adds very little surface area to the API. The other items in this > category are similarly simple. Conceptually these types really are part of > the core protocol model, and unlike in the case of security, if your app > does need to deal with timestamps or unsigned numbers or whatever, it is > pretty likely that it will need to do it all over the place which means > that you basically always need to do two imports in order to get the full > protocol model. > http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-types-v1.0-os.html#section-primitive-type-definitions The number of AMQP primitive types is comparable to the number of endpoint types. A given language may not need all the types, but it will likely need more than half of them. Some of these will not find frequent use, such as the decimal types. I think it is a source of clutter (the implementation size is not a factor here; instead it's the number of things in a namespace). The grouping has the additional benefit of clarifying that these are all things of one sort. Are there particular types that you think will find frequent use and should be promoted to the "core" level? I too would like to consolidate the imports, but I disagree about the scale of the clutter problem. Gordon's python examples don't seem to import any types. For most higher level languages, I would hope this would be the case. Reference points: - https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=tree;f=examples/python - http://people.apache.org/~jross/proton-apidoc-draft-2/group__types.html - http://qpid.apache.org/releases/qpid-proton-0.8/protocol-engine/java/api/index.html
