Update to AMGH HOW-TO

I've made an update to my AMGH HOW-TO Guide to cover the lesser-used aspects of the API. See the section titled "Less commonly used features of the AMGH API".
Comments:

very cool bob, thanks for the update.

(the use_firstserer has confused me in the past, per this new information I'll need to experiment with it some to get a full feel for it.)

QUESTION: Given this new use_firstserver information, does this still means the following:
a DTU boots and connects to SRS-a that is AMGH enabled. A card is inserted which triggers a DTU-redirect to SRS-b. (say that SRS-b does NOT have any matching, or ANY AMGH info on it.) In such a situation when the card is pulled, am I correct in thinking there is NO WAY for the DTU to be either restarted, or directed back to where it initially booted from?... since that is an ACTIVE AMGH event that would have had to be trigered from SRS-b?)

Boy this is getting confusing/complex....

In that segment you mentioned something along the lines of "pseudo.\*". Was that "short-hand" or can we indeed use wild-cards/reg-ex-matching in the database-file for the sample-scripts included?

Please expand the HowTo with some clarification for this.

Thanks....

Posted by guest on February 24, 2006 at 06:37 PM EST #

You are correct regarding your SRS-a/SRS-b scenario above. If SRS-b doesn't have AMGH configured, it can't send you back. I think typically you want consistent AMGH configuration and mapping info across your FOGs in order to reduce complexity. The sample scripts don't do wild-card matching, but you can write a script that does so if you like quite easily - the samples are simple in order to provide a good example, they are not full-featured for production use.

Posted by BobD on March 08, 2006 at 05:17 PM EST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

bobd

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Bookmarks