So I have a bunch of thoughts on this thread. They are a bit scattered, but I'll try to consolidate here. Apologies for the clumsy organization of this post.
Firstly, in response to Gordon's "user centric view" comments. I do agree we need to have a user centric view, however what is suggested doesn't strike me as a user centric view. It reads to me more like a component centric view where the components are aspirational, i.e. what we would like the components to be rather than what they currently are: Qpid Proton > - protocol engine > - messenger > - available in java or c, with python, ruby and perl wrappers > > Other client libraries: > > Qpid JMS > > Qpid Messaging > - c++ > - python > - perl, ruby > > Brokers: > > - c++ broker (available on windows and linux) > - java broker > - broker management tools > In my mind, a truly user centric view would be focusing on what users actually want to do. For example I can imagine having a very simple top level division into two categories: "Building AMQP Applications" and "Deploying AMQP Networks". I'm just thinking out loud here, and there may well be a better/snapper/more succinct way to express these categories, but what I'm driving at here is breaking things down very broadly into two different usage scenarios, the former being "I want to write code (or I have a body of existing code) and I want to make it speak AMQP." The latter being a set of tools/servers/brokers/proxies/intermediaries/services/etc that already speak AMQP and I can deploy them into my network without having to write any code. I think from these two categories you could then crosslink into a more component oriented view that explains how a given component might be of use. I think this may roughly be what the "APIs" and "Brokers" categories on the current page are going for, but I feel like the former is a bit esoteric as the name and hard to map to the scenario, and the latter is a bit too specific. There are more than just Brokers involved in an AMQP Networks. Now for what might seem like a bit of a departure, I have to say I am +1000000 on Rob's suggestion to break down the monolithic qpid tree into smaller independently releasable components alongside Proton. Having worked through a number of both qpid releases and proton releases, I can confidently say the difference between the two (monolithic vs small) is night and day. It is *really* difficult to understate the huge advantages of having a simple/nimple/agile lightweight release process. I really think we should do this along with the web site changes above. In my view these issue are really tied together. I feel about the web site the same way I feel about README files. If the README is more than 5 or 10 lines long, 50% of which should be marketing, then the build system/src organization/etc is broken and we should continue to iterate until we have achieved that level of simple/compelling README and web site. In fact I would go so far as to say we shouldn't rev the qpid version to 1.0 until we do this breakdown, and I'd personally like to both do both of those things ASAP. --Rafael On Tue, Mar 26, 2013 at 4:06 PM, Rob Godfrey <rob.j.godf...@gmail.com>wrote: > 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 >
