On 4/7/07, Steven Gong <[EMAIL PROTECTED]> wrote:
Hi all, It's been a week since the last user requirement collection. Five guys contribute to this survey. They are Joseph Wamicha, Juan Delgado, Manos Batsis, Alexander Zhukov and Bill. Thanks to all of you guys for your valuable suggestions and concerns. Now I think it's the time for a summary. * Simplify the integration and configuration (Alexander, Manos and Bill) Make Red5 easier to be embedded and integrated into existing projects other than a standalone server. Limit the number of configuration files and simplify the configuration. The configuration could be provided as xml files or property files or a set of configuration classes. So the integration could be: one or several jars are provided by Red5 together with a set of configuration classes. The project simply add the jar(s) to classpath and write a host class to configure and startup Red5. Or the configuration files can be provided on file system or classpath and the location could be specified on Red5's startup.
Perfect! NOTE: java classes configuration as described in fowlers IoC paper, not the wrapped-xml-as-an-object configuration scenario. XML/properties/etc should be transformed into POJOs, every internal object of red5 should be a POJO itself (i.e. no service lookups, no deps on container), which as a side effect is good for unit-testing. The mantra for good POJO is: do one thing good, if you need services to do your stuff declare them as dependencies (either, preferably, via constructor or via setters) The driving factor is not xml file but java classes. We should first model the right objects, their interactions and dependencies and afterwards write xml/properties configurator not vice versa. BTW, this way configuration can be written in any JVM compatible scripting language as well: groovy, jython, javascript, beanshell etc. * Make Red5 as multi-functional server (Joseph and Bill)
Add VoIP support and provide RTP/RTSP wrapping. Act as a pure AMF application server. * Run Red5 within a desktop application (Juan) Red5 should be light-weight enough so it's easy to get installed as a client application. * A just work media server Different usage scenarios need different set of features. Juan uses Red5 only for recording and playback for "recording audio tool" application while Bill needs live streaming. And if your application only needs streaming capability, SharedObject is not needed at all. * Stability and Scalability (Juan and Bill) Stability is needed by most of the software projects. We also need to take into account the scalability. How to scale the server and how to make load balanced and clustering. * Better documentation (Alexander) I like this too. :-) Anyone else has something to add? -- I cannot tell why this heart languishes in silence. It is for small needs it never asks, or knows or remembers. -- Tagore Best Regards Steven Gong _______________________________________________ Red5 mailing list [email protected] http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________ Red5 mailing list [email protected] http://osflash.org/mailman/listinfo/red5_osflash.org
