ࡱ> []Z5@ u)bjbj22 "BXX\6666RRRf,4f::(""""222:::::::$;R>7:R22@2227:66""L:1919192@6"R":192:19(19Y9,&RY9" `9=6Y9:b:0:Y9>17>Y9ff6666>RY92219222227:7:ffj$9ffjIntermediary Architecture By: Tico Ballagas Motivation: The EventHeap infrastructure has enabled a host of applications and features in the iRoom including wireless I/O devices, sound, multibrowsing, and a convenient mechanism for cross-platform inter-process communication and coordination. This allows the notion of room applications that run across an entire room of PCs and use the event heap to coordinate application flow. Some examples of this include iPong, which is a multi-platform / multi-screen version of the classic game Pong, Workspace Navigator, which is a meeting capture program, and the iClub which transforms the iRoom into an interactive club. With all of this event activity, it became inherently obvious that the room was missing a convenient mechanism to translate events from one type to another. This was most apparent when room developers started writing there own application specific event intermediary applications, or patch panels, to perform this translation. The goal of this intermediary application is to provide a general solution that can perform all of the event translation as a central service quickly and efficiently and also provide additional desirable features to the user. System Architecture:  SHAPE \* MERGEFORMAT  The Intermediary application can be most accurately described as an event daemon. It has no UI, and communicates with the world through the event heap. It listens for all events from the event heap. If a translation is specified for an incoming event, it will non-destructively translate that event to a set of new events which are posted on the event heap. Translation configurations can be specified by any application that is connected to the eventHeap through an event based interface to the Intermediary. One such application might be a Patch Panel application which provides an easy GUI to configure the event mappings. However, many different patch panels might exist on an event heap and client applications might also choose to specify configurations without a GUI. Translation Criteria: The intermediary allows the specification of event field based translation criteria. That is the translation from event A to events B, C will only happen if A contains field values that match the translation criteria. It is important to note that multiple translation criterion may exist for each EventType and the resulting event translation may be the sum of several different translation criteria matches. Intermediary Interface: Applications may specify or inquire about translation configurations by posting a IntermediaryConfigEvent to the eventHeap. The event acts as a wrapper to some fundamental APIs that are available to users. The functions that are available include: getTranslation( eventToMap ) : this function takes any event and returns the entire mapping of events across all translation criterion. This API is accessed with the following event. IntermediaryConfigEvent{ Method = getTranslation EventString = ConfigMan.getEventString( iwork.eheap2.Event ) } The response is posted by the Intermediary in the following form IntermediaryResponseEvent{ Method = getTranslation EventListString ( to decode use ConfigMan.getEventList( String ) ) TargetApplication = SourceApplication of original } getConfig( translationCriteria ) : this function takes in an event named translationCriteria that has only the fields desired for a translation criteria specification. It returns only the event mapping for this particular set of translation criteria. This API is accessed with the following event. IntermediaryConfigEvent{ Method = getConfig EventString = ConfigMan.getEventString( iwork.eheap2.Event ) } The response is posted by the Intermediary in the following form IntermediaryResponseEvent{ Method = getConfig EventListString ( to decode use ConfigMan.getEventList( String ) ) TargetApplication = SourceApplication of original } setConfig( translationCriteria, eventList[] ) : this function takes in an event named translationCriteria that specifies the fields necessary for event translation. The event also takes a second parameter that is essentially the set of events to map to when the translation criteria is met. This event mapping is stored by the Intermediary and used for all future event translations. This API is accessed with the following event. IntermediaryConfigEvent{ Method = setConfig ConfigString = ConfigMan.getConfigString( Event, Event[] ) } There is no response to a setConfig method. Note: in each of these interfaces the ConfigMan class provides static methods to aid in encoding and decoding iwork.eheap2.Events into strings. Field Handoffs and Transformations: In many event translation situations it is useful to handoff the value of a field of an incoming event to a field of an outgoing event. The Intermediary application supports this handoff through an inline function specification. Any field of any outgoing event in the event list mapping may be handed off to an outgoing event by using the following format. = fieldName1 The quotations and equal sign are mandatory for the translation engine to recognize it as a value to replace. The field name can only be a field from the incoming event structure. If the field does not exist the in the incoming event, the outgoing event field may be empty. Similarly, one may specify field value transformations. This allows simple arithmetic operations (+-*/) to be performed on incoming event fields. For example, to normalize the events from the iSlider device to iPong paddle location values the following operation was performed = (Value - Min) * 768 / (Max - Min) where Value, Min, and Max are all fields from the slider event. Implementation Details Configuration Manager: The configuration manager is a class that handles all of the event translation functionality for the intermediary. It keeps a copy of a full tree of translation mappings both in memory for quick access and on disk for recovery purposes at all times. The structure of this tree is a combination of hashes, lists and strings in the following manner:  SHAPE \* MERGEFORMAT  To configure an event translation, the configuration manager places an entry in the EventTypeHash with the EventType as the key. Then an entry in the FieldNameHash is placed based on the fields included in the translation criteria. The key is a sorted concatenation of all of the field names of the translation criteria. For each FieldNameHash entry there exists a CriteriaFieldValueHash and a CriteriaFieldList. The list is constructed using the field names of the translation criteria similar to the FieldNameHash key. This list is used to obtain the translation criteria field values to construct an entry for the CriteriaFieldValueHash. The key for the CriteriaFieldValueHash is a concatenation of the field values sorted by field name (same order as FieldNameHash). Each CriteriaFieldValueHash entry stores the event list mapping for translation purposes. Alternatively, to translate an event the configuration manager first performs a hash in the EventTypeHash using the EventType as a key. The next level, FieldNameHash, is a useless level for translation because each entry in the hash must be considered for a possible translation criteria match. However, the level exists to simplify configuration as described above. For each entry in the FieldNameHash, a key is constructed using the CriteriaFieldList. If a matching entry exists in the CriteriaFieldValueHash, then the event list mapping for that criteria is added to the total translation mapping. The use of hash tables for field values reduces seek time for translation criteria matches because all fields are compared for each translation criteria entry in a single step. The use of hash tables also dramatically increases performance for configuration lookup since all that is needed is 4 hash lookups to retrieve or set a configuration. Alternative Event Generator Alternative Patch Panel GUI Client Application Patch Panel GUI iStuff Wireless Input Device Intermediary Event Heap EventList EventList EventList FieldValueHash Key =concatenated field values FieldValueN FieldValue2 FieldValue1 CritFieldList CritFieldHash TransStructHash Key = transStruct field name CritFieldList CritFieldHash FieldNameHash Key = concatenated field names FieldNameN FieldName2 FieldName1 EventTypeN EventType2 EventType1 EventTypeHash Key = EventType Root  +,-;9 ? ] l  %&4=Xaefjs^ĸ~~h5hW{hwRhjhKOUmHnHuhKOjhKOUhl>h~J5hh~Jhl>h 5h hnhn5 hn5hjQ5CJ aJ h\I5CJ aJ h h 5CJ aJ 1,-;<  %&Dgd|'gd!$a$gd|'\'t)^CDw4Nr3;t&'STdPQWduՙ|h\Ih] h]5h]h]5h?ah|'hbXCJOJQJ^JaJhHgeCJOJQJ^JaJhCJOJQJ^JaJ h!h!hW{ h|'hHgeh|'CJOJQJ^JaJ hbXh!CJOJQJ^JaJhHgehwRh!0D_x6J?rtu&'@Tgdgd!$a$gd|'`gd!`gd|'gd|'TPQuvEF  $a$gd|'gd!gd|'op!CEj     6 7 8 9 : ; < D!&"G"""h#o########$)$*$,$Y%ÿûh3hph]hHgeh?ahhEjh/KUjh2T UmHnHuh2T jh2T Uh&OhMhzhzhz5hW{h?ah?aCJ aJ h?aCJ aJ h,hbX h,h,hbXh\Ih,1 ; < ##&&['\'x'y''''''''''''''''gd2T $a$gdKO$a$gd|' $`^`a$gd|'Y%m%p%y%&&}&&&Z'\'x'y''''''''''''''''( ((("(#(((A(B(C(O(P(\(](i(j(x(y(z((((((((((((((((((ƾƾƾ hN]5h2T hh2T CJaJhMh2T CJaJhMh2T >* h2T >*hMhKOhKO5CJ aJ hKO5CJaJhKOhKOhKO5CJaJh2T h]h/K?''( (((#(B(C(O(P(\(](i(j(x(y(z(((((((((((($a$gd2T gd2T ((())))))))*)5)6)A)B)M)N)\)l)m)r)s)t)u)$a$gd|'gd2T $a$gd2T (()))))))))*)5)6)N)\)l)s)t)u)h]h<.hMh2T >*hN]5h2T hh2T CJaJhMh2T CJaJ 1h/ =!"#$%Dd D  3 @@"?Dd 'eD  3 @@"?D`D !NormalCJ_HaJmH nHsH tHDA@D Default Paragraph FontRi@R  Table Normal4 l4a (k@(No List:N_}.\l|u!|yxwv:N_}.\l| u!B,-;<%&   D _ x 6J?rtu&'@TPQuvEF;<[\xy   # B C O P \ ] i j x y z !!!!!!)!*!5!6!A!B!M!N!\!l!m!r!s!v!0(000000000000000000000@0@00000p00p00000000000000 0p000000p0000000000p00p00p00p00p00p00000p0@0p0@0p00p00p0000000000000000000000000@000000000@000@000@000@000@000@000000000000000@00000P\x !!v!O900 ثKO90M90 KM90M90My0Oy0O90 6[5?@K6[5?@K6[5?@K6[5?@KO90@_O90@_O90@^Y%(u) DT '(u)t)69u!__8@R=(   5,  t3  s"*?` u c $X99?5, T v # v] , n w C w"`O + T x # x ]+- T y # y + TB z C DO P TB { C D  T | # | + TB } C DO / 0TB ~ C DO  fB  s *DjJ=d>4TB  C D+WT  # W\3+ T  # W3 T  # W3 TB  C D TB  C D/W0TB  C DWfB  s *DjJc2n  C "`3a T  # ]* T  #  n  C "`_a T  # / T  # f T  # !^&, T  # !&  T  # !&  fB  s *DjJ#e#3TB  C D!TB  C D  TB  C D !TB  C D /!0n  C  "` o'a  T  # o']+,  T  # o'+  T  # o'+ TB  C D&o'TB  C D&o'TB  C D&o'Br   H/gBr   H(#]TB  C D3,TB  C D3d   3  s"*?`  c $X99? N   p N    N   Vz Z N   F" T N   LP N   V N   % `B  c $D"D%`B  B c $DD`B ! c $D`B " c $Dz h%`B # c $D" `B $ c $D*B S  ?7u!!ttL,t- D L U D ] i w x  : M 4@IKVYq 2?PSdu~'>JSUad}6C5BKa<I+8Yj\   " C N j w z !!*!4!v!4 = + , D ^ 5Yr u'?d~FK\v!3333333333333333333;% ruATD\wy   A C N P [ ] h j x z !!!!!!(!*!4!6!@!B!L!N!k!m!q!v!\v!Rafael Ballagas('U ?a3y2T |'N]5 @hE"Y]"z<. "&OM!wRrpn@@J``u!@@UnknownGz Times New Roman5Symbol3& z Arial?5 z Courier NewC .PMingLiUe0}fԚ"qh h h _88!24dLL 3H)? "Intermediary Design DocRafael BallagasRafael BallagasOh+'0 , H T `lt|Intermediary Design DocnteRafael Ballagasafaafa Normal.dotaRafael Ballagas9faMicrosoft Word 10.0@vE @:9@(9՜.+,0 hp  Stanford University8LA Intermediary Design Doc Title  !#$%&'()+,-./0123456789:;<=>?@ABCDEFGHIKLMNOPQSTUVWXY\Root Entry F9^Data "1Table*>WordDocument"BSummaryInformation(JDocumentSummaryInformation8RCompObjj  FMicrosoft Word Document MSWordDocWord.Document.89q