Thanks. I’ll give it a go and see if that corrects the problem.

I think you should just add a short timeout (like 300msec) to the select() call and send all data collected in that time period as one message.

In pseudo code:

a. select() on stdout+stderr with a 300ms timeout.
b1. if you read something, append the bytes read to a buffer
b2. else: (you didn’t read anything i.e. the timeout kicked in), send the buffer data via xmpp and empty the buffer
c. goto a.

I hope I can contribute with my Z-machine run/stop interpreter soon as well!

Still looking at buffering to frotz output…

The z-machine bridge buffering may be a bit more tricky (for me) to
figure out. I think the problem will be knowing when the process is
done sending data. Currently I’m using popen3() and a select() call
to grab the data from STDOUT and STDERR as the frotz process spits it
out. Dunno if you are a programmer, but here is what I’m doing:

@stdin, @stdout, @stderr = Open3.popen3("./dfrotz -Z0 -w #{width} -p
zgames/#{zgame}.z5")
loop do
 result = select([@stdout, @stderr], nil, nil)
 if result != nil
   for data in result[0]
     if data == @stdout
       send_to_user(@stdout.gets)
     elsif data == @stderr
       send_to_user(@stderr.gets)
     end
   end # for
 end
end # loop

I can probably play around with this a bit, maybe use a timeout or
something… but I definitely understand the issue with limited screen
real estate on a Blackberry. I personally use a Blackberry Curve and
the BeeJive IM client. What I do, though, is create a very short
nickname in my roster for the bot (like “xb”) and don’t use timestamps
on each message. The BeeJive IM client even goes one better and
doesn’t prepend the sender’s nickname for consecutive messages. In
addition to the point you raise, the current method has another
problem where occasionally lines in a paragraph will arrive in the
opposite order they were sent. Doing as you suggest and sending the
response from the frotz process as a single message will solve that
problem as well.

Thanks again for the feedback! I’ll take a look at these issues
tomorrow and will likely have an update running very soonish.

2. Perhaps you should buffer the responses from the z-machine and then send a single message stanza when the z-machine is done sending data, rather than one message per line (I imagine your doing some kind of readline deal). With clients like google talk for blackberry and PSI the users nick or jid is displayed with each message like this…
[22:49:29] ———- XMPP Bridge commands ———–
[22:49:29] !about : About the Gamebridge.
[22:49:29] !enter : Enter the chat lobby.
[22:49:29] !exit : Exit the chat lobby.
[22:49:29] !frotz : Connect to a z-game. (e.g., !frotz zork1 [scrn_width] )

On a blackberry that’s half the screen real estate used up per line.

Keep up the good work!