[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:	DECmcc user notes file. Does not replace IPMT.
Notice:	Use IPMT for problems. Newsletter location in note 6187
Moderator:	TAEC::BEROUD

Created:	Mon Aug 21 1989
Last Modified:	Wed Jun 04 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	6497
Total number of notes:	27359

6336.0. "How to use qualifier VIA PATH ?" by KETJE::PACCO (Horum omnium fortissimi sunt Belgae) Wed Jun 28 1995 19:37

    Can somebody tell which is the exact syntax of the
    
    			VIA PATH
    
    qualifier.
    The Toolkit tells that the dispatcher takes care if it.  If that
    qualifier is found, the directive call is routed to that module
    or remote dispatcher. It's a Latin1String, but which one ?
    
    Can an example be given for the use of this, including the right syntax?
    I would like to use (experiment) with it, but I cannot achieve any
    progress.
    
    Regards,
    	Dominique.

T.R Title User Personal
Name Date Lines

6336.1 not implemented feature TAEC::FLAUW Marc Flauw, TeMIP Technical Office, VBO Thu Jun 29 1995 09:54 43

T.R	Title	User	Personal Name	Date	Lines
6336.1	not implemented feature	TAEC::FLAUW	Marc Flauw, TeMIP Technical Office, VBO	`Thu Jun 29 1995 09:54`	43
	Dominique, The short answer is that it does not work. This qualifier is not taken into account by the dispatcher. The reason it is in the SRM is that this document was supposed to be an architectural document, aligned with the architecture of the product and if the implementation of it was not following up, it had to be documented in the release notes of the product. VIA PATH was an example of such a feature, planned in the architecture, but not implemented. We have tried to remove such cases from the SRM of TeMIP Framework V3.0 and if you look at the SRM T3.0.0, you will no longer see the VIA PATH documented. The idea behing the VIA PATH was to allow overloading (or re-direction) of services by letting a client requests a service using a VIA PATH qualifier to override the standard dispatch and point to another module. We haven't met a lot of cases where redirection of services was really needed and I don't consider the use of this qualifier as the best way of achieving overloading of a service as the client has to know the name of the module servicing the request. This a-priori knowledge breaks the idea of the dispatching where the client does not know which module will service the request. Overloading a service is a requirement we have seen already, like I want to have my own REGISTER directive to do some specific stuff and then I want to call the standard REGISTER one to do the regular registration, or I need to do some specific changes in the field of an alarm before it gets consumed by the Notification FM. Sometimes, using the fact that there is 2 levels of dispatch tables (access and function) is enough as it provides a simple overloading of services. In other cases, like the REGISTER directive, it is not enough. But in all the cases we have seen, the requirement is that this overloading of services should be transparent for the client (PM or high level FM). The client simply asks for a service and don't care (and should not have to care) whether it has been overloaded or not. This is the reason why we have decided for TeMIP Framework V3.0 not to implement the VIA PATH qualifier and to remove it from the SRM. If you have detailed requirements on that topic, I will be interested to get them. Best regards, Marc.

Dominique,

The short answer is that it does not work. This qualifier is not taken into
account by the dispatcher. 

The reason it is in the SRM is that this document was supposed to be an
architectural document, aligned with the architecture of the product and if the
implementation of it was not following up, it had to be documented in the
release notes of the product. VIA PATH was an example of such a feature, planned
in the architecture, but not implemented. We have tried to remove such cases
from the SRM of TeMIP Framework V3.0 and if you look at the SRM T3.0.0, you will
no longer see the VIA PATH documented.

The idea behing the VIA PATH was to allow overloading (or re-direction) of
services by letting a client requests a service using a VIA PATH qualifier to
override the standard dispatch and point to another module. We haven't met a lot
of cases where redirection of services was really needed and I don't consider
the use of this qualifier as the best way of achieving overloading of a service
as the client has to know the name of the module servicing the request. This
a-priori knowledge breaks the idea of the dispatching where the client does not
know which module will service the request. 

Overloading a service is a requirement we have seen already, like I want to have
my own REGISTER directive to do some specific stuff and then I want to call the
standard REGISTER one to do the regular registration, or I need to do some
specific changes in the field of an alarm before it gets consumed by the
Notification FM.  Sometimes, using the fact that there is 2 levels of dispatch
tables (access and function) is enough as it provides a simple overloading of
services. In other cases, like the REGISTER directive, it is not enough. But in
all the cases we have seen, the requirement is that this overloading of services
should be transparent for the client (PM or high level FM). The client simply
asks for a service and don't care (and should not have to care) whether it has
been overloaded or not. 

This is the reason why we have decided for TeMIP Framework V3.0 not to implement
the VIA PATH qualifier and to remove it from the SRM. 

If you have detailed requirements on that topic, I will be interested to get
them.  

Best regards,

Marc.