+972 52-548-6969
The myth of the all inclusive meta-entity
Jeff Brown has a good post about information in software:
There is no technical reason preventing software applications from adopting common standards in the representation of their information.
[...snip...]
Would software interoperability improve if we could just agree on common meta-classes for data structures?
[...snip...]
In any case, it bothers me profoundly that software is so vertical. There is too little common ground. Each application contains a wealth of information but remains steadfastly inaccessible.
It is worth point out that most organization can't agree on what something as fundamental as the Customer within the organization. This is because different parts of the organization are responsible for different aspects of the customer, and they have radically different needs.
As Jeff points out, software that is open & extensible usually carry a price tag of six figures as well as a hefty customization fee. That is just the nature of the beast, because being a generalist costs, because the business doesn't care if you you can handle fifty different ideas of customers, they want your to fit their idea of customer, do it well, and fit with the different view of a customer within the organization. That doesn't come easily.
Comments
Indeed, good luck getting anyone to agree on common definitions of model objects in a system. It just won't happen!
But somehow I think it should be possible to have a common meta-language for data model so they can be accessed, presented and manipulated generically.
You'll see UI frameworks where this has been done. JFace, used by Eclipse, defines IContentProvider interfaces to adapt models of various kinds for presentation purposes. So there are IListContentProviders and ITreeContentProviders.
Likewise, the model objects themselves are often adaptable to other formats via interfaces like IAdaptable. Thus a Java Package object can be adapted to a Directory Resource and manipulated in any of the ways a directory might be manipulated. Adapters are often contributed by external plugins to add new interpretations to existing objects so that they can be used in a variety of different contexts.
These are very powerful approaches indeed! Imagine what would happen if all applications were built like this?
In the UI, it is possible to do so because you have a limited set of things that you can display, lists and tree and objects are just about it.
Likewise for things that can be adapted. Hierarchy to directory is very natural thing, but it can't work for a graph, for instance.
I do, imagine the cost for this.
That is the problem.
Hmm... It's been my experience writing plugins for Eclipse that with a well-designed core set of abstractions the costs are much diminished. In fact, the cost of integrating a few extra actions and views into a platform like Eclipse appears to be much less than it would be to build all of the action and view management code you would need on your own.
Witness the difficulty of building an add-in for Visual Studio versus Eclipse. Visual Studio is much more difficult to extend because it provides comparatively primitive services. Extending views with new actions requires individually hooking into the menus and toolbars for those views. There's no way to simply contribute an action on the basis of the underlying model object that is being presented and selected by the user.
At the risk of suggesting we all go framework-happy, I am curious as to whether the overall quality of software applications would improve if they were built atop a better platform rather than all pretty much working from the ground up.
For example, what would be the benefits of using common abstractions and DSLs to specify and implement common participants in a UI such as the models, views, actions, undo/redo mementos, background jobs, etc...
In other words, should we be writing applications using a 4GL?
The classic issue that we faced with 4GL is that they are really good for what they are supposed to do, and really bad for general purpose one.
I with you on extensible frameworks, certainly, but I think that this is not an applicable method to develop most applications. Unless you build to extend, there is a high cost of it.
Comment preview