Changes

ServiceResponse data structures and generation

91 bytes added, 00:33, 24 January 2011
Statelessness
===Statelessness===
(Not sure this is actually true any longer, working to make it not so. jrochkind jan 2010). Service logic should generally be written to be state-less. The same Service object, defined in services.yml, is initialized once and generally re-used for the life of an application instance (cached by ServiceList). So any state you store can end up persisting from request to request and session to session, which you probably don't intend. Umlaut architecture for background services also involves threads and forks, and while there's normally no reason a given service object would be in two threads simultaneously, better safe than sorry. It's safest to store no non-universal state in the service object.
===Disclosure methods===
Anonymous user