On Wed, Apr 3, 2013 at 7:12 PM, Justin Ross <[email protected]> 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. --Rafael
