Up to this point in time, CarrierWave has been mostly an experiment.
It was intended that the result of the experiment would live in the continuum between the application server and object database. To provide client side type safety for vertical clients, and enough meta-data for horiztontal clients. And to provide a level of isolation between client and server developers to help maintain a wait free development cycle.
Using only a handfull of verbs and a method for defining graph closure, could a system be built useful enough to overcome the native drawbacks of the applications it would endeavor to replace?
The answer is a tentative "yes". Tentative for two reasons.
One, because there are probably more applications you would be more successful building without CarrierWave than with (in today's world). From a high-level, I would like to try and define atleast one set of these applications that may benefit from CarrierWave later in a different article.
Two is a little trickier. The closure method, or Graph Plan, allows clients to interact with their server in a discrete and atomic way. Instead of faulting in your graph elements on demand, you get the whole thing in one go. Giving a graph plan a symbolic name and storing it on the server (or centralized repository) improves the performance, reduces coupling, and can make a system more supportive of change.
This last bit is the crux. If you think of a graph plan instance as a dynamic type that can in turn be instantiated, you have some great potential.
Consider a graph plan that defines a Purchase Order. You can have a client retrieve the current definition/version of a PO and instantiate it, and possibly apply any rules or default values from the graph plan, before instantiating one business object on your server. It some ways a graph plan can be seen as a DTD (and doing so may be part of the problem).
Sounds great, but is it really useful in the light of the new XML world? I haven't had the luxury to take my experiment very far except in isolated cases and simple mind games. But the obvious question is, if graph plans were to move on to the next level, would you be better off just using a stew of XML specifications?
Also the premise behind CarrierWave is that OO development using adaptive models and the like are still useful. And in my role in the real world, i'm watching the landscape shift from complex object models to well defined messages and orchestrated discrete services. It's all going inside out.
So the ultimate question is: Is what I know that is useful about CarrierWave useful enough to warrant any extra effort in preparing a mature 1.0 distribution?
I guess i should first enumerate what a 1.0 would look like, but if i put "easy to configure, and deploy" on the list, it would trumpet a hefty undertaking in itself.
In an effort to provide federation and distribution, CarrierWave has become crufty and monolothic. It needs to be re-built so that it can be more simply deployed and managed. This essentially means turning it inside out allowing it to be more readily plugged in, instead of plugging things into it.
Over the next week or so I will be wrangling with the idea of continuing on or moving on.
Leave a comment