On Tuesday, May 8, 2012 7:17:33 PM UTC-4, Andy Parker wrote: > > I'll chime in on this now, I suppose. > > You are right that both read and write operations are good for > abstraction. The problem comes that comes into play is that read and write > operations usually end up with completely different needs for their > abstractions and so combining them together in a single system can be > problematic (this is the basis for the CQRS architectural design). So > although you can combine the write model and the read model in the same > application, they often will have little to do with each other and so you > might as well keep them separate. >
Can you clarify "separate"? Hiera is the thing that has a plugin system and delates lookups to the backend (plugin). The plugin returns a response. The plugin can be simple or very complex in how it goes about fetching the data. The only thing Hiera provides is a common interface for doing lookups. Based on your response, I'm still not clear why we cannot do the same thing for save. I can see your argument for why this is a bad thing in general, but why is it a bad thing for Hiera? > > On May 8, 2012, at 4:04 PM, Jeff McCune wrote: > > On Tue, May 8, 2012 at 2:59 PM, Daniel Pittman <[email protected]>wrote: > >> > The idea is that this simple save function would be behind a REST API >> like >> > the one you mention. Do the hard work of modeling and capturing data >> then >> > make a call to Hiera#save. If a REST API for Hiera is needed we can >> build >> > one. >> >> ...but the save function proposed is too abstract from the reality of >> data storage to be able to do that. Each backend needs additional >> context - or someone to write a custom back-end for their site, ever >> time - to be effective. >> > > What additional context is necessary? > > Why would custom back ends be necessary if the default one we use supports > writability? > > >> This is a good idea, but at the wrong level of abstraction. > > > I'm not yet convinced this is the wrong level of abstraction. If I > understand your original email, you mentioned building tools that > understand the semantics of specific back end storage systems in order to > write data into the system. That seems to defeat the whole point of a > robust plugin system. > > If read operations are good enough to warrant abstraction, surely write > operations are too. Right? > > -Jeff > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/puppet-dev?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-dev/-/6j67wPa8zBQJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
