[Bf-taskforce25] data api proposal

[Brecht Van Lommel]

Hi,

On Mon, 2008-09-29 at 19:51 +0100, André Pinto wrote:
> ===Random thoughts about UI===
> - Having a function like set(..) to verify if the value is inside the
> valid values isnt very usefull to the UI, as we may need to show what
> are the min/max values possible.
> Thats probably the reason why Brecht added min/max values.
> But such a solution will add incoherence between the UI and code..
> because UI might show possible values are [-100,100].. but the code
> inside set function  will for example have a limit like: [-(min Z of
> BB),  (max Z of BB)].
> 
> As so I consider that if we need to callbacks todo data validation...
> we also need a better mode(callbacks also?) to determine the min/max
> values allowed on UI.

OK, maybe we need an (optional) callback to request the min/max for a
property, so it can be dynamic. Some BDR_prop_get_min/max() function
would then use the callback if it is there, and otherwise use the fixed
value (read-only, ui-hidden, pointer type, .. are intended to work the
same way and have both fixed values and callbacks defined in the
proposal). I think this is is quite a special case, only a few
properties need it probably, but we'll need it yes.

> - ""Do we need nested property groups?""
> If this is needed can we still use simple properties like:
> "render.raytrace.max_ray_depth"?

My idea for these groups is that they would strictly be used for UI and
documentation, not the python API.

> ===Access to properties===
> It would be useful to access char/int/long masks like different
> properties:
> (at least on python this would be a must-have)
> obj.renderable = true
> obj.visible = true
> 
> This would make it easier to read and maintain,
> and also create a good layer to separate UI from data internals.

This is the intention, bitflags should be exposed as booleans. The
integer type would be used for just that, integer numbers.

> ===Some other questions/ideas===
> Are callbacks like notify, set, unset, supposed to change on runtime?
> Is there any real advantage if that is true?
> Is this data only going to be used before the compile time to
> auto-generate code?
> 
> If callbacks don't change at runtime then clever code with defines can
> replace most of the get/set with direct code.

The code inside these function would not change at runtime, but I would
prefer to avoid that kind of code with defines. It would be better to
explore using inline functions, or whatever compiler flags can help, so
we get proper type checking and compiler warnings. For a plugin API this
also helps preserve ABI compatibility.

> Since DataAPI will have a deep knowledge on the data structures used
> on blender.. I guess it will also be used to generate the sdna data.
> As so an useful thing to do could be a "don't save" property to avoid
> having some data saved to files. (like caches, or other variables that
> might only make sense at runtime).

This data API is intended to be a layer on top of the SDNA structs, and
it would not affect file saving. It would not actually know much about
how the data is actually stored or with which exact datatypes, that is
abstracted through the get()/set() functions the implementation of which
can be any arbitrary written piece of code.

Thanks for the feedback,
Brecht.