What exactly are the rules for having state reflected back in the wave client

[Bill Higgins]

Hi, I'm creating both a robot and a gadget, and the two communicate by
the gadget's state object. However, I'm having a bit of trouble
because it seems like sometimes the robot sets gadget state on the
server-side but this isn't reflected in the client side. Let me
explain.

I have a gadget that listens to state change events with code like
this:

// GADGET CODE

gadgets.util.registerOnLoadHandler(function() {
wave.setStateCallback(onStateCallback);
});

function onStateCallback() {
// do stuff with wave.getState() object
}

// other event handlers that sometimes call wave.getState().submitDelta
(deltaObj);

// END GADGET CODE

On the (Java) server-side I have a robot that occasionally appends or
modifies the gadget state via calls like this:

// ROBOT CODE

theGadget.setField("aKey", "aValue");

// END ROBOT CODE

Observations:
1) The robot always seems to see the state updates that the gadget
makes via submitDelta
2) The gadget usually but doesn't always see the updates that the
robot makes via setField; more precisely, the onStateCallback doesn't
always fire after the robot called setField on the server-side

The oddest thing about observation 2 is that set the log level for
AbstractRobotServlet to INFO and verified via the serializeOperations
log message that the missing in action setField operations are
actually getting sent back from the robot.

Does anyone know why the gadget's onStateCallback method doesn't
always see the server-side changes? Are there any gotchas in this
area?

Thanks,
Bill

[Brian Kennish (Googler)]

On Tue, Sep 8, 2009 at 11:36 PM, Bill Higgins <bill...@gmail.com> wrote:
> Hi, I'm creating both a robot and a gadget, and the two communicate by
> the gadget's state object. However, I'm having a bit of trouble
> because it seems like sometimes the robot sets gadget state on the
> server-side but this isn't reflected in the client side.

Hey Bill, as of last week, robots were limited to updating a gadget's
state one time (the workaround being to delete the gadget and reinsert
it). We had a pending change that undoes the limitation, but I'm not
sure it got rolled out this week.

[Bill Higgins]

Hi Brian, thanks for the response.

Could you clarify what you mean by "robots can only update a gadget's
state one time"? Do you mean once per processEvents(RobotMessageBundle
bundle) invocation?

Also, can you let me know if this throttling is a point-in-time
limitation or a design constraint? Based on your response I'd guess a
point-in-time limitation but I'd like to confirm so I can design
appropriately short-term and long-term. Also, if it's point-in-time it
would be good to know when you expect the limitation to go away so I
can determine if I tolerate the resulting problems or invest time in
workarounds.

By the way, based on the observed behavior and your response I had
another idea for a workaround. I haven't tried it yet but I'd be
curious to see what you think. Since client-side wave.getEvent
().submitDelta() changes seem to always result in (eventually)
callbacks to the onStateCallback function, I could simply create a
"ping" service (implemented with setInterval) that updates a
meaningless field (e.g. lastPingTime) every couple of seconds to make
sure onStateCallback gets called with the most recent information (my
onStateCallback function is idempotent so this shouldn't be a
problem). Does this seem like a reasonable workaround? I'm still a bit
new to wave programming so I'm never sure if a design idea is a good
one, a terrible one, or in between :-)

Thanks again,
BIll

On Sep 9, 3:19 am, "Brian Kennish (Googler)" <byoo...@google.com>
wrote:

[Brian Kennish (Googler)]

On Wed, Sep 9, 2009 at 4:13 AM, Bill Higgins <bill...@gmail.com> wrote:
> Could you clarify what you mean by "robots can only update a gadget's
> state one time"? Do you mean once per processEvents(RobotMessageBundle
> bundle) invocation?

Once ever -- and just when a gadget is added. I confirmed the fix
hasn't been pushed yet, but it should be this week. So, if you're in
the process of implementing, I'd recommend waiting over opting for
workarounds.

[Bill Higgins]

Thanks again Brian - I will take your advice and wait for the fix.
Both workarounds (re-adding the widget and periodically pinging the
server) introduced other problems.

Once the fix is there I think it should enable some pretty cool
conversations between robots and gadgets.

On Sep 9, 5:09 pm, "Brian Kennish (Googler)" <byoo...@google.com>
wrote:

[Bill Higgins]

Hi Brian, any update on the fix for Robots being able to set state
whenever they want? I'm still seeing the problem behavior.

Thanks,
Bill

[Brian Kennish (Googler)]

On Fri, Sep 11, 2009 at 11:04 AM, Bill Higgins <bill...@gmail.com> wrote:
> Hi Brian, any update on the fix for Robots being able to set state
> whenever they want? I'm still seeing the problem behavior.

Hasn't gone out yet. The upgrade Greg posted about earlier
(http://groups.google.com/group/google-wave-api/browse_thread/thread/dd75b896b2717305)
is a prerequisite, so it ought to follow soon after. I'll try to note
on this thread when the new robot-gadget stuff is actually live.

[Bill Higgins]

Hi, sorry to be a broken record, but any idea when this update might
go out?

Thanks,
Bill

On Sep 14, 9:35 pm, "Brian Kennish (Googler)" <byoo...@google.com>
wrote:

> On Fri, Sep 11, 2009 at 11:04 AM, Bill Higgins <billh...@gmail.com> wrote:
> > Hi Brian, any update on the fix for Robots being able to set state
> > whenever they want? I'm still seeing the problem behavior.
>
> Hasn't gone out yet. The upgrade Greg posted about earlier

> (http://groups.google.com/group/google-wave-api/browse_thread/thread/d...)

[Brian Kennish (Googler)]

On Mon, Sep 21, 2009 at 3:29 PM, Bill Higgins <bill...@gmail.com> wrote:
> Hi, sorry to be a broken record, but any idea when this update might
> go out?

Douwe posted when the API changes were released:
http://groups.google.com/group/google-wave-api/browse_thread/thread/59409e5825ddd375/3981f1c01a2ec390.
And the Python library is capable of multiple state updates now. But
the Java library still isn't. At this point, I don't think we'll have
a new Java version till after the 30th.

[Dagfinn Parnas]

Any news on when this will be added to the Java API?

Awaiting for this fix in order to implement some more advanced robot
and gadget scenarios.

Regards
Dagfinn

On 22 Sep, 08:32, "Brian Kennish (Googler)" <byoo...@google.com>
wrote:

> On Mon, Sep 21, 2009 at 3:29 PM, Bill Higgins <billh...@gmail.com> wrote:
> > Hi, sorry to be a broken record, but any idea when this update might
> > go out?
>

> Douwe posted when the API changes were released:http://groups.google.com/group/google-wave-api/browse_thread/thread/5....
> And the Python library is capable of multiplestateupdates now. But

[Brian Kennish (Googler)]

On Mon, Oct 5, 2009 at 10:42 AM, Dagfinn Parnas <ame...@gmail.com> wrote:
> Any news on when this will be added to the Java API?

Hey Dagfinn, it'll be in the next cut of the Java library. You can
subscribe to various project updates here ("Downloads" is what you're
waiting on): http://code.google.com/p/wave-robot-java-client/feeds.

[Venkat Polisetti]

On Oct 5, 3:11 pm, "Brian Kennish (Googler)" <byoo...@google.com>
wrote:

> On Mon, Oct 5, 2009 at 10:42 AM, Dagfinn Parnas <amen...@gmail.com> wrote:
> > Any news on when this will be added to the Java API?
>
> Hey Dagfinn, it'll be in the next cut of the Java library. You can
> subscribe to various project updates here ("Downloads" is what you're
> waiting on):http://code.google.com/p/wave-robot-java-client/feeds.

The Java robot jar file still has the date time stamp as "wave-robot-
api-20090916.jar". It looks like there is no update to the Java robot
library.

Regards,
Venkat Polisetti