I'm not sure.
Storing as a dict sound like the same as annotations, but storing as a single attribute instead of object per tile data dict. Sure annotations could be reconsidere. They did allow concurrent writes of tile data, and Castle CMS seems to be ok with just using big connection cache for keeping them warm.
I'm still considering ugly query string serialization, because that's been in plone.tiles from the beginning and the serializer in plone.tiles is pretty well tested. But I admit, I have pretty blind belief in the original HTML-based Deco manifest. I'd also like to use it to optimize the rendering in the following way.
In Castle CMS:
Static (shared and centrally managed) content layout may contain tiles with syntax
When a content with that static layout is created and tile configuration is customized, values from that querystring are use as a default value, but customized values are saved as tile annotatation with id
When content is rendered, tile is called with URL
./@@tiletype/tileid?var1=foo&var2=bar, but data from annotation storage is preferred over the default values from query string.
I'm thinking, if we could go back to original transient tiles idea with the following
Static (shared and centrally managed) content layout could still contain tiles with syntax
When a content with that static layout is created and tile configuration is customized, a tile URL with customized values would get saved into
content attribute HTML storage
When content is rendered, tiles from
content attribute would be merged into layout after "panel merge", so that before "tile merge" tile URL would look like good old transient tile
With query string serialization, this could be done without de/serialization in 3. and also tile rendering could be done without tile data lookup.