Using Ajax/PHP/MySQL doesn't often integrate well with wave. While
there is the huge issue with the verification of insuring the wave
state has not been tampered with (A few weeks ago, I built a prototype
bookmarklet which could swap inline gadgets and replace them with
state-editing interfaces, and I managed to allow it to do fun things
like create chat posts from the far future, changing other people's
votes, etc. Obviously a huge security issue, and even though the hack
i used to enable my exploit has been fixed by google, the fundamental
issue of having the state editable in such a way still exists as
slightly more complex robots and packet sniffers can accomplish the
same thing).
I made a really large (state heavy) gadget which was part of an
animation app I ported to a gadget. The problem with that is that
there was a huge number of rows. I created a key addressing model of
something like layer1/keyframes/shape340134 and created a helper
function getSubKeys(str) which would do getKeys() but only return
results whose keys began with a certain string to differentiate
between the multitude of data types. One thing I learned was to give
up on the idea that storing tons of rows is a bad thing. It's really
not a bad thing to split your data into tons of rows. It could even be
more efficient than storing everythign as a huge value block, and
helps stop the issue with collisions.
The chat thing really isn't that much of an issue. Just set the key
name to (new Date).getTime()+"."+Math.floor(1000*Math.random()) and to
retrieve them in order, just keys.sort(function(a,b){return parseInt
(a)-parseInt(b)}) and then you have the correctly ordered states
unlikely to be colliding.
On Dec 20, 10:16 am, palisade <[email protected]> wrote:
> I am vexxed by something that has been holding me back in my
> development. Currently, it is not possible to asynchronously update
> the wave state. What I mean by this is that when two people commit the
> same state at the same time, one of them "wins" and the other's change
> is lost. This is unacceptable for many reasons:
>
> 1) Asynchronous chat for example is impossible without doing what one
> programmer who made a popular chat gadget did which was to store a key/
> value pair for every single line of chat input. Not only is that
> reckless and inefficient use of the state map, making it flagrantly
> long, it also makes it difficult to properly store non-chat data in
> the state without coming up with a scheme for differentiating the two.
> The chat gadget didn't have to worry about players, positions, other
> objects, scores, realm information, etc. If your code for loops the
> state keys and performs some function on the data, it might get
> confused/impeded by the chat lines. In addition, performance is
> impacted because of the large quantity of keys to sort through. And,
> it might be bad for security as well as someone could spike your code
> by typing a malformed sentence in the chat. One popular chat gadget
> just stores the entire chat log into one state entry, which is also a
> flawed concept due to the "there can be only one" problem with storing
> data in the state. As a result, sometimes when many people are typing
> to one another their sentences are lost to the void, replaced by
> someone else's.
>
> 2) 2D movement in my game involves pressed/released states per player
> in addition to interpolating their positions over time. I get the
> feeling that using json+ajax+php to pass my messages around instead of
> piggybacking it onto a currently overburdened wave back-end using a
> heavy-duty xml protocol might perform better not to mention be
> asynchronous. And, my server code could then also centralize and
> authenticate the actions players are taking to prevent hacking,
> simulate events ahead of time, and store their stats, equipment and
> other data permanently in a database even if a wave is corrupted or
> vanishes. Not to mention allowing players on google wave to play with
> players on other social sites like facebook or myspace, which is point
> 3.
>
> 3) Supporting/porting games/apps to & from other sites that don't use
> the wave api, examples; facebook, myspace, etc... there is a need to
> be homogeneous and interoperable that makes relying on merely wave's
> state architecture instead of say ajax/php/mysql seems absurd.
>
> Does anyone have any solutions to these problems? Am I missing
> something? Are any of these planned, are there APIs exposed or to be
> exposed that will allow me to do this? Is there an alternative, and is
> it portable?
>
> From what I have read so far in this group, no one seems to be able to
> get Ajax to work, and my guess is that when they parse the gadgets
> they strip any ajax calls out to prevent them. I have tried a few
> times to make the calls and it always return 0 on the status. Unless
> you yourself has written a google wave gadget that can do this or
> knows of one, don't suggest it as the solution. I'm looking for real
> answers. Sorry, but this is frustrating me to no end.
--
You received this message because you are subscribed to the Google Groups
"Google Wave API" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-wave-api?hl=en.
