Servants needing proxies to themselves

dougmeredithdougmeredith Member Doug MeredithOrganization: Skyridge Systems Inc.Project: Home automation
I’m a newbie to Ice, but I’ve searched both the manual and the forums for this, with no real help. I guess this is more of a best practices question than anything.

I have a servant that represents an electrical light, which can be either on or off. The servant is to use IceStorm to broadcast changes to it’s state. I toyed with one topic per light, but decided on a single topic for all light changes. That means that the monitor interface method becomes “void levelChanged(Light* theLight, int level)” rather than just “void levelChanged(int level)”. I could have used an identity rather than the proxy, but this seemed more convenient for the clients.

The difficulty arises with the servant needing to have (or create) a proxy to itself in order to broadcast update messages. Servants don’t have any knowledge of their identity, so I would need to construct the servant with some extra information, or set it after construction. I can think of ways to do this, but nothing that seems graceful.

I’d appreciate any advice, both on my specific problem, or on my entire approach.

Comments

  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi,

    If the light IceStorm updates are only invoked from light servant dispatch, you can construct the proxy from Ice::Current, for example:
    // C++
    void 
    LightI::levelChanged(int level, const Ice::Current& current)
    {
         LightPrx self = LightPrx::uncheckedCast(current.adapter.createProxy(current.id));
         _publisher->levelChanged(self, level);
    }
    
    Otherwise, if updates can be sent form methods which aren't servant dispatch and where you don't have an Ice::Current, you will need to cache the light proxy with the light servant at construction time.

    Cheers,
    Benoit.
Sign In or Register to comment.