Quote from: myfriendscallmebill at Oct 10, 2008, 11:20 PM
I can’t help but feel that we’re getting too wrapped up in metaphors here. It seems to me that what’s being called a "transport" might more prosaically be called an "installer package", and what’s being called a "vehicle" is an "installer".
As I see it, each vehicle (what I suggest should be called an "installer") is to a first approximation the combination of logic and data needed to add (or install) some capability into MODx. Again to a first approximation, it looks like each vehicle installs something that is complete in and of itself, and so it would not be amiss to all each vehicle an "installer".
As the developer that oversimplifies it for me. This is a part of a generic domain model in xPDO I originally designed to serialize data from any data model into a format that could be easily transported to other database platforms, between dev/staging/production environments, etc. Basically, for flexible distribution of data. It consists of xPDOTransport instances that can contain a sequential manifest referencing intelligent artifact containers, I’ve termed xPDOVehicle. The actions of delivering, packing, unpacking, installing, updating, restoring, and uninstalling a package are potentially only some of the actions that can be taken on packages as we continue to develop xPDO and MODx.
Quote from: myfriendscallmebill at Oct 10, 2008, 11:20 PM
I would think that over time there will be snippet installers, module installers, language installers, file installers and so forth. I would think that what differentiates one type of installer from another is sometimes its purpose (e.g. install a snippet) and sometimes its internal structure.
Actually those things are all data artifacts, potentially combined with other dependent data artifacts and/or file system artifacts. So far almost everything has worked nicely in the generic xPDOVehicle, but we are developing xPDOFileVehicle to hold file system artifacts directly that are not related to a specific data artifact. It’s basically an xPDOVehicle with the main payload representing the file resolver subset normally contained in a regular xPDOVehicle, and the logic to process that payload when various actions are performed on it.
Quote from: myfriendscallmebill at Oct 10, 2008, 11:20 PM
Regarding internal structure, I can envision some installers running a pre-processor (or preflight) script to make sure the necessary preconditions prevail, then running a main script to delete old stuff, install new stuff and make up configuration settings, then running a post-processor to test that all has gone well or to restart a process, etc. I can also envision some installers having just a single script that handles everything. I can also envision some installers that are labeled in a canonical way and have a canonical set of contents for which MODx has built-in logic to do the whole job. Maybe the xPDOVehicle, which Jason in reply #14 calls "the default Vehicle class" is one such installer type.
Again in Jason’s reply #14, he calls the preflighting action a "validator" and the wrap-up action a "resolver". Maybe those terms make the best sense for an installer following the generic xPDOVehicle pattern. I don’t know what’s really going on there.
That is all xPDOVehicle specific; those things are simply attributes stored in the payload of a vehicle instance which the base class knows how to process. A derivative class can store whatever attributes it wants, and provide logic to process those attributes in any way it wants.
Quote from: myfriendscallmebill at Oct 10, 2008, 11:20 PM
But at the very least I’d suggest we just call the top two levels of encapsulation "installer packages" and "installers", rather than "transports" and "vehicles".
At the end user level, we can call them however we would like, and maybe that makes the most sense. But I also hold that my metaphor is accurate and that these zip files representing an xPDOTransport will come in a variety of shapes and sizes; Add-On Packages, Core Extension Packages, Theme Packages, Jason’s Snippet Collection Package, Sample Content Packages, Security Policy Template Packages, an all-in-one Blogger’s Package, Promotion Packages for developer workflows, etc., etc. I think everyone will eventually see that these are more than simple installers and uninstallers.