Difference between revisions of "Uno/To-Dos"

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