The manner in which layers were used in the old Ax was pretty clear, we had
SYS, SYP Used by the core system
GLS, GLP Used by the initial added modules which were bought in ( CRM from Hands Norway, Product builder from Aston (now Tectura) HRM from Circle Capital, Shop Floor from Thy Data Center ).
LOS, LOP Used by some countries to add functionality ( US EDI connector, Germany Cost Accounting from Circon )
DIS, DIP Used by most countries for localisation
BUS,BUP Used initially by partners freely then only by invitation in an early version of IBI (Industry Builder Initiative)
VAR,VAP Used by the partners to put their code in
CUS,CUP Reserved for the customer
USR,USP Reserved for the customers
Today in V4, the first 4 are all now in SYS and I am told discussions are ongoing right now as we speak as to where to put what as regards corrections.
I would say do not be greedy:
You have freed up 3 Layers
How about designating one GLS GLP as still for internal use
and freeing UP LOS LOP for IBI use
Leaving DIS DIP empty (replace it later to add another level of user layer )
Give back both BUS and VAR to the dealers freely as it was in 2.5 and V3 initially.
And in a future version give the freed layer to the customers who also need in many cases another layer for their use.
Be a great X-Mas present a clear IBI Layer and an added Dealer layer as well as an added Customer layer
Of course it will not be easy to move things around, as the whole object numbering scheme depends upon this and moving them around is not that easy.
Renumbering the objects has some dreadfull consequences all sorts of places, as those who forgot to export with numbers from their dev system have found out to their cost :-).
But hey the clean up has given the opportunity, and I always though Erik Damgaard when he designed it was being greedy taking 4 of the layers for the systems out of the 8 available ( not counting the patch layers ).
So rebalancing is now a possibility, perhaps.
/Sven
Subscribe to:
Post Comments (Atom)
2 comments:
I realize this is a radical idea what would probably be difficult to implemenet, but how about getting rid of the numeric object IDs entirely and replacing them with GUIDs like Class IDs?
And instead of having a predetermined number of layers, allow for the creation of any number of layers above the layers Microsoft is using. Then give administrators the ability to determine the ordering of these additional layers.
Sounds good to me Todd, however I do want them to consider the existing population of 8,000+ companies that have already deployed.
Having done some upgrades I could see how your idea could work however, I can also see some unwise decisions by sys admins leading to disastrous performance issues.
The problem is I know how the P-code in this stored and executed (through good old fashioned peeking at the files) and they would have to change the P-code executor completely. It looks like it uses arrays and lookups to find fields and classes that it needs to execute, I think this is done in order to avoid having to parse / search for them in a more Java like manner.
One of the things I do appreciate in the tool is the speed advantage it has over f.ex. Java in a similar environment due probably in no small part to the P-code and the numbers etc etc.
Anyhow could ask someone in the Microsoft Dev Center in Copenhagen whether they can do as you suggest.
And last but not least, they make us pay for each of our layers LOL
Post a Comment