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 
_______________________________________________
telecom-patterns mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/telecom-patterns

Reply via email to