Hi Phil,
"Maybe someone can explain ?"
I guess that would be me
Here is some historical context to assist in understanding how we got to where we are today and why the mach dev rev is required for MSM -
The MSM project originally was a User Interface (UI) redesign with the specific target of providing UI support for changes that Brian was making for V4. The project started in Q3 2009 and a lot of manpower time has been invested to get to the beta release stage. This MSM package has been in development for about 9 months - obviously, I have not been using the latest mach dev version for that entire time, instead I prototyped the code using the V3 lock down revs of Mach. This means I was attempting to prototype v4 features by running on on the V3 mach kernel. (BTW, that is not a simple task).
I was pretty successful in doing much of the feature set with V3 - but some things just couldn't be implemented w/o mach V4 support. Along the way I kept a list of things that could not be done without additional script application programming interface (API) support. I also had a list of things that could not be trusted to work correctly in all cases (on V3, without access to info that mach did not expose at the scripting interfaces).
A couple of months ago, I suggested that by adding key portions of the needed APIs to V3, and then making a few of the screen pages reflect V3 (instead of V4) functionality, we could have a spin off version that had 80%+ of the user exposed functionality running on V3. That proposal had both pros and cons....
Pros:
It would provide significant new functionality to users of V3
It would would be a means to get wider spread testing of the package (the Alpha test group size was around 15 people).
It would begin to shift the user base into learning the new UI which would in turn lower the learning & test curve for V4 later on.
Cons:
It meant that Brian would have to put some significant level of work into V3 to add the new APIs.
That time had to come from somewhere - so this would push back other tasks.
The decision was made to create a V3 version of the MSM v4 project.
The minimum APIs we needed to add grouped into a couple of categories:
a) Correct functionality
b) Automated installation
c) Code maintainability
I'll give an example of each category.
Functionality: Essentially, every single script that exits prior to MSM that attempts to implement probing functions for Z can be made to crash a probe. In the dev rev we added an api to get the state of the mach option "IncludeTLOinZFromG31()". Without that call, the only thing a programmer could do is assume the state of the corresponding general config page option. You could not even cheat and read it directly from the profile XML (I did that) as the XML is not updated until mach exits.
Set this option different form the Z probing code's assumption and the result is a crashed probe. (you don't want to learn that the same way I did.... ) It's unacceptably dangerous to release software that requires that all users, set multiple options, exactly right, to get the software to work correctly.
Automated installation:Paraphrasing something I said in another thread and playing on a well known car slogan: "This is not your fathers screen set".
MSM is much more than a set of bitmap screen images. It's really a significant functional enhancement for Mach 3 V3. To get this functionality working on V3 requires a lot of stuff to be going on under the hood.
The alpha packages for MSM were a pain to install and a pain to support - even for a small group of people. Alpha testers had to do things like edit their macro pump to patch in MSM support code and install and hand enable several brains. It was simply unreasonable to consider rolling out this package for beta test unless a clean automated installation was part of the package.
Multiple APIs were added to enable this to happen. Examples include:
1) Screen sets can now have load and unload scripts that mach runs automatically. Think of these as simple constructors and destructors for a screen set object. We even did this in a way that you can use the facility with old screen sets.
2) To avoid editing user macropumps, we invented periodic scripts. Mach can now run multiple periodic background scripts. MSM fires up the ones it needs from it's initialization code.
3) There is now a way to get brains automatically loaded by mach w/o user intervention via the menus.
Code maintainability:I have not counted it up lately (I don't really need to know), but I know that the script code in the MSM package is well over 5000 lines...
It is simply impossible to create something of that size and reasonably maintain it without the use of some supporting software tools. We added some key facilities to Mach scripts to support the creation and use of maintainable code:
#expand - this feature implements simple pre-processing for mach scripts. From a maintainability standpoint, it enables one source script to live in one place. This is a huge quality improvement.
For example, the page change buttons in MSM run a script routine. There are over 100 buttons in the screen set that can change a page. In prior versions of MSM, each and every one of those buttons had to have a copy of the routine in it - that's a nightmare if you want to change the routine. Now there is one copy of the routine, in a named script file on disk, that each button uses.
This is a classic case of a huge effort to provide a feature that enhances quality and maintainability, but that is totally invisible to 99.9% of mach users. Getting this to all work required a huge effort by Brian and I thank him again for doing it.
All the features have been in development for several months (I've been using unreleased mach dev revs for MSM work) and were publicly first made publicly available with mach 3.43.6. Because of the extensive use that MSM makes of the new APIs, I think they are likely to have been better tested prior to release than the casual user might suspect.
All these things were done in order to enable us to provide the MSM v3 package. We've tried hard to make the user experience simple and easy. ...and none of this is possible with the 3.42.40 lock down revision - and hence the requirement for use of the mach development version.
Now, having said all this, and again saying that I think the MSM package is pretty stable... we are pragmatic. This is a beta test program for both the Mach Dev rev and MSM. The software has been through a pretty long Alpha test program before getting to the beta stage, but we all know that when you let more people try it, things will get done that were never anticipated. I expect that bugs will be found - that is, after all, the main purpose of a beta test program.
Each user has to decide for themselves if beta software is appropriate for their use or not. There is absolutely nothing wrong with deciding to let others have the new experiences and waiting until later to jump in.
Dave
Guest
Show Posts
sorry, my only comment will be "no comment" wrt to questions re future plans or projects that Brian may have. You have to go ask him those questions 
