qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <...@alum.mit.edu>
Subject Re: Website update 2
Date Thu, 04 Apr 2013 19:11:08 GMT
On Wed, Apr 3, 2013 at 7:12 PM, Justin Ross <jross@apache.org> wrote:

> Update:
>     http://people.apache.org/~jross/transom/2013-04-03/
> Previous version:
>     http://people.apache.org/~jross/transom/2013-03-26/
> Head version (if you want to follow things as they change):
>     http://people.apache.org/~jross/transom/head/
> The source code:
>     https://github.com/ssorj/transom
> I have a feeling the most noticed change will be the page width.  It's
> now set to a max width just a hair wider (leftmost to rightmost
> character) than our current site.  In addition, it scales down to fit
> comfortably in one half of a wide desktop display or a mobile device
> in portrait.
> There remain plenty of things to do:
> https://github.com/ssorj/transom/blob/master/TODO.  Check there to see
> if the thing you'd like to have is still incoming.
> Topics for discussion:
>   - Should we rename AMQP Messenger (and its buddy) to Proton
> Messenger to clarify the link to the toolkit?

The way I think of it is that "Messenger" is the name of the API, and "AMQP
Messenger" is the implementation of the API that speaks AMQP, and that is
all part of Proton. I'm not suggesting we would necessarily ever bother
extending the implementation to speak anything else, nor do I think of
Messenger as an API that we are seeking third party implementations for,
just observing that logically more than one set of terms makes sense. I
think defacto the name of Messenger is just Messenger as that is what
people are most likely to call it, and we need to make the relationship of
Messenger to both AMQP and Proton clear, and using terms like AMQP
Messenger and/or Proton Messenger could all be reasonable in the
appropriate context.

I don't know if the above helps much, but I think it's actually the
arrangement of the information that is losing a bit of the story on what
Proton actually is, and what is its relationship to Messenger. For example
Messenger is a part of Proton, yet it doesn't appear underneath Proton in
the hierarchy of the site. I guess to sum it up, Messenger and Engine are
presented as two independent top level things, whereas in the current site
they are presented as two parts of one thing (Proton). I would say we
probably want to steer a bit more towards the latter picture given the API
discussion on the list as I think when Messenger surfaces its transports in
order to allow custom drivers, they will really have evolved to the point
of being two different facets of the same thing.

FWIW, I very much like the way you have presented information on the top
level page, with the grey box calling out the "headline" for what qpid is
and then very relevant information presented below that with useful stuff
on the right hand side. I think a similar layout could work well on the
proton page where the "headline" would be Messenger  with a more nuanced
picture presented below and some of the more mundane stuff (like the bug
box) over on the right. I think that general layout could make a very good
template for each of the independently releasable sub-units of Qpid.

    - Alternatively, should we give up on treating messenger and
> protocol engine as peers to jms and the messaging api, etc., and just
> call it the "Proton component"?

I don't think it's bad to call out those APIs into a flattened list the way
you currently have. In fact I think it's good. I would just say that each
sub-unit of qpid might have multiple interesting facets that want to be
pulled out here, and we shouldn't lose the overall structure, i.e. we
shouldn't try to hide that there are really three levels here: qpid ->
sub-unit -> facet. Where by sub-unit I mean independently releasable chunk,
i.e. a single source artifact.

>   - Is "Component" a terrible name for an end-user-facing,
> independently usable, independently documented Qpid subunit?  Do you
> have suggestions?

Possibly, I tend to think of component as a more concrete unit, and some of
the things you are calling components are actually APIs, and APIs are of
course "Abstract". I think in the three level view of things you could
perhaps get away with it, e.g. Qpid -> Sub Project -> Component. You could
also consider using Component as the term for the second level, e.g. Qpid
-> Component -> ___, but that leaves you with no obvious name for that
third level of things. Facet seems too abstract, and feature seems too fine
grained. You could of course simply go with Qpid -> Component -> (API |
Tool | Utility | Server), i.e. expand out the third level into a more
concrete term and never reference the abstract category.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message