Difference between revisions of "Uno/To-Dos"
From Apache OpenOffice Wiki
< Uno
m (added some more items) |
m |
||
Line 31: | Line 31: | ||
* man pages | * man pages | ||
* various IDE integrations | * various IDE integrations | ||
+ | * connection parameters in environment descriptions for URP environments | ||
Revision as of 11:49, 18 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
- connection parameters in environment descriptions for URP environments
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