Page Operations
Browse Space
Here's my 2nd proposal that is based on what we've discussed with Luke earlier:
- red5
- WEB-INF
- lib [1]
- classes [2]
- web.xml [3]
- server [4]
- red5.xml [5]
- re5.properties [6]
- applications [7]
- webtv [8]
- application.rb [9]
- streams [10]
- _persistence [11]
- _temp [12]
- services [13]
- echo-service.py [14]
- js-service.js [14]
- logs [15]
- web [16]
- app [17]
- config [17]
- public [17]
- lib [17]
- javaapp
- app
- services
- EchoService.java [18]
- Application.java [19]
- services
- app
- webtv [8]
- WEB-INF
The description follows...
- Red5 Jars (Spring, MINA, Quartz, Java Scripting API, JRuby, etc)
- Red5 compiled classes
- Web application context as required by Servlet specification
- Server directory name is self-speaking and tells user about contents so newbies won't touch it and geeks will find important internals stuff quickly
- Red5 Spring application context
- Red5 application context properties bundle with ports, security contraits and so forth
- Directory for Red5 applications (like in FMS)
- Concrete app directory
- Applications main file, this time in Ruby
- Streams directory for FLVs or MP3s
- Persistence dir for Remote Shared Object. Secure resource, hidden from web.
- Temporary data directory. Secure resource, hidden from web.
- Services directory for application services and other scripts
- Concrete scripts in Python and JavaScript
- Logs directory
- Web application directory. Optional, contains all the data that is used to show this application from Web. In this case contains Ruby on Rails application. Proxied by Apache?
- Web layer content, this time typical RoR application
- For Java applications app.services package is conventional (for service classes)
- For Java applications app package is conventional (for ApplicationAdapter subclass)
- All other Java app classes go into developer/vender own packages.
Some more notes about implementation and conventions over configuration:
I got rid of per-application Spring context here so we have to change resolver code. I think that app's name must be the same as it's application directory name, and not case-sensitive. I think we can look for either application.rb file and use template Spring application context (tweak it with BeanFactoryAware object) or try to load Spring context called app-name-context.xml if applications.rb file is not found. This will be the case for Java applications. For ApplicationAdapter subclass me and Hank come up with app.Application class convention that breaks no Java naming convention because it's hardly imaging that someone would like to use 2 app adapter at the same time 
Directories starting with _ are hidden from web access. Scripted services must be called as name-service.rb, Java services go to app.services package. This is by convention as well.
That is, applications use conventions and typical Spring context tweaked programmatically to wire scripts, script engines from JSR 223 and Red5 itself with Spring. If conventially-names Spring context is given it overrides default one. Conventional context should be called appname-context.xml. We do not configure anything, we load configuration only when it's in place and use default configuration from server directory.
If logger isn't configured (we may add an option to API) then used Log4J and logs directory. Streams can be saved to any location but within streams directory.
Any more comments?
UPD : this was edited after conversation with Hank. We found even better solution so first 3 comments make no sense now.
Hank,
> I think this is ok, but I would like to suggest that there be a default filename that a java programmer can use without
> touching spring
Man, this is impossible, we can force people use packages names.
Web directory is optional and my guess is that most of users wont use Red5 or app server as web server but prefer Apache. But this can be an option, why not?
Posted by 
After some offline discussion Michael and I came to a common ground on a ror-like convention for java apps to be able to, as a default, avoid spring configuration, which is reflected in the current diagram. I am just adding this so that people will not be confused by my comment and michaels comment since they were made before we had our discussion.
I like how the structure is shaping up. One question.. where are persistent share objects stored? Maybe in the _persistance folder and the non-persistent shared objects in the _temp folder? Is there a reason we couldn't just create a sharedobjects folder similar to the streams folder? Not that it's a huge deal but it would consolidate sharedobjects.
I'd say we don't need to create a separate folder for sharedobjects inside the main tree, but can create subfolders in the persistence area for all persistent objects like SOs, scopes, etc.
Non-persistent SOs are not stored in files, they are just kept in memory while they exist.
One thing we must handle with persistence: every scope inside an application can have objects with the same name so we need subfolders inside "_persistence" to keep track of them.
Currently, the folder structure in "persistence" is
"persistence"
|- "scope"
| |- "default"
| |- "<app>"
| |- "<subscope1>".red5 (persistence data for rtmp://server/app/subscope1/)
| |- "<subscope1>"
| |- "<subscope2>".red5 (persistence data for rtmp://server/app/subscope1/subscope2)
|- "SharedObject"
|- "<name>".red5 (SO "<name>" in rtmp://server/app)
|- "<subscope>"
|- "<name2>".red5 (SO "<name2>" in rtmp://server/app/subscope)
Just to understand: what we're talking about here is the folder structure for the WAR version of Red5 that can be dropped in an existing application server, right? How would a standalone version of Red5 look like? Will it be an application server (say Jetty) pre-configured with Red5 as only application?
2Joachim,
Yes, I think so. Being consistent is good and I like the idea of scope separation although it's not a big deal for me.
2Jake,
Correct. And Joachim is right, we need to separate scope to avoid name conflicts...
Several comments
1. Application Configurations
It's fine to use default settings when spring configuration is not defined by app devs but I think it's better to let app devs to override everything from spring conf. So I propose the following configuration process:
a. appname-context.xml is searched firstly and if it exits, all properties like the app main file, the dir for streams, services and others can be overridden. If these properties are not defined in xml, the default value is used.
b. if appname-context.xml doesn't exist or app main file is not defined, application.rb, application.js or other script main files are used. If none of these files can be found, app.Application is searched on classpath.
c. both script services and java services can be defined in xml and the default value for script is "services" and for java is the package "app.services".
d. I don't find any point to differentiate app built in scripts from app built in java. The dir layout should be almost the same IMO.
2. Web content
Red5 is mainly a communication server not a web server so the web content in each app had better be defined by app devs whether it follows ruby's convention or others. What we define is just a dir named whatsoever "web" or "www" (I prefer the latter).
Steven,
Maybe my description wasn't clear enough but this is exactly what I thought of. Context, when found, overrides conventions. If not, then convention way we go.
Joachim wrote this:
>Just to understand: what we're talking about here is the folder structure for the WAR version of Red5 that can be
>dropped in an existing application server, right? How would a standalone version of Red5 look like? Will it be an
>application server (say Jetty) pre-configured with Red5 as only application?
I think that is exactly what we should do. The standalone is the same thing as the WAR version in every way except that it's prepackaged as an application with Jetty as the servlet engine. This will certainly prevent the need to branch two versions of the server and will make them work exactly the same way no matter which way one deploys their application.
This was discussed on the mailing list, but I thought that I should add the comment here for clarification.
re: Java applications use minimal Spring context tweaking that is fine for Java devs.
I think this is ok, but I would like to suggest that there be a default filename that a java programmer can use without touching spring. If you want to get more fancy with more services then spring would be necessary, but I think some default "convention like" behavior would really be a good thing. In general, the less touching of configuration files when learning is best.
Other than that, I really like the server directory, which I believe is new (I didnt compare to luke's last one, (so if it was there I forgot) but I like it.
I also like the web directory inside the applications directory, though I am not clear whether it is a requirement or a suggestion. I am guessing that, as I understand it, you wouldnt need that directory to exist at all or to be called "web". But even still it is a good convention, required or otherwise, and it looks quite neat.