[PD-dev] data "fields" - pure enough?

[notyves]

wondering what mathieu's 'fields' addition to m_pd.h is to look in practice..saw a mention of 'bitmask', does this mean an incremental update of say, the 2nd and 5th attributes woudl look something like this?

x252115:1 update 010001000 2.45555 rofl

this is an extra step for the client to figure out (i already know im updating 'leetness' and 'grunt', but now have to look up which field it is..) and continues the tradition of unreadable patches..where you have to get out some kind of field reference, proably only existing in the pd source somewhere, to decode it.. ( i mean sure, x y the first couple are easy but then it rapidly descends..)

toxy uses a key->value structure so the message would look more like 

x252115:1 #leetness 378.0 #grunt ugh

im not a fan of the # prefix either, (and requiring them all the time could bloat file-size and network bandwidth...but an optional method would be great) but like the idea of key-value hash..especially in terms of patch readability and dynamically updating attributes via msg..or from a client GUI (how do yo update a iemgui dynamically, deconstruct the fields into some crazy 15-element message?)

from a brief glance it looks like miller's data structures use a key-value idea, at least from the users standpoint, i mean [set template3 h] is exactly how youd do the same thing in tcl: [dict set template3 h 10].. and are converted to raw fields of data (seperated with escaped ";" !)

so my question is, are the new devel_'s GUI fields the same as pd's datastructure_gui fields? if not, why not? one of hte main reasons ive been hacking around with GUI stuff is i loved the _concept_ of the data-structure GUIs but realized it would need little snippets of tk or perhaps openGL to make the datastruct views more useful (and get better control data back). inveting yet another format is a great way to contribute to the confusion.. but i admit i am NOT a fan of this new msp(d)-0.39 w(0:100)(0-38) nonsense, what the heck is that?!?!