next »

[sottwell]

As long as you don't get its (possessive) and it's (contraction of it is) mixed up!

[BobRay]

As long as you don't get its (possessive) and it's (contraction of it is) mixed up!

Something I do all the time as a typo along with typing "you're" when I mean "your" (had to correct it in my post). 

[myfriendscallmebill]

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".

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. 

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.

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". 

Just my two cents,
Bill

[myfriendscallmebill]

This comment refers to functionality not terminology, so I'll put it in its own post.

First, it seems to me that if some things are complicated enough to need installers ("vehicles"), that they will also be complicated enough to require un-installers ("car crunchers" to continue the metaphor...?).

Further, Jason's reply #14, where he outlines the transport/vehicle process, says that a transport contains "a manifest file controlling the order the Vehicles are processed in."  That's fine as the simplest case, but what do we do if a set of vehicles only makes sense if they all install successfully?  Rather than a simple list (manifest) don't we need a master install script which, in its simplest form would be a simple list of vehicles, but would also have the ability to have some logic; so that it could be make to monitor the parade of installations and do something intelligent if one of them fails?

And finally, what's our rollback strategy?  Does the technology allow an installation that goes bad partway through to be rolled back to the state before it begun, or could we be left hanging with some stuff deleted, some stuff installed, etc.?

Let me posit an example:  Let's say I have a transport intended to install a blog subsystem.  Let's say it contains installers for some custom object definitions, Jot, Ditto, a calendar snippet and some lexicon topics.  What if by the time to run your transport you've already got a copy of Ditto that's several versions more recent?  What happens if there's a namespace conflict for the lexicon topics?  What happens if the transport has an older copy of the lexicon data, that contains fewer terms (and will thus wipe out terms that you currently have language strings for)?

Hope I'm not opening a can of worms, but I've seen all of these cases before...

--Bill

[smashingred]

@myfriendscallmebill  What insight.

Does the technology allow an installation that goes bad partway through to be rolled back to the state before it begun, or could we be left hanging with some stuff deleted, some stuff installed, etc.?

...snip...

  What if by the time to run your transport you've already got a copy of Ditto that's several versions more recent?  What happens if there's a namespace conflict for the lexicon topics?  What happens if the transport has an older copy of the lexicon data, that contains fewer terms (and will thus wipe out terms that you currently have language strings for)?

Hope I'm not opening a can of worms, but I've seen all of these cases before...

--Bill

I wonder if anyone else thinks this might be an issue? Should this be a new topic?

[OpenGeek]

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.

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.

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.

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.

[OpenGeek]

Further, Jason's reply #14, where he outlines the transport/vehicle process, says that a transport contains "a manifest file controlling the order the Vehicles are processed in."  That's fine as the simplest case, but what do we do if a set of vehicles only makes sense if they all install successfully?  Rather than a simple list (manifest) don't we need a master install script which, in its simplest form would be a simple list of vehicles, but would also have the ability to have some logic; so that it could be make to monitor the parade of installations and do something intelligent if one of them fails?

That's not a bad idea at all, though I think an xPDOScriptVehicle will do the job, and that can be packaged last.  I wanted to provide all the capability to get into such details without prescribing exactly how it should be performed.

And finally, what's our rollback strategy?  Does the technology allow an installation that goes bad partway through to be rolled back to the state before it begun, or could we be left hanging with some stuff deleted, some stuff installed, etc.?

That's really too complicated to say; it's going to have to be the responsibility of the package builder/maintainer to make sure the package has everything it needs and is robust enough to handle problems gracefully.  We're also working on a way in the future, to provide interactive interfaces that can be triggered by actions taken on a package.

Let me posit an example:  Let's say I have a transport intended to install a blog subsystem.  Let's say it contains installers for some custom object definitions, Jot, Ditto, a calendar snippet and some lexicon topics.  What if by the time to run your transport you've already got a copy of Ditto that's several versions more recent?

Then the maintainer of the aggregate package isn't doing a very good job of keeping it up to date.

  What happens if there's a namespace conflict for the lexicon topics?

There would be an error displayed in the console most likely, though that is up to the package at this point.

 What happens if the transport has an older copy of the lexicon data, that contains fewer terms (and will thus wipe out terms that you currently have language strings for)?

It won't automatically remove or overwrite existing terms; vehicles can use their payloads to handle a variety of these situations in intelligent ways, i.e. only insert new, don't update existing, update existing, don't resolve files, etc.

[wshawn]

If I understand resolver well enough,  it sounds to me more like a Train Conductor or conductor for short.

Maybe that would be a better name.  A conductor basically allows access to the train, checks the tickets, signals the train to move along, etc...

The concepts being discussed here are the equivalent of a first year programming student being introduced to classes and object oriented programming.  It takes a bit, but when you get it -- you get it.

In any case, I think if we look to real world visuals which are typically universal it should satisfy both the developers and marketers who definitely have different viewpoints of reality.

One day threads like this will truly be exemplary of the modx community and the openness of the designers.

I would love to have a team to work with on projects like you guys. 

Typically, in most packaging system used in open source operating systems, resolvers (looking for package dependencies) run first and thereby can cause confusion to the myriads of people who have been working with yum, up2date, apt, yast, etc.