Difference between revisions of "Uno/To-Dos"
From Apache OpenOffice Wiki
< Uno
(→Simplification and Performance: Add bootstrapping to be implemented by global variables.) |
m (→Clear Separation between C and C++) |
||
Line 1: | Line 1: | ||
== ToDos and potential ToDos == | == ToDos and potential ToDos == | ||
− | ===Clear Separation between C and C++=== | + | ===Clear Separation between C and C++ and Core Components=== |
* Move C++ stuff from [http://udk.openoffice.org/source/browse/udk/cppu cppu] to [http://udk.openoffice.org/source/browse/udk/cppuhelper cppuhelper]. | * Move C++ stuff from [http://udk.openoffice.org/source/browse/udk/cppu cppu] to [http://udk.openoffice.org/source/browse/udk/cppuhelper cppuhelper]. | ||
+ | * Move cppuhelper bootstrap stuff to Binary UNO and let it provide a 'C' interface. Implement current cppuhelper API as wrappers. | ||
+ | * Move cppuhelper/shlib.cxx into the library loader. Let the library loader provide a C/C++ API. | ||
+ | * Move cppuhelper/component_context.cxx into into its own core component. | ||
===Module Naming Clean up=== | ===Module Naming Clean up=== |
Revision as of 15:10, 29 June 2006
Contents
ToDos and potential ToDos
Clear Separation between C and C++ and Core Components
- Move C++ stuff from cppu to cppuhelper.
- Move cppuhelper bootstrap stuff to Binary UNO and let it provide a 'C' interface. Implement current cppuhelper API as wrappers.
- Move cppuhelper/shlib.cxx into the library loader. Let the library loader provide a C/C++ API.
- Move cppuhelper/component_context.cxx into into its own core component.
Module Naming Clean up
- Rename module cppu to reflect that it is implementing Binary Uno.
- Rename module cppuhelper to reflect that it is implementing C++ Uno.
- Move the io module from the util project into the into project.
- Move the jut module into the UDK project.
Simplification and Performance
- Remove the Binary Uno ABI (struct uno_Interface) and friends, replace it 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 Uno and components -> it is actually the same.
- Leverage Purpose Bridges for global variables, e.g. the "ServiceManager" or the "ComponentContext". Use this for bootstrapping as well. E.g.
Reference<XComponentContext> cppu::getComponentContext();
always returns the current component context. It is usable in components, libraries or applications and may even bootstrap UNO, if no context is available yet. - Remove all exception specifications.
- Consolidate the Binary Uno structs "uno_Environment" and "uno_ExtEnvironment".
- Remove
#ifndef EXCEPTIONS_OFF
macros, actually C++ Uno is not useable without exceptions anyway. - Is SAL_CALL really necessary for "inline" stuff? If not, remove it.
- Unify 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.
- Uno alien type support e.g. for Java (e.g. a type description provider implemented in Java based on Java reflection).
- A Uno-SOAP Bridge.
- Allow (remote) proxy detection, needed for remote detection and optimizations.
- Zones.
- Write
man
pages. - Various IDE integrations.
- Allow connection parameters in environment descriptions for URP environments, e.g. "urp,socket=<port>,host=<name>".
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