Difference between revisions of "Uno/To-Dos"

From Apache OpenOffice Wiki
< Uno
Jump to: navigation, search
m (ToDos and potential ToDos: Added "General" section.)
m (Removed redirects. "Include" to-dos.)
 
(33 intermediate revisions by 6 users not shown)
Line 1: Line 1:
==ToDos and potential ToDos==
+
To-Dos and potential To-Dos.
 +
<noinclude>[[Category:Uno]] [[Category:To-Do]]</noinclude>
 +
==General==
 +
* Move documentation from http://udk.openoffice.org into the [[Uno|Uno wiki]], see [[Uno/Effort/Migrate Documentation]] for details.
  
===General===
+
==[[Uno/Todo/Clear Separation of C and Cpp and Core Components|Clear Separation of C and C++ Uno]]==
* Move documentation from http://udk.openoffice.org into the Uno wiki (http://wiki.services.openoffice.org/wiki/Category:Uno).
+
{{:Uno/Todo/Clear_Separation_of_C_and_Cpp_and_Core_Components}}
  
===Clear Separation between C and C++ and Core Components===
+
==Bugs==
* Move C++ stuff from [http://udk.openoffice.org/source/browse/udk/cppu cppu] to [http://udk.openoffice.org/source/browse/udk/cppuhelper cppuhelper].
+
* Move the module {{Uno/UDKlink|api|udkapi}} from [http://api.openoffice.org/ API] project into the [http://udk.openoffice.org Uno] project.
* Move cppuhelper bootstrap stuff to Binary UNO and let it provide a 'C' interface. Implement current cppuhelper API as wrappers.
+
* Fix {{Uno/UDKlink|cli_ure}} dependency against {{Uno/UDKlink|offapi|api}}.
* Move cppuhelper/shlib.cxx into the library loader. Let the library loader provide a C/C++ API.
+
* Fix {{Uno/UDKlink|cpputools}} dependency against {{Uno/UDKlink|offuh|api}}.
* Move cppuhelper/component_context.cxx into into its own core component.
+
* Move the module {{Uno/UDKlink|io|util}} from the [http://util.openoffice.org/ util] project into the [http://udk.openoffice.org Uno] project.
 +
* Move the module {{Uno/UDKlink|jut/util}} into the [http://udk.openoffice.org Uno] project.
 +
* [http://udk.openoffice.org/issues/buglist.cgi?Submit+query=Submit+query&issue_type=DEFECT&issue_type=ENHANCEMENT&issue_type=FEATURE&issue_type=PATCH&component=udk&issue_status=UNCONFIRMED&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&issue_status=RESOLVED&email1=&emailtype1=exact&emailassigned_to1=1&email2=&emailtype2=exact&emailreporter2=1&issueidtype=include&issue_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&short_desc=&short_desc_type=allwords&long_desc=&long_desc_type=allwords&issue_file_loc=&issue_file_loc_type=substring&status_whiteboard=&status_whiteboard_type=substring&keywords=&keywords_type=anytokens&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&order=%27Importance%27 Query for Uno bugs]
  
===Module Naming Clean up===
+
==Naming / Clean up==
* Rename module [http://udk.openoffice.org/source/browse/udk/cppu/ cppu] to reflect that it is implementing [[Uno/Binary | Binary Uno]].
+
* Rename module {{Uno/UDKlink|cppu}} to reflect that it is implementing the [[Uno/Binary|Binary Uno]] runtime.
* Rename module [http://udk.openoffice.org/source/browse/udk/cppuhelper cppuhelper] to reflect that it is implementing [[Uno/Cpp | C++ Uno]].
+
* Rename module {{Uno/UDKlink|cppuhelper}} to reflect that it is implementing the [[Uno/Cpp|C++ Uno]] runtime.
* Move the [http://util.openoffice.org/source/browse/util/io/ io] module from the [http://util.openoffice.org/ util] project into the [http://udk.openoffice.org into] project.
+
* Rename the [[Uno/Binary|Binary Uno]] to JNI (Jave Native Interface) bridge: java_uno -> jni_uno. Because that is what the bridge is about.
* Move the [http://util.openoffice.org/source/browse/util/jut jut] module into the [http://udk.openoffice.org UDK] project.
+
* Rename the [[Uno/Binary|Binary Uno]] to [[Uno/Remote|Remote Uno]] bridge: urp_uno -> remote_uno. Because that is what the bridge is about (actually, there is no URP object to program against, at least not in [[Uno/Binary|Binary Uno]]).
 +
* Remove the "lib" prefixes under UNIX from the [[Uno/Binary|Binary Uno]] bridges.
 +
* Rename {{Uno/UDKlink|cpputools}} to something like "unotools" (unfortunately this name is already in use).
 +
* Mark SAL_IMPLEMENT_MAIN_WITH_ARGS as deprecated, the right way to deal with args are the RTL command line arg functions, see {{Uno/UDKlink|sal/inc/rtl/process.h|porting}}
  
===Simplification and Performance===
+
==Simplification and Performance==
* Remove the Binary Uno ABI (struct uno_Interface) and friends, replace it with one of the platform C++ ABIs.
+
* Remove the [[Uno/Binary|Binary Uno]] [[Uno/Term/Object Binary Interface|Object Binary Interface (OBI)]] (struct uno_Interface) and friends, replace it with one of the platform C++ OBIs.
* Support direct access of Uno types in [[Uno/Spec/IDL | IDL]], without includes.
+
* Support direct access of Uno types in [[Uno/Spec/IDL|Uno IDL]], without includes.
 
* Let the *makers retrieve type information from the type providers and not from rdb files.
 
* Let the *makers retrieve type information from the type providers and not from rdb files.
* Harmonize initial object access for [[Uno/Remote | Remote Uno]] and components -> it is actually the same.
+
* Harmonize initial object access for [[Uno/Remote|Remote Uno]] and components -> it is actually the same. E.g. <pre>"uno:library;[gcc3];<implementation name>"</pre> may be used to access an instance factory, or any other object of interest.
* Leverage [[Uno/Spec/Purpose Bridge|Purpose Bridges]] for global variables, e.g. the "ServiceManager" or the "ComponentContext". Use this for bootstrapping as well. E.g. <pre>Reference<XComponentContext> cppu::getComponentContext();</pre> 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.  
+
* Leverage [[Uno/Spec/Purpose Bridge|Purpose Bridges]] for global variables, e.g. the "ServiceManager" or the "ComponentContext". Use this for bootstrapping as well. E.g. <pre>Reference<XComponentContext> cppu::getComponentContext();</pre> 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.
 
* Remove all exception specifications.
* Consolidate the [[Uno/Binary | Binary Uno]] structs "uno_Environment" and "uno_ExtEnvironment".
+
* Consolidate the [[Uno/Binary|Binary Uno]] structs "uno_Environment" and "uno_ExtEnvironment".
* Remove <code>#ifndef EXCEPTIONS_OFF</code> macros, actually [[Uno/Cpp | C++ Uno]] is not useable without exceptions anyway.
+
* Remove <code>#ifndef EXCEPTIONS_OFF</code> macros, actually [[Uno/Cpp | C++ Uno]] is not usable without exceptions anyway.
 
* Is SAL_CALL really necessary for "inline" stuff? If not, remove it.
 
* Is SAL_CALL really necessary for "inline" stuff? If not, remove it.
 
* Unify command line interface for all Uno tools.
 
* Unify command line interface for all Uno tools.
 +
* Convert the ProxyFactory service into a library and deprecate it.
  
===Features===
+
==Features==
 
* Introduce process lifecycle based on living threads.
 
* Introduce process lifecycle based on living threads.
* Have Uno package support for the [[Uno/Spec/Ure | URE]].
+
* Have Uno package support for the [[Uno/Spec/Ure|URE]].
* Move the [http://ucb.openoffice.org UCB] into the [[Uno/Spec/Ure | URE]].
+
* Move the [http://ucb.openoffice.org UCB] into the [[Uno/Spec/Ure|URE]].
* Move the [http://util.openoffice.org configr mgr.] into the [[Uno/Spec/Ure | URE]].
+
* Move the [http://util.openoffice.org configr mgr.] into the [[Uno/Spec/Ure|URE]].
 +
* Move the most useful helpers from comphelper into the [[Uno/Spec/Ure|URE]].
 
* Uno alien type support e.g. for Java (e.g. a type description provider implemented in Java based on Java reflection).
 
* 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.
+
* A Uno-SOAP Bridge. [http://udk.openoffice.org/common/man/draft/soap.html Some considerations]
 
* Allow (remote) proxy detection, needed for remote detection and optimizations.
 
* Allow (remote) proxy detection, needed for remote detection and optimizations.
 
* Zones.
 
* Zones.
 
* Write <code>man</code> pages.
 
* Write <code>man</code> pages.
 +
* Write a DBUS bridge.
 
* Various IDE integrations.
 
* Various IDE integrations.
* Allow connection parameters in environment descriptions for [[Uno/Remote/Spec/URP | URP]] environments, e.g. "urp,socket=<port>,host=<name>".
+
* Allow connection parameters in environment descriptions for [[Uno/Remote|remote]] environments, e.g. <pre>"remote[urp,socket=<port>,host=<name>]"</pre>
 +
* Bridge the interface gap e.g. of Java and C++ Uno - AKA know as "smart mapping".
 +
* Graphical and Command line tool for registry data modification.
 +
* [http://udk.openoffice.org/common/man/draft/com_lang_spec.html COM Bridge]
 +
* [http://udk.openoffice.org/common/man/concept/uno_corba.html CORBA Bridge Concept Paper]
 +
* [http://udk.openoffice.org/common/man/draft/logging.html Logging support]
 +
* [http://udk.openoffice.org/cpp/man/draft/stacktraces_for_exceptions.html Exceptions with Stack Traces]
 +
* [http://www.openoffice.org/issues/show_bug.cgi?id=75053 Issue 75053: Language binding support for service contstructors]
  
 
+
==Tests==
 
+
* [http://udk.openoffice.org/common/man/tasks/apitests.html API Tests] - Help implement API tests.
===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 (&rarr; no need to deploy both rdb and jar anymore).
+
And this embraces the "*makers read from type manager/type providers" feature (&rarr; 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]]
+
 
+
[[Category:Uno]]
+

Latest revision as of 08:48, 18 June 2007

To-Dos and potential To-Dos.

General

Clear Separation of C and C++ Uno

There are various obstacles in the way to cleanly separate C Uno (AKA Binary Uno) from C++ Uno. Some of these are

  • the C Uno runtime is implemented in C++,
  • a C++ Uno runtime would be stacked on top of C Uno,
  • there is no living C language binding,
  • the C++ Uno runtime offers various functions for bootstrapping Uno, which are not yet available for Binary Uno.
  • Upper level modules headers may not be used, until they are delivered, even if they are self contained.

Some of the obvious tasks are:

Bugs

Naming / Clean up

  • Rename module udk/cppu to reflect that it is implementing the Binary Uno runtime.
  • Rename module udk/cppuhelper to reflect that it is implementing the C++ Uno runtime.
  • Rename the Binary Uno to JNI (Jave Native Interface) bridge: java_uno -> jni_uno. Because that is what the bridge is about.
  • Rename the Binary Uno to Remote Uno bridge: urp_uno -> remote_uno. Because that is what the bridge is about (actually, there is no URP object to program against, at least not in Binary Uno).
  • Remove the "lib" prefixes under UNIX from the Binary Uno bridges.
  • Rename udk/cpputools to something like "unotools" (unfortunately this name is already in use).
  • Mark SAL_IMPLEMENT_MAIN_WITH_ARGS as deprecated, the right way to deal with args are the RTL command line arg functions, see porting/sal/inc/rtl/process.h

Simplification and Performance

  • Remove the Binary Uno Object Binary Interface (OBI) (struct uno_Interface) and friends, replace it with one of the platform C++ OBIs.
  • Support direct access of Uno types in Uno 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. E.g.
    "uno:library;[gcc3];<implementation name>"
    may be used to access an instance factory, or any other object of interest.
  • 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 usable without exceptions anyway.
  • Is SAL_CALL really necessary for "inline" stuff? If not, remove it.
  • Unify command line interface for all Uno tools.
  • Convert the ProxyFactory service into a library and deprecate it.

Features

Tests

Personal tools