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'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.
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.
"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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
