Connections Issue #3 - IceStorm

[slypete]

Hi Matthew,

In this issue you provide another interface on the server to clients, ChatRoomParticipant. I'm curious why you opted against passing the publisher proxy back to clients; instead, this encapsulating object was introduced.

The client could just as easily call ChatRoomObserver::message instead of ChatRoomParticipant::say. It seems unnecessary to me; am I missing something? Is there a limitation of Glacier2 that makes this impossible?

No criticism intended. I'm a student with a similar design, so I value your insight.

Thanks,
Pete

[benoit]

Hi Pete,

The chat room participant interface is a facade: it hides the complexity and implementation details of the server to the clients.

Thanks to this interface, the client doesn't need to know about the IceStorm publisher. It's also useful for the server if it needs to add some checks on the given message before distributing it to all the other clients through IceStorm. And thanks to Glacier2, you can limit client access to this single facade object. This ensures that malicious clients can't access other Ice objects.

For more information on Glacier2, checkout the Issue #1 and #2 of the Ice newsletter.

Cheers,
Benoit.

[slypete]

Hi Benoit,

Thanks for the info! I figured that adding some checks before publishing was one of the main reasons; however, I hadn't thought about the additional security measure.

I will stick with that approach. I found it annoying that I had to write a method that just calls its corresponding method on the publisher proxy. I guess that I was being lazy...

I have read both the issues you mentioned. I think the Connections series is invaluable, both in and out of Ice.

Thanks a lot,
Pete