epoch1970;398980 Wrote: > Great idea! Do you query SN, or the local SC, for that ?? Actually, it's much more primitive than that at this point. Since Max's alarm functions only provide alarm data for currently locally connected clients and have nothing at all to say about SNed connected clients, I'm actually having to parse the local server.prefs to get the data. Which, of course, means that the slightest change in how alarm data gets stored in the prefs will totally break this feature. Not good, but I don't know of an easy way to do this otherwise.
I queried AndyG on the developer's forum about this approach, but all I got back was a "Why would you want to do this?" sort of answer. epoch1970;398980 Wrote: > Not for *me*; Since switch back can happen any time before alarm time > simply because the server is woken up (think of a non-dedicated > computer), I want the ability to cancel a switchback when a player is > currently streaming radio on SN. I was doing this -until now- because I > felt my prior policy "at wakeup I switch back all players I switched in > the 1st place" was too obtrusive. My code is basic and forfeits > switching back this player ever, so at alarm time I'm probably good for > fallback sound. Nevertheless, for me usability is better than without > it. So I'll be looking into JSON to get the activity state. ... If you > feel there is some value to querying SN directly, I could look into > this. You go, guy. You're already treading in territory that inspires abject fear in me. Which is not to say that I wouldn't happily incorporate anything you come up with and care to share. And I do concede that your rationale for wanting the feature makes total sense. epoch1970;398980 Wrote: > You're right to insist on this. I will have a look; I think I read > somewhere about adding to the doc, or calling the doc pages from a > plugin. Local pages have the advantage of being tied to the plugin > version that's installed. Versioning with online pages is a bit more > tricky. But online pages (the wiki ?) are easily updated. This boils > down to what the doc is about. Centered on the plugin, then the doc > lifecycle should be the same as the plugin, and local pages are better; > If the doc is more of a how-to, with e.g. recipes on how to WOL using > ubuntu-8.x on platform XYZ, then online is better. > Anyway, first thing first: how to link. > EDIT: Found it. See the last paragraph on > http://wiki.slimdevices.com/index.php/PluginWebInterface (that's SC6, > though.) Thanks for that. I'll take a look. And, may I just quote Homer Simpson here and say "DOH!"...I hadn't even THOUGHT of just providing a href link to an on-line page. And screw on-line versioning. If the href incorporates the installed plugin's version number, then the link could always just redirect to a "invitation to upgrade" page if the user doesn't have the latest version. But all-in-all, I think I'd rather keep the setup help page stored locally. -- gharris999 ------------------------------------------------------------------------ gharris999's Profile: http://forums.slimdevices.com/member.php?userid=115 View this thread: http://forums.slimdevices.com/showthread.php?t=48521 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
