Hi Peter, Nice to see you stuff arriving on the SVN. I just moved rocket in a directory next to liquidsoap's: I believe that the new generation GUI should be a rather large project which will get its own releases, branches, etc. I'm also glad to see that you're happy to stick to pygtk. Finally, rocket is a nice name, but it's not very soapy and not very distinctive either ;)
Another major aspect about the GUI is that in my current design I've moved away from the detaching window form of the previous GUI, I need suggestions on ways to handle this. Since some users might want to have multiple aspects of the GUI visible at once and I don't want it to become an unorganized chaos every time the program is opened.
I don't know how much you tried the current liGuidsoap. Although each widget can be ran independently in its own window, the main program liguidsoap starts widgets in notebook tabs, much like your current mockup. I'm not a big fan of the separated windows, however I feel that only one notebook is too limited. It could be nice to have an interface allowing arbitrary horizontal and vertical splits (much like vim/emacs) to give the user the ability to choose the layout of its controls. Same as your colors, it would be neat to reming the layout from one session to another. I'm also not sure to understand the intended design of your tool. In the old design, one controller (one tab) controlled exactly one node in a liquidsoap script, not doing anything more. This is probably not the best way. For example, I like the first tab in your demo, where one can see the status of all the output nodes. However, one advantage of this simple architecture is that it fits any liquidsoap instance, whatever nodes are there. Will it still be possible with rocket or are you targetting specific instances of liquidsoap? About the jingle board: it looks like a convenient widget. But how is it supposed to be setup? From earlier discussions, I guess it controls a request.queue() or request.equeue(), but how does the GUI know the list of jingles? Again, a nice thing would be to save this information from one time to another: the admin configures the GUI and the DJ just uses a predefined layout.
One main aspect of the GUI I will be heavily developing is User Control, since it is assumed that the GUI will be in use in studio environments with multiple users. Therefore we don't want users messing around with key studio jingle boards and being able to touch the streams directly, some of these requirements will come under user control within the main daemon and there's plenty of time to discuss what strategy the team can take. - From what myself and David B were talking about on irc today, there's the choice of telnet, telnet + ssl, CORBA or even Operating system specific sockets for communication (any more please add). Each of them come with their own distinct advantages and it'll be good to have a full discussion of which would be the best suited.
At some point, the protocol for interacting with liquidsoap will probably have to evolve to something more structured. However, we can already do a lot with the current protocol, and have a lot more on the TODO list.. But your question is not about the protocol, it's about the medium. Or rather, I think you're mixing both questions. Telnet used to mean "remote shell"; as such it is very outdated by much more secure ssh. I use the word "telnet" because it still refers to a convenient tool for interacting with a server (liquidsoap) using a human-readable plain-text protocol like ours. What you see in the telnet command is exactly what is carried through sockets -- and by the way, we do use the socket API directly. Using the word "telnet" may be a bad choice because it has lead several persons to believe that this was necessarily a cheap hack. In my sense, HTTP, POP and IMAP are also telnet-compliant protocols, and the development of our protocol won't be stuck because we use this so-called "telnet" interface. There is only one protocol for interacting with liquidsoap, but there are already two available mediums: tcp sockets and unix sockets. The first ones are weak, because the is no password, so (at least) any user of the host machine can control liquidsoap. SSL could indeed be a simple solution to that problem. Unix sockets offer more fine-grained permissions, actually the same as for files under unix. I don't know what CORBA can bring us. Discussion about the protocol could be useful, although I don't feel an urgent need for it right now. Discussion about the media are open, but in that domain coders are most welcome: it doesn't hurt to add new mediums, as it wouldn't invalidate the two existing ones. Cheers. -- David
