[sr-dev] git:master: sl Minor README updates (file name changes)

Daniel-Constantin Mierla miconda at gmail.com
Fri Dec 21 17:15:51 CET 2012


On 12/21/12 11:01 AM, Olle E. Johansson wrote:
> [...]
>>> At the end I wouldn't be against of having a (new) 'standard' way, but it has to be defined with some clear patterns/rules, because what you started to use as new name was not a 'standard' pattern so far.
>> Ok. What's the proposal? I would prefer kamailio style file names and <book> as the main item in the <modname>.xml file.
> The Kamailio way is better, when comparing HTML output.
The output is probably a matter of the root tag in the xml docs. All 
htmls are generated by the same command and use the same css file.

To put a bit more, kamailio inherited the initial structure, which was:
- modname.xml - just the details about the author, editor, etc...
- modname_admin.xml - the admin guide for the module
- modname_devel.xml - the devel guide for the module
- modname_faq.xml - the faq guide for the module

But 99% of the modules have only admin guide. This file became quite big 
for some files and I guess ser guys decided to split it in: params.xml, 
functions.xml, rpc.xml, ... Also, the first chapters (like short 
descriptions, dependencies) were moved to modname.xml. I think ser went 
for section as root tag for its docs, to be able to build one book, by 
including all the other xmls. Not sure it can be done anumore if the 
root tag is book for each module.

At the end the content is the same structure, but kept in different files.

Can't say by now which broken-files structure is better. Let's see if 
there are other opinions.

But I would prefer to be something to stick with for long time if decide 
to change massively. For me is more important the internal structure 
(e.g., the chapter for listing the functions to be named 'Functions').

Cheers,
Daniel
>
> Any other opinions?
>
> /O

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda




More information about the sr-dev mailing list