[Bf-taskforce25] data api proposal

[Joshua Leung]

Hi,

A few comments regarding this proposal and/or notes on details of the way I
had attempted it:
* The reason why my attempt was written in Python was mainly because it was
an easier language to quickly "whack-together" some code which would parse
the C-code. Also, by using python, there are some niceties we can introduce
into the way of defining info embedded in comments (see my sdna2kt.py
approach for details). There wasn't much of an issue with the mixing of the
two languages, as the job of any python code was merely to autogenerate the
c-code to use as the api.

* Regarding the embedding of info in comments inside the headers - one of
the main issues this aimed to solve was to prevent having a situation where
definitions for various attributes of properties (i.e. name, limits, etc.)
were spread out over several lists/arrays/whatever (like the current IPO
system, which is hellish in that regard), by defining everything about a
SINGLE location. Everything that is necessary to define is set out there,
right beside the member of the SDNA data that it is intended to work on.
Thus, it becomes harded for people to make mistakes regarding defining vars
more than once or skipping some (more on that later). In the process, the
SDNA gets documented. This is also a rather compact form when it comes to
maintainence, as definitions are quite compact (to make sure they fit
nicely).

However, that is really just the definitions that need to be converted into
another form that can actually be used by Blender. This proposal does cover
this well, however, in terms of compactness, the function-call mechanism is
a bit yuck IMO. It's rather more verbose than would be nice to have, and
also, what are the implications for startup time? Sure, the UI code does
stuff like this all the time, though there it's much fewer items. Perhaps,
compressing some of these function calls into functions which set a number
of related aspects of a property together would be helpful?

Also, this raises the auto-generation issue. If we are to autogenerate, then
when is this done? By makesdna - in which case will it dump out a file (or a
few) with the necessary code, and what will happen to those things that need
special tweaks? At runtime - how do we define any special cases then?
Manually run as a tool - once again, how do we reapply any tweaks that are
inevitable? Would the autogeneration redo the entire set of mappings or only
those in certain areas? Even if it only redid parts, how much work would be
required to manually port back any special tweaks?

* I see that this covers arrays, vectors, and such. How would this apply to
things like "LocX"/loc[0] or "QuatZ"/quat[3]?  Although the IPO-system notes
are not done in the version of the proposal I read, it appears that there
isn't really much provision for this sort of stuff? If these were treated as
vectors, then this would be fine for a large number of places, except the
anim system, where single value <=> ipo-curve, and also the UI to some
degree.

Regards,
Joshua (aka Aligorith)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-taskforce25/attachments/20080928/80686dd3/attachment.htm