[Openicc] Gsoc2010 - oyranos API stabilization project

Kai-Uwe Behrmann ku.b at gmx.de
Thu Apr 1 11:49:10 PDT 2010


Am 01.04.10, 19:08 +0300 schrieb Yiannis Belias:
> Hi,
>
> OK, so here is a list of the Modules and the proposed actions to be taken:
> o Miscellaneous->Generic Objects
> o Miscellaneous->Values Handling
> o Module APIs
> o Device API
> o Profile API
> o Named Colour API
>
> (a) Simplify the interconnections of objects.

Objects in Oyranos are currently used with intime knowledge. This 
is often tricky and not easy to understand. Objects should, IMO, typical 
expose only the oyStruct_s structure members [1].
E.g. the complicated oyConfig_s structure[2] would be exposed with the 
oyStruct_s members only, but still typed as oyConfig_s. The oyConfig_s_ 
internal structure will be visible only in its own file, say 
oyranos_config_s.c . Access to the private members is possible 
through the to be exposed functions with a oyConfig_s * object 
argument[3].
Possibly a oyConfig_s flawor of type oyDevice_s would be a useful add[4].
The generic struct members of oyStruct_s still allow to handle the data 
in lists or other data structures. E.g. the caching code does not need 
to know about internals of cached objects. oyStruct_s members are enough.
[5]


In case where a interface is appropriate, say in the module vtables, it 
would suffice to expose only the common parts of a interface and hide more
specialised members.
Say the oyCMMui_s[6] can, beside oyStruct_s, expose a version member and 
say some simple string API, which is useful in a module selection UI. The 
real options and XFORMS style stuff is private and APIs to oyCMMui_s can 
be added later. This allowes now for static UIs convincing for instance 
the SANE module. More complex structures based on oyCMMui_s with callbacks 
for interaction and validation can be designed later. Or in other words 
SANEs oyCMMui_s object would still be compatible with newer extented 
oyCMMui_s objects. The real structures would then eigther be called 
oyCMMui1_s, oyCMMui2_s or the oyCMMui_s objects version[7] does change.

What this code reorganisation would aim is
* a object oriented C API with compile time safety (API and ABI wise)
* enough transparency for common debuggers as it is provided now and new
* flexibility for further development
* ... (not shure what else might be important to keep in mind)

> (b) Change the implementation code of objects to use an internal and public
>   API by using the code generator. Copy the rest of the already existing code to new object.
> (c) Create test cases.
> (d) Write documentation.
>
> (a) seems a little fuzzy right now, it probably needs some conceptual work first
> to reorganize the object dependencies.

Heartedly agreed. Clearing some of the fuzzyness from the Oyranos code 
base is a big part of that GSoC project ;-)
I would love to see the dependencies to minimise during reorganisation.


To the list readers, last years work of students during GSoC on the 
device modules was a great experience. They helped during that project a 
lot by pointing out weaknesses and ambiguities in the APIs and 
documentation.


> So, I hope I'm getting this right. Any additions/modifications to this plan?
>
> Cheers,
> Yiannis


kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org

[1] http://www.oyranos.org/scm?p=oyranos.git;a=blob;f=oyranos_alpha.h;h=7e436439e3956fc587de1786c08e9da152f4f2f4;hb=master#l207
[2] http://www.oyranos.org/scm?p=oyranos.git;a=blob;f=oyranos_alpha.h;h=7e436439e3956fc587de1786c08e9da152f4f2f4;hb=master#l1067
[3] http://www.oyranos.org/scm?p=oyranos.git;a=blob;f=oyranos_alpha.h;h=7e436439e3956fc587de1786c08e9da152f4f2f4;hb=master#l1106
[4] http://www.oyranos.org/scm?p=oyranos.git;a=blob;f=oyranos_alpha.h;h=7e436439e3956fc587de1786c08e9da152f4f2f4;hb=master#l1531
[5] http://www.oyranos.org/scm?p=oyranos.git;a=blob;f=oyranos_alpha.h;h=7e436439e3956fc587de1786c08e9da152f4f2f4;hb=master#l535
[6] http://www.oyranos.org/scm?p=oyranos.git;a=blob;f=oyranos_cmm.h;h=b1730e30aafe83068637b01e717592c78a3e0fc4;hb=master#l876
[7] http://www.oyranos.org/scm?p=oyranos.git;a=blob;f=oyranos_cmm.h;h=b1730e30aafe83068637b01e717592c78a3e0fc4;hb=master#l894


More information about the openicc mailing list