Dart has rereating idiam of message massing in various places.
This may be simplified with a Message queue system like Qpid.
[abstraction of event driven message sending/receiving pattern]
Future is probably implemented as a generic class in Dart class. so no language extension would have been required to support Future.
Other event driven communication also requires couple of functions to be associated with the communication.
In this book, these are written in codes which is scattered in the source code.
Also it requires similar code need to be repeated again and again.
It might be possible to provide generic class which may be similar to Future class for these setup of communication.
[replacing message passing by message queue system]
These message passing is quite similar to message queue system like Qpid(Apache). If we use such system as communication mechanism, there will be more uniformity and flexibility.
For instance, some of the queue can be processed in C/C++ applications.
If we need have high performance server side engine, some of the job can be delegated to such C/C++ codes interacting with Message queue system(e.g, Qpid) without changing code.
Also it might be possible to make local/remote process transparent for the client.
for instance if some job is simple, it will do locally, but if it require more resources, it may distributes the jobs in distributed servers, and yet client may not notice these things are happening.
[writing sender and listener on the same side ]
It might be possible to define both logic on teh same side(client or server).
The current approach need to write corresponding codes on both of client and server. these are going to be confusing if they maintained separately.
For instance, listener code may be shipped to client using dart or javascript, and that code may be loaded dynamically in the client, and these VMs are communicated with message passing approach.
This may be simplified with a Message queue system like Qpid.
[abstraction of event driven message sending/receiving pattern]
Future is probably implemented as a generic class in Dart class. so no language extension would have been required to support Future.
Other event driven communication also requires couple of functions to be associated with the communication.
In this book, these are written in codes which is scattered in the source code.
Also it requires similar code need to be repeated again and again.
It might be possible to provide generic class which may be similar to Future class for these setup of communication.
[replacing message passing by message queue system]
These message passing is quite similar to message queue system like Qpid(Apache). If we use such system as communication mechanism, there will be more uniformity and flexibility.
For instance, some of the queue can be processed in C/C++ applications.
If we need have high performance server side engine, some of the job can be delegated to such C/C++ codes interacting with Message queue system(e.g, Qpid) without changing code.
Also it might be possible to make local/remote process transparent for the client.
for instance if some job is simple, it will do locally, but if it require more resources, it may distributes the jobs in distributed servers, and yet client may not notice these things are happening.
[writing sender and listener on the same side ]
It might be possible to define both logic on teh same side(client or server).
The current approach need to write corresponding codes on both of client and server. these are going to be confusing if they maintained separately.
For instance, listener code may be shipped to client using dart or javascript, and that code may be loaded dynamically in the client, and these VMs are communicated with message passing approach.
No comments:
Post a Comment