Difference between revisions of "Uno/To-Dos"

Revision as of 07:07, 4 July 2006

ToDos and potential ToDos

General

• Move documentation from http://udk.openoffice.org into the Uno wiki (http://wiki.services.openoffice.org/wiki/Category:Uno).

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

The Clear Separation between C and C++ and Core Components ideas sound nice. During the mono-port of cliuno (mostly port from Managed C++ to C#) (not quite complete yet, sorry) I had to make C wrappers for cppuhelper bootstrap stuff (so that I could P/Invoke them). IIRC there was also a part where I wished I had a C API for the shlib loader, can't remember the details, though.

Martin, would you be interested in helping with this? Kr 09:07, 4 July 2006 (CEST)