Hiding messages

[Neil Mosafi]

Hi

The Message is the schema used to communicate between browser and
aspComet - should applications be exposed to this? I am not sure!

Applications currently interact with AspComet through event
subscriptions. I think applications only really care about a few
things on the message - namely channel, data and ext. I can't see why
they'd care about other fields such as version numbers, connection
types, id, etc...

So how about just exposing those fields on the Events, and not letting
the messages get to the applications? Be interested to hear people's
thoughts on this.

Thanks
Neil

[Symon Rottem]

I don't know, does working with the message obfuscate meaning or introduce friction?  If not then I wouldn't abstract it away - you can't anticipate what a developer might find useful in that additional data.

Just my 2 cents.

Cheers,

Symon.

 
Symon Rottem
http://blog.symbiotic-development.com

[Wintermoose]

Hi,
I think I agree with Symon there. Unless we identify some field that
can mess up thing, I'd leave it all exposed. I came across too many
situations where I had to go through crazy hoops just because the API
creator didn't feel like field X or Y is useful (probably the worst
case I can remember was the session storage in asp 1.1 :-)

best regards
Robert

On Oct 31, 7:43 am, Symon Rottem <s.rot...@gmail.com> wrote:
> I don't know, does working with the message obfuscate meaning or introduce
> friction?  If not then I wouldn't abstract it away - you can't anticipate
> what a developer might find useful in that additional data.
>
> Just my 2 cents.
>
> Cheers,
>
> Symon.
>

> Symon Rottemhttp://blog.symbiotic-development.com

[Greg Thomas]

On 30 October 2010 23:33, Neil Mosafi <nmo...@gmail.com> wrote:
> Hi
>
> The Message is the schema used to communicate between browser and
> aspComet - should applications be exposed to this?  I am not sure!

IMHO, the "unit" that aspcomet deals with is a message; and that's
what people would expect to deal with. So I think it a message should
be exposed. Perhaps document that certain fields are "internal", and
therefore subject to change, but hiding the mesage itself sounds
counter-intuitive.

Unless I've missed what you're trying to say.

Greg

[Neil Mosafi]

Yeah I guess so... was just thinking that it makes it harder for us to
change, say the Bayeaux protocol changes or something, we wouldn't
want to have to make all applications change too.

Probably not worth it.

On Oct 31, 7:04 pm, Greg Thomas <greg.d.tho...@gmail.com> wrote:

[Symon Rottem]

If that's really a concern then an alternative would be to deliver another ASPComet message object which exposes the Bayeaux message as a property; this would allow you to expose a standardized ASPComet message but still have access to the Bayeaux message.  You could even document the property to indicate that the message property exposes a Bayeaux message and that is may be subject to change.

Personally, however, I wouldn't do it.

Cheers,

Symon.

Symon Rottem
http://blog.symbiotic-development.com