We¹ve implemented our own userprefs osapi service (yes, we dumped the whole idea of sitting on top of appdata). As I understand it the calls to our service will be asynchronous. Recently Dan Dumont made some changes to the common container layer to support a callback for GET_PREFERENCES so that we didn¹t try to render the gadget before the GET had completed.
I need some help understanding the SET side of things. A gadget could call SET for each userpref in rapid succession. It¹s possible 2 of these could be handled simultaneously at the service layer (it¹s not only possible, we are hitting it EVERYTIME with the horoscope gadget). Thus it¹s possible we could get a constraint violation on the database side (we are creating a master record that references the userpref values). Two values could try to create the master record simultaneously. Even if we flattened that out and didn¹t do the master record, the gadget COULD still set the same value twice in rapid succession and we¹d run into the same problem. So, it the right solution to return a 409 (conflict) from the service and have our container userprefs layer retry? And doesn¹t this same issue exist from gadgets who are calling appdata (or any osapi write service for that matter)? Should our services be trying to prevent this or only reporting errors? Is there some shindig construct that helps with this? Your help is appreciated. Thanks, Doug
