On Fri, Feb 13, 2009 at 4:05 AM, Marnie McCormack <
marnie.mccorm...@googlemail.com> wrote:
> Well put, and aside from any excitement caused (and driving Rafi to read
> our
> docs :-), apologies for my heated response
Marnie no need to apologize. Debating and raising concerns are good and you
ar
Well put, and aside from any excitement caused (and driving Rafi to read our
docs :-), apologies for my heated response ! Having had mainly Java docs for
quite a while, and laid out in such a way that users I sent to the site
could follow them I'd admit to finding some of the top level changes quit
Rafael Schloming wrote:
Believe it or not I've never actually read our documentation, however
the controversy here inspired me to take a look, and now I feel the
need to supply the perspective from a fresh set of eyes.
Comparing just the two top level pages, I found the DocumentationB
page t
Marnie McCormack wrote:
Being honest, I like the old page far better - escpecially since I just
added to it/updated it :-)
From my pov, I think it's quite frustrating that all the
broker/implementation boundaries are becoming blurred in the docs & the way
we link to them.
For example, the FAQ i
On Thu, Feb 12, 2009 at 10:28 AM, Marnie McCormack <
marnie.mccorm...@googlemail.com> wrote:
> >
> >
> > Maintaining docs by language is not a good choice IMHO.
> > We can clearly see that our users are trying to mix and match components
> > written in different languages.
> > Also the c++ broker
>
>
> Maintaining docs by language is not a good choice IMHO.
> We can clearly see that our users are trying to mix and match components
> written in different languages.
> Also the c++ broker is packaged by platform and IMO each package is a
> different product with possibly different documentati
Marnie McCormack wrote:
I'm not sure what the answer here is, as you're right about the multiple
differing views issue.
My take on it (and it is a little one sided) is to approach the pages as a
User tries to find something out, usually (inevitably) as a Java dev.
Not sure about a better way fw
I'm not sure what the answer here is, as you're right about the multiple
differing views issue.
My take on it (and it is a little one sided) is to approach the pages as a
User tries to find something out, usually (inevitably) as a Java dev.
Not sure about a better way fwd tho ... will ponder.
Ma
On Thu, Feb 12, 2009 at 8:43 AM, Marnie McCormack <
marnie.mccorm...@googlemail.com> wrote:
> Being honest, I like the old page far better - escpecially since I just
> added to it/updated it :-)
>
The problem with the old documentation page is that you cannot find
information easily. They are bur
Marnie McCormack wrote:
Being honest, I like the old page far better - escpecially since I just
added to it/updated it :-)
From my pov, I think it's quite frustrating that all the
broker/implementation boundaries are becoming blurred in the docs & the way
we link to them.
One problem we're
Being honest, I like the old page far better - escpecially since I just
added to it/updated it :-)
>From my pov, I think it's quite frustrating that all the
broker/implementation boundaries are becoming blurred in the docs & the way
we link to them.
For example, the FAQ is not a Qpid wide FAQ and
Rajith Attapattu wrote:
On Wed, Feb 11, 2009 at 3:49 PM, Carl Trieloff wrote:
I don't like there is a link for each client, I would prefer it to be an
achor to the info on the same page... not links
to separate pages.. to much clicking around
It can be done in a Similar way to the FA
On Wed, Feb 11, 2009 at 3:49 PM, Carl Trieloff wrote:
>
> I don't like there is a link for each client, I would prefer it to be an
> achor to the info on the same page... not links
> to separate pages.. to much clicking around
It can be done in a Similar way to the FAQ page.
Rajtih
>
>
> Carl.
I don't like there is a link for each client, I would prefer it to be an
achor to the info on the same page... not links
to separate pages.. to much clicking around
Carl.
Rajith Attapattu wrote:
On Wed, Feb 11, 2009 at 1:25 PM, Jonathan Robie
wrote:
Rajith Attapattu wrote:
Jonat
Rajith Attapattu wrote:
Now there will be API guides for QMF as well. Ex the python and c++ based
API's.
We need to make sure we distinguish properly between these API's and the
messaging client API's
Currently, the Python console API is in the normal Python API docs. Is
there a reason not
On Wed, Feb 11, 2009 at 1:25 PM, Jonathan Robie
wrote:
> Rajith Attapattu wrote:
>
>> Jonathan, appologies if I wasn't clear enough.
>>
>> The goal was to replace the current documentaiton page at
>> http://cwiki.apache.org/confluence/display/qpid/Documentation with the
>> proposed
>> http://cwiki
Rajith Attapattu wrote:
Jonathan, appologies if I wasn't clear enough.
The goal was to replace the current documentaiton page at
http://cwiki.apache.org/confluence/display/qpid/Documentation with the
proposed
http://cwiki.apache.org/confluence/display/qpid/DocumentationB
The reason why I create
ne good documentation page is better than a collection of documentation
> pages that differ in various ways.
>
> Jonathan
>
>
> Rajith Attapattu wrote:
>
>> Hi All,
>>
>> I had a stab at re organizing the Qpid documentation page.
>> Looking at dev/user
ocumentation page is better than a collection of documentation
pages that differ in various ways.
Jonathan
Rajith Attapattu wrote:
Hi All,
I had a stab at re organizing the Qpid documentation page.
Looking at dev/user list I found that several users had a bit of trouble
finding out the info th
Hi All,
I had a stab at re organizing the Qpid documentation page.
Looking at dev/user list I found that several users had a bit of trouble
finding out the info they are looking for.
The goals for the re-org are,
1. Provide a top level index of documentation broken down by functional
area.
2
20 matches
Mail list logo
