Propose a new concept for the structure

[GoogleCodeExporter]

This is our new proposal on the structure. The purpose of this is to be
more easily customizing OpenMeetings.
 This will help for all contributers to create their modules and to commit
it to trunk.
 The points are as following
       - all features are to be plug-in type module
       - contributor could make their module without unnecessary modules
       - generate library file for customization order by administrator tool

Original issue reported on code.google.com by onoke...@gmail.com on 9 Mar 2008 at 2:07

Attachments:

• om2.odp

[GoogleCodeExporter]

thx for the document.

How do want to realize:
*All features should be selectable as plug-in*
I guess you mean recompiling the OpenLaszlo-Source Code.
For changing the Layout of the Interface it is not necessary to recompile the 
code,
you could make it configurable in the Admin-Panel just like other config-keys 
or add
some kind of wizzard / editor to change the Layout or disable certain features 
in a
Conference-Room.

Administrator tools.
Server(s) start stop scripts are provided with each Software. Red5 and 
OpenOffice or
OpenLaszlo do not ship with OpenMeetings, so its quite hard to write a control 
system
which handles these Servers.

About resource-structure:
Its a bit a matter of how you build modules. If you handle all resources 
central, you
cannot use any module without using the hole system and vice versa.
So I tend to store resources and assets in the folder of their component. So 
each
component has its own resource-folder with all needed resources for this 
Module. If
you make it centralized you have to force / teach everybody to store the 
resources in
the scheme and its quite natural that people will break these rules cause they 
want
to include for example an already build module from another application into
OpenMeetings. On the other hand you may want to handle some basic resources 
globally.
So I think you cannot make it that strict.

For the rest I'm fine with that, LZX-Classes need to be structured in a 
different
manner, at the moment its a mixture between historical reasons and needed 
structure.

Original comment by seba.wag...@gmail.com on 9 Mar 2008 at 3:33

• Changed state: Accepted

[GoogleCodeExporter]

1.plug-in
  In the case of changing layout dose not need recompile. Those layout design data(
position, screen transition order ) could be contained into configuration file 
or db.
  But in the case of selecting components ( using *B* video, not *A* video ), we are
imaging the include library file should be recreate order by selecting, and 
main.lzx
also would be recompile to get the swf file.
 For example,
     - there are some modules in the features directory. And you would like to 
       create two conference room on your OpenMeetings. In this case, you can take 
       steps like this.
         (1) Login into administrator tool
         (2) input new conference name ( in this case you may set Room1 and Rom2 )
         (3) select components that you would like to use in Room1
            may be, you would choice "A-type video", "A-type white board" and "A-type
            chat" modules.
         (4) administrator tool would arrange those selected modules into the include 
            library file.
               features/library.lzx
                    > include  src="A-typeVideo.lzx"/<
                    >include  src="A-typeWhiteBoard.lzx"/<
                    >include  src="A-typeChat.lzx"/<
         (5) Then room1_main.swf file would be created by recompiling main.lzx as it 
            has contained this library file as following.
               main.lzx
                    >canvas<
                           > include src="features"/ <
                                      .
                                      .
                    >/canvas<
         (6) After (5) you could open the Room1 conference by room1_main.swf.
         (7) When you create Room2 conference, you could take same steps above.

 Recompiling will run each conference, but it run just in creating it. After that,
each conference will be operating in SOLO mode.

2. Server start/stop scripts
   Yes i know it is not easy, but i think those are need for excellent IT system. You 
   could imagine when you got in face of system trouble on any IT systems, it got your 
   back up if it ordered you about striking shell command. Of cause i did not say to 
   let you do it. 

3. Resource-structure
   I agree with you. I mean it just only using global or common resources should be 
   located in the top level. Other should be located in each module directory.      

Original comment by onoke...@gmail.com on 10 Mar 2008 at 5:15

[GoogleCodeExporter]

okay I agree with you. 
I would like to extend this with *non-conferencing-features* later, meaning if 
you
have some other Modules which go directly in the main-menu you could load them 
using
the same logic.

Original comment by seba.wag...@gmail.com on 10 Mar 2008 at 10:28

[GoogleCodeExporter]

Regarding Issue 353,I have started the wiki for the new directory structure.

http://code.google.com/p/openmeetings/wiki/NewStructure?updated=NewStructure&ts=
1205826808

In the new structure, /conference, /oslmon and /xmlcrm will be gone.
There are /base and /modules instead.

FROM:
/doc
/test
/resources
/conference
/oslmon
/xmlcrm

TO:
/doc
/test
/resources
/base
/modules

I am going to change the whole structure step by step from now on.

Original comment by minamoto...@gmail.com on 18 Mar 2008 at 8:08

[GoogleCodeExporter]

Original comment by minamoto...@gmail.com on 25 Mar 2008 at 10:52

• Changed state: Started
• Added labels: Priority-High, Type-Task
• Removed labels: Priority-Medium, Type-Other

[GoogleCodeExporter]

I will put this onhold for now.

Original comment by seba.wag...@gmail.com on 17 Nov 2009 at 8:48

• Changed state: onHold