Christian,
I take the feedback that I receive very seriously. I agree with you completely on the following point:
"Just by stating that something is a fact it doesn't become a fact."
These are your exact words. This is logical and correct. We can all agree with it. In my case, I bring documentation, papers, detailed arguments/answers, reference implementations and production applications. It is not just a statement or assumption.
On the other hand, this same standard applies to everyone, including yourself.
Using your own logic and words, you need to bring references, arguments, documents
to prove or support your points. Otherwise, just because you state it as a fact it does not
make it so. This is your exact logic and words.
As a constructive criticism, you should obviously apply the same standard to
yourself.
I'm afraid your latest points in regards to the actual paper are lacking arguments and/or references/documentation.
Regards,
Al
More facts based on arguments, mathematical proof, detailed documentation/papers, reference implementation, production quality application... I welcome any rebuttals/comments/questions based on specific arguments, facts, documentation, references, etc.
Van: Messaging Design Pattern [dsheppard2k AT yahoo.com]
Verzonden: maandag 21 mei 2012 5:01
Aan: Christian Köppe
CC: gang-of-4-patterns AT cs.uiuc.edu; telecom-patterns AT cs.uiuc.edu; ipc-patterns AT cs.uiuc.edu; patterns-discussion AT cs.uiuc.edu
Onderwerp: Realistic Information Model and Concepts
Christian,
I seriously consider all specific feedback that I receive. Either via the list or as part of future work/papers. Obviously the feedback needs to provide specific information based on the paper being discussed. It should be also constructive critism in order
to have a rational/logical conversation and move the discussion forward.
I may not agree with someone's views/opinion which is obviously a separate matter. I have answered your previous specific questions/comments in detail (related to the papers). I appreciate the specificity of your latest question:
"(A) The information pattern family can provide comparable capabilities to the ones
provided by multithreaded and distributed applications/processes, (B) while at the same
time improving overall complexity, decoupling, encapsulation, reusability and scalability.
(C)As a consequence, software engineering processes are also improved in terms of reliability, cost, implementation timeframes and so forth.")
This statement is supported (factual) for several reasons:
The information primitive is Turing complete as demonstrated in the paper. Therefore the first of the part statement is true (A). Any arbitrary technology, including distributed access and concurrency can be implemented using the information primitive:
processInformation (message)
The second part is also factual(B). It should be obvious that messaging and the other information patterns improve decoupling and encapsulation: entities are fully decoupled and encapsulated. The paper covers the rest in detail. I'm not going over all of them
as part of this email.
(C) is also factual as expected. If we are able to improve overall complexity, decoupling, encapsulation, reusability and scalability ... it should be expected that cost, timeframes and reliability will be improved as well. This is also supported by the reference
implementation of the information patterns and many production quality applications.
Everyone with experience with distributed/multithreaded application can talk about the complexities/costs/delays associated with traditional RPC/multihreaded APIs. Moreover, if a conceptual framework is reused, the cost/timeframe of such implementation is very
small. The information infrastructure (plumbing) is already provided by the framework and can be reused with minimum additional cost/time. In general Mutithreaded/RPC capabilities (like remote proxies) cannot be reused.
It should become obvious that if we don't have to reimplement the concurrency/distributed/asynchronous capabilities, such approach will have an substantial impact on software cost, reliability, timeframes and so forth.
Let us assume that the implementation of a MDP component/package is comparable
to the cost of implementing traditional components/packages based on traditional APIs.
However, it can be argued that MDP component based on a conceptual/messaging API
are simpler: one primitive and a very limited number of message types (READ,
CREATE, UPDATE, SEND, etc). On top of this, individual MDP components/packages can be reused and/or purchased.
We still need the specifics about the papers on concepts that you mention. I agree that statements should be supported by specific facts/arguments/documentation/references/etc. I respect everyone's opinions/views. Obviously statements/views needs to be accompanied
and supported by specific facts/documents in order to be more than unsupported opinions/views. As I said, I'll be happy to add any references that may be required. I'm afraid that specific empirical information is not part of the scope of every technical
publication.
I'll address your other points (related to the paper) shortly. I hope this makes sense. As you can see this specific statement is supported by technical facts. It also supported
by a reference implementation of the information patterns and many production-quality applications.
I'm afraid that he traditional API/multithreaded/RPC model is limited. Complexities and shrotcomings are present. A realistic information model, as the conceptual model proposed, provides a more complete (better) model. No point in trying to second-guess nature
and its information design patterns and concepts. The mind is best information processor available, so to speak. It is also a 'conceptual engine' based on messaging and the other information design patterns and concepts. Our best bet is mirroring it as part
of computer systems and software.
Regards,
Al
|
|
