Simon John wrote:
As far as querying the server every few seconds, it does make sense (you don't miss events) and is the recommended way of doing things with InetCtrl, but I'd prefer to save the bandwidth/server load than have realtime status updates.
The amount of bandwidth and server load that will be used by a once-a-second query is probably pretty trivial (unless you're expecting this to run over internet or dialup networks -- and even then, it's probably not going to be worth worrying about). Even on an old 10Mbit ethernet connection, a couple of extra packets every second will not make a notable difference. This (IMO) is premature optimization. :)
The status also updates whenever you send a command (like play/pause).
But does the server push events to the client? If there's a filesystem error while a track is playing, how does your client know about it? In addition, what happens if XMMS segfaults, or the server machine loses power?
I'm really stuck on how to implement this now....
One of the big questions here is whether your client will have exclusive access to the XMMS server. That is, will it be possible for more than one such client to connect to the same XMMS, and/or for XMMS to have direct interaction on its host machine?
If you have exclusive access, then changes in the status of XMMS will only happen when 1) you change it yourself, or 2) there is an error. In this case, you can check status much less often. (However, you'll still want to deal with the error conditions, which probably means checking at a much shorter interval than expected track length.) If, on the other hand, there may be more than one client/user interacting with XMMS, then you also have to deal with the possibility of your server changing status without your client taking direct action.
I really think that you *do* want to do fairly frequent status checks with your server. The cost is small, and the gains in responsiveness and robustness are potentially very significant.
Jeff Shannon
-- http://mail.python.org/mailman/listinfo/python-list
