> I have put online the new CometD 2.4.0 documentation athttp://docs.cometd.org/reference.

> The new documentation is much improved over the previous one, with
> many sections added, and hopefully will ease contributions since it's
> written in docbook and hosted at GitHub, so anyone can fork and
> request a pull.

> We are in the process of expanding the documentation by adding
> tutorials, for an easier path to learn CometD.

> I'd appreciate any comment on the new documentation, especially about
> the "concepts" sections, seehttp://docs.cometd.org/reference/#concepts.

> Any idea, or suggestion or improvement you want to see about the docs, speak up.

> The documentation was the last step holding the release of CometD
> 2.4.0 final, which will be hopefully tomorrow.

> Simon
> --http://cometd.orghttp://intalio.comhttp://bordet.blogspot.com
> ----
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless.   Victoria Livschitz

> The concepts section makes sense to me, although I already understood
> it :op

> I would like to see an explanation for 6.4 - 6.7 about when you would
> use the extensions, and why you should. And I guess when you
> shouldn't.

> On Wed, Feb 8, 2012 at 07:07, Iain <iain.robe...@gmail.com> wrote:
> > Thanks for the new documentation. I have struggled a little to get up
> > to speed with Cometd, and it looks quite detailed :o)

> > The concepts section makes sense to me, although I already understood
> > it :op

> > I would like to see an explanation for 6.4 - 6.7 about when you would
> > use the extensions, and why you should. And I guess when you
> > shouldn't.

> Makes sense. Can you please file a JIRA task under the "documentation"
> component athttp://bugs.cometd.org?

> > The area I am most unsure about is what happens across page loads.
> > Including if I have the reload extension and/or the acknowledge
> > extension on.

> Ok, same as above, file a JIRA.

> > Maybe a few common scenarios and what configuration you should use is
> > another idea. My guess of common scenarios are:
> >  - Single Page Chat

> This could be a tutorial.

> >  - Multiple Page Chat

> I am guessing it's too complicated for a tutorial.

> >  - How to ensure they don't miss a message across page reloads.

> Ack extension, could be another tutorial.

> >  - Multiple Page Alerts (i.e. instant alert when an event occurs
> > across an entire website)

> If I understand correctly, this is already present out of the box: if
> you open 2 browsers of the chat demo, they both receive the chat
> message.

> >  - This is what I am using it for. When the page is rendered it
> > contains the alert count, and then it subscribes to /user/alerts (race
> > condition?).

> Not following.

> >  - Twitter style 20 new tweets.

> Not sure I understand this precisely.

> >  - Stockmarket Ticker

> Perhaps another tutorial.

> >  - Losing messages is ok for this scenario

> Not sure what scenario you refer to.

> Thanks much for the feedback.

> Simon
> --http://cometd.orghttp://intalio.comhttp://bordet.blogspot.com
> ----
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless.   Victoria Livschitz