Difference between revisions of "Uno/To-Dos"
From Apache OpenOffice Wiki
< Uno
m |
m (added some more items) |
||
Line 18: | Line 18: | ||
* remove "#ifndef EXCEPTIONS_OFF" macros | * remove "#ifndef EXCEPTIONS_OFF" macros | ||
* SAL_CALL really necessary for "inline" stuff? | * SAL_CALL really necessary for "inline" stuff? | ||
+ | * a unified command line interface for all UNO tools | ||
Features | Features | ||
Line 24: | Line 25: | ||
* move the UCB into the URE | * move the UCB into the URE | ||
* move the configr mgr. into the URE | * move the configr mgr. into the URE | ||
− | * alien type support e.g. for Java | + | * alien type support e.g. for Java (e.g. a type description provider implemented in Java based on Java reflection) |
* web services bridge | * web services bridge | ||
+ | * (remote) proxy detection - needed for remote detection and local optimizations | ||
+ | * Zones | ||
+ | * man pages | ||
+ | * various IDE integrations | ||
+ | |||
+ | |||
General | General |
Revision as of 08:32, 11 April 2006
ToDos and potential ToDos
module naming
- rename cppu -> binary uno
- rename cppuhelper -> cppu
clear separation between C and C++
- move C++ stuff from cppu to cppuhelper
simplification / performance
- remove
uno_Interface
and friends, replace with one of the platform C++ ABIs - support direct access of UNO types in IDL, without includes
- let the *makers retrieve type information from the type providers and not from rdb files
- harmonize initial object access for "remote" and libraries, it is actually the same
- leverage purpose environments for global variables, e.g. the "ServiceManager" or the "ComponentContext"
- Remove all exception specifications.
- Consolidate "uno_Environment" with "uno_ExtEnvironment".
- remove "#ifndef EXCEPTIONS_OFF" macros
- SAL_CALL really necessary for "inline" stuff?
- a unified command line interface for all UNO tools
Features
- introduce process lifecycle based on living threads
- have UNO package support for the URE
- move the UCB into the URE
- move the configr mgr. into the URE
- alien type support e.g. for Java (e.g. a type description provider implemented in Java based on Java reflection)
- web services bridge
- (remote) proxy detection - needed for remote detection and local optimizations
- Zones
- man pages
- various IDE integrations
General
- standardize?
Comments
How about type providers for Java Archive files, .NET assemblies?
That way, we can hold types the way that best fits, i.e. the target language of the component (→ no need to deploy both rdb and jar anymore). And this embraces the "*makers read from type manager/type providers" feature (→ I can generate types for lang A out of types from lang B without an intermediate format).
- This is basically what I meant with "alien type support" ~~kr