What is cometd?

Hi Alex,

I would have thought the seperation of components would be
something
like this, which may be what you are doing already or have
planned...
An implementation of a client side library, this uses a
defined spec to
talk to a server. The cometd server would just be 'an
implementation'
again. This then leaves the backend. I think this would be
up to the
cometd server, for example you might like to come up with
another
spec/API for the backend - but it feels to me that this
would be more
implementation specific rather than a standard spec/API that
all
implementations of a cometd server has to implement. This
decouples the
client and backend API's, which allows people to implement
a simple
cometd server without having to implement a backend API.

Subscription management is something that is very useful to
implement
in the server rather than letting a backend app have to deal
with
knowing where to send everything. I guess it depends on what
style of
apps people might use this for, but for apps that send
messages that go
to multiple subscribers you really want that handled for you
in an
efficient way.

Hookable auth is good (another API), permissioning of
channels can also
fall into this area - probably read/write permissions.

One other thing to consider is message size. When/if you get
to the
point of an application that can support high message rates,
especially
to high numbers of users, then every byte counts and can
have a
dramatic effect on performance. Your messages dont look
overly verbose
(unlike some XML based protocols), but it might be something
to
consider at this stage before it's too late to change
things.

Regards
Martin


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cometd-dev" group.
To post to this group, send email to cometd-devgooglegroups.com
To unsubscribe from this group, send email to
cometd-dev-unsubscribegooglegroups.com
For more options, visit this group at http://grou
ps.google.com/group/cometd-dev

Visit the cometd website at http://www.cometd.com/
-~----------~----~----~----~------~----~------~--~---

On Friday 21 July 2006 1:43 am, Martin Tyler wrote:
> Hi Alex,
>
> I would have thought the seperation of components would
be something
> like this, which may be what you are doing already or
have planned...
> An implementation of a client side library, this uses a
defined spec
> to talk to a server. 

Yep, that's what we're working against right now. The
complicating 
factor is that we're still working out what the
"right" 
envelope/preamble/tunnel-init/signoff messages are per
pluggable 
transport type. I'm evolving those in the python
implementation right 
now, but I think they can (and should) be standardized such
that the 
protocol for what gets sent over the wire is
fully-constrained.

> The cometd server would just be 'an 
> implementation' again.

Exactly. We're pursuing 2 server implementations right now
to proove 
interop (and I'll probably write a second client that
doesn't have a 
Dojo dependency).

> This then leaves the backend. I think this 
> would be up to the cometd server, for example you might
like to come
> up with another spec/API for the backend - but it feels
to me that
> this would be more implementation specific rather than
a standard
> spec/API that all implementations of a cometd server
has to
> implement. This decouples the client and backend
API's, which allows
> people to implement a simple cometd server without
having to
> implement a backend API.

I'm not sure I grok "backend" in this context.
I can think of a couple 
of different layers which could be specified here. What are
you 
thinking of in particular?

> Subscription management is something that is very
useful to implement
> in the server rather than letting a backend app have to
deal with
> knowing where to send everything. 

Agreed. The python version right now is just a dumb topic
router...even 
apps would just "throw" messages at it rather
than knowing anything 
about the channel dispatch mechanism specifically.

> I guess it depends on what style of 
> apps people might use this for, but for apps that send
messages that
> go to multiple subscribers you really want that handled
for you in an
> efficient way.

Yep. I don't know that my current implementation is very
efficient, but 
I suspect that it's not a horrible first pass.

> Hookable auth is good (another API), permissioning of
channels can
> also fall into this area - probably read/write
permissions.

Would you view that as part of the spec? Or
server-dependant?

> One other thing to consider is message size. When/if
you get to the
> point of an application that can support high message
rates,
> especially to high numbers of users, then every byte
counts and can
> have a dramatic effect on performance. Your messages
dont look overly
> verbose (unlike some XML based protocols), but it might
be something
> to consider at this stage before it's too late to
change things.

My initial latency concerns revolve around message batching.
In a lot of 
transport types it's very possible for there to be many
messages 
delivered to a client between client connects, and I want to
be able to 
specify a way to multiplex multiple event delivery along a
single 
message such that the envelope overhead is minimized.

Beyond that, I'd love to know what your thoughts on the
current 
implementation and proposed spec are.

Regards

-- 
Alex Russell
alexsitepen.com     A99F 8785 F491 D5FD 04D7 ACD9 4158
FFDF 2894 6876
alexdojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78
E242 59C3 9723