On 26 March 2013 19:13, Gordon Sim <g...@redhat.com> wrote: > On 03/26/2013 05:56 PM, Justin Ross wrote: > >> (A little trouble with my list subscription, so I'm using nabble to >> reply.) >> >> "I would have these categories on the front page in some way (with more >> detail on each and indeed on each aspect or sub-component) available via >> links." >> >> This suggests that the categories you listed are not now present on the >> front page. >> > > Sorry, I didn't mean to suggest they weren't present. I was responding to > the 'next iteration' plans. > > I agree with Gordon that the user / requirement centric view rather than the source-code organisation / release artefact point of view makes sense for the front page. It may well be that such a view may point us in a direction of changing our project organisation to better reflect how users want to use the components within the Qpid project.
> > I'm confused because I think they are (APIs, Brokers, Proton). >> Is the trouble that some of Proton's APIs are mixed into the API group? >> >> I think a user-centric view focuses on the immediate thing people use, >> which >> is an API or a server. >> > > In general I agree. I think proton is a 'toolkit' and I think that is also > something that users care about. > > The "toolkit" thing is interesting and perhaps points to a third category. Personally I wouldn't have an issue in having the same component linked to from multiple "use cases" on the front page. Proton is providing APIs via Messenger, but it is also a toolkit. > > Those are the independently usable parts, and so >> they should be first class in the logical presentation. Proton doesn't >> fit >> in this scheme. >> >> Proton doesn't fit because it's a container of multiple end-user parts, >> just >> as our cpp (broker, messaging api) and java (broker, jms) trees are. >> > > The difference for me is that the combination of protocol engine and > messenger in to a single proton toolkit is deliberate whereas the > collection of clients and brokers for c++ and java respectively is somewhat > accidental and driven by the convenience of having them share certain > common code. > > > So I think the division into "APIs" and "Brokers" seems a little incomplete. A Management tool is neither an API nor a Broker... Similarly if we start building proxies, routers, "storage nodes" etc these will not be brokers. I don't want us to give the impression that Qpid is only about APIs and Brokers. I also wonder about categorizing QMF as an "API"... I tend to think of it as an application stack built on top of AMQP (or actually on top of Qpid). I think it is a little confusing to list it as a peer of Messenger, JMS or the Messaging API. I might be tempted to put it into an "Extras" or "Other" category. It's also pretty Qpid (C++) specific right now (though thanks to Fraser's great work it should soon be available for Java too)... it's not a generic AMQP (1.0) API as we expect the others to be. It won't work as a management framework for an AMQP 1.0 broker from another vendor. > "Much of the other stuff on the right hand side of the page I would move >> off the front page. While I see the value of having some easy links, I >> think it is a little noisy and I think it could be more clearly done in >> the context of the different components." >> >> I could see doing that. Note, though, that the stuff on the right does >> not >> naturally hang off the categories you described (for example, "other >> client >> libraries") because they are really operational things, and are therefore >> tied to how our source modules are organized. To map them onto >> proton+otherclientlibs+brokers would be very synthetic. >> > > Not sure what you mean by synthetic. I agree certainly that the svn layout > doesn't represent the logical structure I laid out and neither do the > release artefacts in some cases. However what I meant was that you could > provide context specific notes or links if desired. E.g. I can provide an > svn ref to the cpp directory for the c++ broker and for the c++ version of > qpid::messaging and perhaps explain the two are shipped together. > > > I tend to agree that the right hand side of the main page is over fussy (and it is somewhat surprising when clicking through to a child page that suddenly the breadcrumb trail is the only remaining navigational element... where did my sidebar go?) I think in general we suffer because we haven't properly thought about what our "components" are and what it means to be a component. Proton is a component and has a sensible location in our repo, and its own release cycle and JIRA project. I tend to think long term other components (or groups of components) should follow this pattern. At the moment Proton sticks out as "special" because it is the only component doing things "properly"... it might help us if we though about where we want to be with other components and designed to that rather than the mess (IMHO) that we have now. Perhaps we can even make some progress on moving towards that organisation? -- Rob
