hi Guenter,
the main advantage of the proposal is simplicity. Another advantage is, that it is equivalent to the preset api in max, yet simpler, and different enough to avoid copyright claims. Besides, it works out-of-the-box (I have already done a preset's prototype, in order to test it).
The main point is that both validation, and object selection, is done in a client code. So, it is up to a client code to use symbolic ids, once these are available.
For my part, I do not feel they are needed so badly. What most users expect, is to be able to drop a [preset] object on a patch, and click on it. For more demanding users, there are various ways of including or excluding objects. The [preset] in max includes all guis in a patch by default (except [table]), and uses connections drawn from its outlets for specifying exceptions. This is a flat scheme, though -- subpatches and abstractions need their own [preset]s (synchronization is pretty easy).
Checking symbolic ids should be just another way, used by another client. Yet another could be based on the 'flags' argument and return value of the statefn call, as designed in the proposal ``for future use''.
Also with validation, just checking object's serial number against its class name should do for recalling from memory. An additional xy check, and a simple warning if failed, seems ok for loading from a file. There is no danger of corrupting things, because an object is guaranteed to handle restoring request -- the requst being a simple pd_forwardmess() call, which passes atoms stored by the object's class' statefn function. If this happens to be another object of the same class, then a user would probably figure out that the edits have been made, without much confusion (ask maxers).
Without knowing Miller's opinion, we are probably wasting our time, though...
Krzysztof
guenter geiger wrote: ...
It is a good thing to have an official API for saving state. In the case of state the API doesn't really help
why is it so, btw?