A really big problem in projects is the desire of "customers" to "gold-plate" the product. This adds time and complexity to building it. Further more, it enhances unreal expectations of the customer that the product can be "everything to everyone".
- Yeah. So lets never add any more features. Ever. After all, we don't want to get anyone's hopes up. This crazy idea of listening to users suggestions/requests is spiralling out of control, if we don't curtail it now who knows what tomorrow's feature suggestors might bring. Won't somebody
please think of the children?!
mIRC is an IRC client. IRC is (by its very definition) a text-based chat. Video is not text.
- If mIRC is an IRC client plain and simple then there's no reason for /splay, sockets, binary variables, file handling, or pretty much about 90% of the scripting language. Just because mIRC is an IRC client doesn't mean it must be an IRC client in the most spartan sense of that term.
If mIRC were to support video, then it would occur in a similar way. This would mean that mIRC itself will not support webcam, but that IRC would support a text command that would enable clients to recognise that a particular file should be played by a nominated application. I would be surprised if that infrastructure was not already in place.
ON CTCP:VIDEO:/play <file name or URL>
Come to think of it, would not the existing commands to play sounds achieve the same purpose? After all, Windows Media Player coud be the chosen application for that particular file extension.
If this is the case, then WebCam support does not need to be added!
- Of course it requires support in mIRC because we're talking about
streamed content being sent over a sub-protocol of a sub-protocol of IRC. It's nothing like a sound request.
