Should we discontinue OnPre?

[bruno-brant]

Liquid.OnPre is a implementation of Liquid abstractions for an on premises deployment.

Currently, while the project exists and some implementation was made, as we can see from issues such as #95 , #96 and #97, they are pretty raw.

My question is: do we need it? Are there projects using this implementation?

If so, then, what is the proposed architecture for that deployment? FileDb certainly shouldn't be used in production (or anything other than the simplest of tests, as we can see from #95), and messaging is simply not done.

The fact of the matter is that while on Azure, AWS and Google there is usually a single option for each of the services needed, on premises the number is vast. One could be using CouchDb, MongoDb, RavenDb etc. for NoSQL storage, WMQ, RabbitMQ, ApacheMQ etc. for messaging, and god knows how many APM solutions.

Therefore, I think we could either:

• Forgo providing OnPre and let customers provide their own implementations, when desired. That would render Liquid less effective on on premises scenarios, but saves us a lot of work maintaining those components.

• Decide on a recommended architecture for an on premises deployment, and provide components for that. This means dropping a number of implementations done and providing more solid ones.

[dwjobling]

I've been following the recent exchange. In my experience, even with selecting the most likely and most popular components there is a high probability that it won't be usable as-is for any one instance. But there remains value in having OnPre and so I'm inclined towards option 2. This is also an excellent opportunity for other contributors.

For the implementations we have we should review them and caveat them for use. I'm sure there is a good use case for FileDB somewhere (3rd party configuration?) but a MySQL option may be more useful as an implementation example. We should remove the ones that are simply not implemented or implement them.

[guilhermeluizsp]

While I agree that providing default implementations for this scenario is a good choice, I'm still not convinced that people would use them without replacing at least half of the default services, so, IMHO it's not worth the effort. But I'd love to create extensions (aka cartridges) for them, although I'd not create them inside the Liquid itself (this repository), but rather in separated repositories (just like Serilog does). I'm between option 1 and 2.