Difference between revisions of "Uno/To-Dos"

Revision as of 11:37, 21 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

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