We recently had a very inofficial real life discussion on the topic of a roadmap for Pike, and started bundling our ideas off the top of our heads. Further discussion is necessary, but to start off somewhere, here is our initial draft of things we find worth pursuing in the near future (say, within the scope of 7.5).
What follows might need a correction or two of what was really meant by whomever said what and some of the issues are probably just another way of phrasing earlier ones. (I trust there will be keen minds busy rectifying what came out weird in my scratch pad. :-)
* Improve the structure of the Pike header files - providing a more defined API for 3rd party pike module authors (today, this is essentially things marked PMOD_EXPORT) - specify an API we intend to be binary compatible with - make a pike lib with a version number - separate the low level implementation details from semantics - easen core changes without the need for recompiling all modules - address the valgrind dependency problem - split configure into two parts; one for the pike, one per module - rename ac_module_init to pike_module_init (we should not borrow autoconf namespace inappropriately) - the environment passing between makefiles and configure is hairy and could use a healthy refactoring
* Extend pikedoc to handle c level APIs, and document them
- Improve the structure of the Pike header files
- providing a more defined API for 3rd party pike module authors (today, this is essentially things marked PMOD_EXPORT)
- specify an API we intend to be binary compatible with
- make a pike lib with a version number
Does this help us to embed pike in others applications ? Eg for example to make a apache mod_pike for example that can help us to promote Pike outside Caudium and Roxen.
/Xavier
- separate the low level implementation details from semantics
What does this mean? Example?
/ Mirar
Previous text:
2003-04-07 19:40: Subject: Pike roadmap
We recently had a very inofficial real life discussion on the topic of a roadmap for Pike, and started bundling our ideas off the top of our heads. Further discussion is necessary, but to start off somewhere, here is our initial draft of things we find worth pursuing in the near future (say, within the scope of 7.5).
What follows might need a correction or two of what was really meant by whomever said what and some of the issues are probably just another way of phrasing earlier ones. (I trust there will be keen minds busy rectifying what came out weird in my scratch pad. :-)
- Improve the structure of the Pike header files
- providing a more defined API for 3rd party pike module authors (today, this is essentially things marked PMOD_EXPORT)
- specify an API we intend to be binary compatible with
- make a pike lib with a version number
- separate the low level implementation details from semantics
- easen core changes without the need for recompiling all modules
- address the valgrind dependency problem
- split configure into two parts; one for the pike, one per module
- rename ac_module_init to pike_module_init (we should not borrow autoconf namespace inappropriately)
- the environment passing between makefiles and configure is hairy and could use a healthy refactoring
- Extend pikedoc to handle c level APIs, and document them
/ Johan Sundström (folkskådare)
pike-devel@lists.lysator.liu.se
-
Johan Sundstr�m (folksk�dare) ＠ Pike (-) developers forum -
Mirar ＠ Pike developers forum
-
Xavier Beaudouin