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.
On May 8, 2012, at 4:04 PM, Jeff McCune wrote:
> On Tue, May 8, 2012 at 2:59 PM, Daniel Pittman <dan...@puppetlabs.com> 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
> 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?
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.