Patent Publication Number: US-2012030277-A1

Title: Preview publishing of reports

Description:
CROSS-REFERENCE TO RELATED PATENT APPLICATIONS 
     The present application claims priority to U.S. Provisional Patent Application No. 61/369,690 entitled, PREVIEWING PUBLISHING OF REPORTS, filed on Jul. 31, 2010. U.S. Provisional Patent Application No. 61/369,690 is hereby incorporated by reference in its entirety as if set forth herein in full. 
    
    
     BACKGROUND 
     Organizations collect and store a large amount of data in databases. This data may be for example employee data or data relevant to a business such as inventory or customer information. In order to present this data in a user friendly fashion, reports can be generated to easily view and analyze the data. Reporting services applications can provide ready-to-use tools and services to help create, deploy, and manage reports for an organization, as well as programming features that enable the customization of the reporting functionality. 
     Reporting services that include a report designer do not always provide for an easy, efficient, and accurate way to preview changes to reports. For example, if changes are made to a report and a user wishes to preview the report with the changes, some reporting services may require the changed data to be published as a separate report. Furthermore, the previews of a report may not accurately reflect how a report will look when published. Some report publishing servers provide additional features in their server environments that are not reflected in the report file. Thus, previewing a changed report outside of the server environment will not accurately reflect how the report will look when actually published within the server environment. 
     It is with respect to these and other considerations that embodiments of the present invention have been made. Also, although relatively specific problems have been discussed, it should be understood that embodiments of the present invention should not be limited to solving the specific problems identified in the background. 
     SUMMARY 
     This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detail Description section. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. 
     Described are embodiments directed to providing a preview feature in a report designer that allows modifications to report metadata to be made and previewed accurately. In embodiments, the feature allows a user to open a report to make changes to metadata of the report and have an accurate preview of how the report will look when published on a report publishing server. Embodiments provide for a report publishing server to allocate an in memory location that stores modified metadata of a report. The in-memory location is associated with the same folder as the original report, which allows relative paths and references to sub-reports or data sources stored on the report publishing server to be accurately reflected in a preview on the client. 
     Embodiments may be implemented as a computer process, a computing system or as an article of manufacture such as a computer program product or computer readable media. The computer program product may be a computer storage media readable by a computer system and encoding a computer program of instructions for executing a computer process. The computer program product may also be a propagated signal on a carrier readable by a computing system and encoding a computer program of instructions for executing a computer process. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Non-limiting and non-exhaustive embodiments are described with reference to the following figures. 
         FIG. 1  illustrates an embodiment of a system that may be used to implement embodiments. 
         FIG. 2  illustrates a block diagram of a client and server that may be used in some embodiments. 
         FIG. 3  illustrates an operational flow for a client with a report designer that provides preview of an edited report consistent with some embodiments. 
         FIG. 4  illustrates an operation flow for a report publishing server providing information to allow an edited report to be previewed consistent with some embodiments. 
         FIG. 5  illustrates an operation flow for a client to request a report publishing server to test connection to a data source referenced in a report, consistent with some embodiments. 
         FIG. 6  illustrates an operation flow for a report publishing server to test a connection to a data source referenced in a report, consistent with some embodiments. 
         FIG. 7  illustrates a block diagram of a computing environment suitable for implementing embodiments. 
     
    
    
     DETAILED DESCRIPTION 
     Various embodiments are described more fully below with reference to the accompanying drawings, which form a part hereof, and which show specific exemplary embodiments for practicing the invention. However, embodiments may be implemented in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Embodiments may be practiced as methods, systems or devices. Accordingly, embodiments may take the form of a hardware implementation, an entirely software implementation or an implementation combining software and hardware aspects. The following detailed description is, therefore, not to be taken in a limiting sense. 
       FIG. 1  illustrates a system  100  that may be used to implement embodiments. System  100  includes clients  102 ,  104 , and  106 . As shown in  FIG. 1 , client  102  includes an embodiment of a report designer. The report designer includes a user interface  108  that is used to receive input from a user of client  102 . A user may utilize the report designer to design a report that will be published on a report publishing server such as server  110 . As shown in  FIG. 1 , the report designer includes user interface elements such as elements  112  and  114  that a user can select. As described in greater detail below, in embodiments selection of interface element  112  allows a user to preview a report when the user edits report metadata. Also described in greater detail below, in embodiments when a user selects interface element  114 , report designer requests a publishing server to test connection data that is used to connect to a data source that stores data to be used in a report. It should be understood that although interface elements are shown displayed together, they may actually in embodiments be displayed in separate windows or panes, within separate toolbars, or separate dialog boxes. The interface elements are shown within the user interface  108  merely for illustrative purposes. 
     Through network  116 , client  102  communicates with server  110 . As noted above, once a user has finished designing a report on client  102 , the report is then published on report publishing server  110 . Report publishing server  110  is also accessible by other clients through network  116 , such as client  104  and client  106 . Each of these clients may in embodiments include report designers that allow them to create and modify reports. In other embodiments, these clients only include a browser that allows them to view reports that have been published on server  110 . 
     As those with skill in the art will appreciate, reports designed by users on client  102  using the report designer may refer to different data sources where data used to populate the report is stored. For example, databases  118  may store data that can be used to populate reports designed using the report designer on client  102 . Using the report designer, a user includes references to the databases  118 . When a request to publish a report is sent from client  102  to report publishing server  110 , server  110  will interpret the references in the report and populate the report with data from databases  118 . In embodiments, server  110  utilizes network  120  to retrieve data from databases  118 . In some embodiments databases  118  may be other types of data sources, such as data sources stored locally on server  110 . 
     As those with skill in the art will appreciate, databases  118  may have some security or other protocols that must be followed to access data within databases  118 . In these instances, metadata in the report will include connection data necessary to connect to the databases  118 . As noted above, in embodiments report designer  114  provides for the server to test the connection data before the report is actually published to server  110 . In these embodiments, a user can, while inputting connection data into the report using the report designer on client  102 , request that the server test the connection data. 
     Although some report designers provide for allowing a client to test connection data, embodiments described herein provide for the server to test connection data. In some situations, even if a client can successfully connect to databases  118 , server  110  cannot connect to access databases  118 , such as for reasons related to the topology of network  120 . The inability of report publishing server  110  to connect to databases  118  results in failure to publish the report or an incomplete published report. With the report designer on client  102 , the connection data can be tested by the server, and if there are any problems, the problems can be corrected prior to publishing a report. 
     As described in greater detail below, once a report has been published on server  110 , report designer on client  102  can in embodiments be used to modify metadata of the report. In embodiments, the report designer allows modifications to the report to be previewed. The ability to accurately preview modified metadata is effected by having the server  110  publish the report with the modified metadata. Having the preview published, or generated, by the server  110  results in an accurate representation of how the modified report will publish since the server&#39;s configurations, infrastructure, and IT settings are used in generating the preview. This results in a more accurate representation of the preview that if the preview was being generated locally on the client, which may have different configurations of infrastructure that do not accurately reflect those of server  110 . 
     The previews are accurate representations of what a report would look like with the changed metadata. In addition, the preview does not interfere with the ability of other clients such as clients  104  and  106  to access the original report. While changes are being made on client  102 , users on clients  104  and  106  would see the original report without the changes to the metadata being made on client  102 . 
       FIG. 2  illustrates a block diagram of a client and server that may be used in some embodiments. Client  202  in embodiments is implemented as client  102  shown in  FIG. 1 . Server  210  in embodiments is implemented as server  110  shown in  FIG. 1 . 
     As shown in  FIG. 2 , client  202  includes a report designer application  204 . Application  204  allows a user to design reports. The reports include metadata that describes the features of the report including information for accessing data sources that store data to be used to populate the report when it is published to report publishing server  210 . Additionally, report designer application  204  can be used to edit previously designed reports that are published on server  210 . Report designer application  204  includes a preview module  206 . Preview module  206  allows a user to preview a report that is being edited. Preview module  206  communicates with server  210  to provide a user with an accurate preview of what a report would look like with the edits being made by a user. 
     Report designer application  204  also includes a test connection module  208 . When a user is designing a report that requires data from a data source, a user can include connection data used to connect to a data source. In other words, a user can include a definition of a data source in a report. If the data source requires credentials to authorize access to the data source, a user can include the necessary credentials within metadata of the report to allow a connection by the server  210  to the data source when the report is published. Test connection module  208  allows the report designer to request that the server  210  test the connection data. As noted above, in some situations, clients  202  may be able to connect to the data source however, server  210  may be unable to. The test connection module  208  allows for any issues to be identified before a report is published. 
     In some embodiment, the client  202  stores data source information  209  and includes the data source information when it requests the server  210  to test the connection data. The data source information  209  may include information that identifies the location of the data source or credentials for accessing the data source. In other embodiments, client  202  may not have any data source information and the report may merely reference a data source. In these embodiments, test connection module  208  may simply send a request to test connection module  228  on server  210  to test the connection of the data source, and server  210  will use data source information  229  stored on server  210  to test the connection. 
     As shown in  FIG. 2 , server  210  includes a report publishing application  212 . The report publishing application  212  publishes reports that have been created by report designers such as report designer  204 . Application  212  communicates with application  204  to publish reports and also to provide preview information for reports being edited on report designer  204 . Report publishing application  212  includes API  214  that is used by report designer  204  to communicate with and request services from report publishing application  212 . 
     Report publishing application  212  stores a number of published reports  216 . In the embodiment shown in  FIG. 2 , the published reports are organized within folders such as folder  220  within a folder hierarchy (or namespace)  218 , although other types of organizations are possible. As shown in  FIG. 2 , report  222  is stored within folder  220 . In this embodiment, report  202  includes a number of references to items within folder  220 . The items include a data source  224  and a sub report  226 . The items may be referred to using relative references. 
     As noted above, report publishing application  212  also includes test connection module  228  that is used to test connection data. As indicated above, test connection module  208  of application  204  may request the server  210  to test connection data. In the embodiment shown in  FIG. 2  the request is handled by the test connection module  228  of report publishing application  212 . The test connection module  228  attempts to connect to a data source using data source information provided in the request or stored on server  210 . 
     When a user utilizing report designer application  204  desires to make changes to a report previously published on server  210 , she can make a selection to edit the report. The selection is made in embodiments by selecting a user interface button or by some other input made using a user input device. After the selection, the designer application  204  then allows the user to make changes such as editing metadata of the report. As part of editing the metadata of the report, preview module  206  will execute to provide the user with a preview of the edited report. The report designer application  204  sends a request to the report publisher application  212  to create an in memory location where modified metadata is stored. It should be appreciated that in embodiments the in memory location is a logical concept, and not a physical one. An item may not actually be stored in this location, but has a “context location” associated with it, which provides features such as the ability to resolve relative paths. 
     In one specific embodiment, creating an in memory location is implemented using edit sessions. It should be understood that the use of edit sessions is not the only way to implement the features of the embodiments described herein, and other embodiments are not limited to the use of edit sessions. For example, in some embodiments sessions between client  202  and server  210  are not established. Instead, edited metadata is sent to the server  210  for preview as a single transaction. Edit sessions provide the report designer application  204  the ability to associate the report being edited with a catalog location (e.g., file or folder), thus allowing relative references, stored embedded data source credentials, etc. to work during report preview. As seen in  FIG. 2 , the location is identified by reference numeral  230 . As can be seen, references to source  224  and sub report  226  function properly for the edited metadata item. 
     It should be understood that reference  230  is shown in  FIG. 2  merely for purposes of illustration. The edited metadata  230  is shown in folder  220  to illustrate that previews generated using the edited metadata  230  access data sources and sub reports that may be referenced in report  222 . This provides an accurate preview of a report with the edited metadata  230 . 
     Additionally, shown in  FIG. 2  are client configurations  240  and server configurations  242 . Configurations  240  and  242  include parameters such as security configurations, network configurations etc. As those with skill in the art will appreciate, client configurations  240  are likely to be different than server configurations  242 . This highlights one of the features of publishing previews on server  210 . Previews published on server  210  will be subject to the configurations  242 . As a result, if the server configurations  242  do not allow a report to execute properly, a user will be alerted to the issues because the preview will not execute properly. The user can then make any necessary changes to ensure that server configurations  242  do not interfere with the proper execution of the modified report. In conventional preview mechanisms, which publish previews locally on a client, a user would not be made aware of issues that could be created by server configurations  242  because client configurations  240  may not create the same issues. For example, a report may make a URL call to a network location. Client configurations  240  may allow such calls to be made, whereas server configurations  242  do not. A preview of the report executing on the client would function properly. However, when published on the server, the report would not function properly because the server would not be able to make the URL call. In contrast, the embodiments described herein alert a user to issues that may be created by server configurations  242 . The user can then make any necessary changes to avoid the issues created by server configurations  242 . 
     In embodiments, when the report designer application  204  opens a report from the report server, or otherwise determines that a preview should be displayed, it will utilize a report edit session. When previewing the report, the edit session will be used as the basis for the preview operation. 
     The edit session allows the report publishing application  212  on server  210  to cache data sets used by the report during preview operations. The report publishing application  212  does this automatically for edit sessions. This speeds up the iteration between preview and layout editing operations in report designer application  204 . The report designer application  204  is able to explicitly request new data, if desired. 
     The report publishing application  212  exposes an Edit Session. The Edit Session is a temporary container, for example location  230 , created on the server  210  that can be used by the report designer application  204 . This container is useful for maintaining consistency of property values and data across multiple preview operations. The container can be associated with a location in the catalog, which allows preview operations to reuse relative references, stored properties like embedded data source credentials (e.g., for source  224 ), etc. during preview. In embodiments, multiple Edit Sessions may exist for different users and a single user may have multiple outstanding edit sessions, i.e., for different reports being edited. In embodiments, an edit session is associated with one user. These embodiments avoid conflicting editing issues, which may occur if the edit sessions are shared across users. In other embodiments, however edit sessions may be shared across users and mechanisms implemented to avoid conflicting edits by different users. 
     In embodiments, Edit Sessions can share the same semantics as Execution Sessions (sessions used in originally creating a report). For example, in embodiments: 
     1) Edit Sessions are managed &amp; expired like Execution Sessions. 
     2) Edit Sessions have a timeout which can be controlled by an Administrator 
     a. Each interaction with the Edit Session extends the timeout 
     b. After the timeout is exceeded, the Edit Session is terminated 
     3) Edit Sessions are secured to the user who created them. 
     4) Edit Sessions can be terminated by an API call. 
     In some embodiments, Edit Sessions are longer lived than Execution Sessions and thus have their own default value for session expiration timeout. Administrators can set the Edit Session timeout. 
     Edit Sessions in embodiments have a unique identifier determined by the report publishing application  212 . The report designer application  204  obtains the identifier when the Edit Session is created and is expected to reuse the identifier when interacting with the session. In some embodiments, the Edit Session identifier is a human readable string; its structure is visible to API consumers. 
     One embodiment of an Edit Session Identifier (ID) structure is shown below: 
     |EditId|@|Path| 
     EditId—a unique identifier 
     Path—the path to the item (e.g. Folder or Report) associated with the Edit Session 
     The structure above is merely one example. As those with skill in the art will appreciate, any suitable way for identifying an edit session may be used without limitation. 
     In embodiments, Edit Session IDs can be used in place of item paths in API calls; APIs on each of the report publishing application  212  and report designer application  204  can specify in embodiments whether they can operate on an Edit Session. 
     In embodiments, Edit Sessions may follow the following interaction pattern: 
     1) Edit Session is created 
     2) Edit Session is populated either during creation, or afterwards though a series of API calls 
     3) Edit Session is used for preview operations 
     4) Edit Session is updated through API calls as item edits occur 
     5) Edit Session is re-used for preview operations 
     6) Edit Session is terminated either explicitly by the client or after it times-out 
     To implement Edit Sessions, in some embodiments, a new API call, e.g., CreateReportEditSession is defined for the report publishing application  212 . This API allows the user to create an Edit Session. The Edit Session is created with a report definition and is optionally associated with an existing folder (e.g., folder  220 ) or report catalog item as shown in  FIG. 2 . 
     When an Edit Session is associated with a report (e.g.,  222 ), the current properties of the report are reflected in the Edit Session. These include the parameter defaults, data source settings, general properties like description. This is shown by the dashed lines that link  230  to source  224  and sub-report  226 . 
     Although some specific details have been provided above with respect to implementing an in-memory location for use in previewing modified data, it should be understood that the use of Edit Sessions is not the only way to implement the features of the embodiments described herein, and other embodiments are not limited to the use of Edit Sessions. In other embodiments, client  202  may send edited metadata is a transaction to server  210 , which then publishes a preview of an edited report and sends preview information back to client  202 . 
       FIGS. 3 ,  4 ,  5 , and  6  illustrate operational flows  300 ,  400 ,  500 , and  600  according to embodiments. Operational flows  300 ,  400 ,  500 , and  600  may be performed in any suitable computing environment. For example, the operational flows may be executed by systems such as illustrated in  FIGS. 1 and 2 . Therefore, the description of operational flows  300 ,  400 ,  500 , and  600  may refer to at least one of the components of  FIGS. 1 and 2 . However, any such reference to components of  FIGS. 1 and 2  is for descriptive purposes only, and it is to be understood that the implementations of  FIGS. 1 and 2  are non-limiting environments for operational flows  300 ,  400 ,  500 , and  600 . 
     Furthermore, although operational flows  300 ,  400 ,  500 , and  600  are illustrated and described sequentially in a particular order, in other embodiments, the operations may be performed in different orders, multiple times, and/or in parallel. Further, one or more operations may be omitted or combined in some embodiments. 
     Operational flows  300  and  500  may be performed in embodiments by clients that are executing a report designer application such as report designer application  204  (see  FIG. 2 ). Operational flows  400  and  600  may be performed in embodiments by servers that are executing a report publishing application such as report publishing application  212  (see  FIG. 2 ). 
     Operational flow  300  begins at operation  302  where a selection to publish a report is received. The selection can be received by for example the use of a user interface where a user selects a button after having designed and created a report for publication. Flow  300  passes from operation  302  to operation  304  where a first request is sent to a server to publish the report. 
     Operational flow  300  then flows to operation  306  where a selection to edit the report is received. In this embodiment, the report to be edited was previously published using operations  302  and  304 . Operational flow  300  passes from operation  306  to operation  308  were a second request is sent to the server to establish an in memory location to store modified metadata for the report. As described above with respect to  FIG. 2 , this can be implemented in some embodiments by the client requesting the establishment of an Edit Session. However in other embodiments, this is implemented in different ways. 
     At operation  312  edits to the report are received and at operation  314  the edits are sent to the in memory location. Flow then passes to operation  316  where information from the server for displaying the preview of a report is received by the client. The preview information is used to display a preview of a version of the report with the modified metadata. As those with skill in the art will appreciate, operations  314 ,  316  and  318  are repeated in embodiments each time metadata from a report is edited. In other words, operations  314 ,  316 , and  318  in embodiments work in a loop. Moreover, a user is not required to only perform a single preview but may have more than one preview, i.e., a plurality of previews. 
     Referring now to flow  400  shown and  FIG. 4 , it begins at operation  402  where a request to publish a report is received. In response to operation  402 , at operation  404  the request is published, i.e., the report is populated with data from defined data sources and is formatted according to the report definition. At operation  406 , the server receives a request to establish a memory location for storing edits to metadata of a report. In this embodiment, the report was previously published using operations  402  and  404 . 
     In response to having received the request to establish a memory location, the location is established at operation  408 . As noted above with respect to  FIG. 2  establishing a memory location can be implemented using an Edit Session. In other embodiments however the memory location is merely associated with a folder or other file system location without the specific implementations of an Edit Session as described above with respect to  FIG. 2 . 
     After the memory location is established, edits are received at operation  410 . The edits received at operation  410  are then stored in the memory location at operation  412 . At operation  414 , the edits are executed on the server to generate the preview information. 
     In one embodiment, operation  414  may be implemented by creating an in-memory temporary representation of a namespace, such as namespace  218  ( FIG. 2 .). An edit session may be assigned to a path within the temporary namespace. In some embodiments, the temporary representation of the namespace and the actual namespace are merged. In other words, the temporary namespace is overlayed over the actual namespace. The execution of the preview report then occurs as if the preview report were the actual report. 
     At operation  416 , information that allows the edited report to be previewed on the client based on the modified metadata is sent from the server to the client. Flow then ends at  418 . 
     Referring now to  FIG. 5 , flow  500  begins at operation  502  where a selection to test connection data is received. It should be understood that operation  502  does not necessarily have to follow any of the previous operations described with respect to  FIG. 3  ( 302 - 318 ). Following operation  502  at operation  504  a request is sent to the server to test connection data. In some embodiments, the request may include data source information such as credentials or data source location information for the server to use in testing the connection. In other embodiments, the request may simply include a reference to the data source and the data source information is stored on the server. The server can then use the data source information stored on the server to test the connection. 
     At operation  506  the client receives an indication of success or failure of the server connection. Finally at operation  508  an indication of whether the connection data was successful or not is displayed to a user. Flow  500  ends at  510 . 
       FIG. 6  illustrates flow  600  which begins at operation  602  where a request to test connection data is received from a client. It should be understood that operation  602  does not necessarily have to follow any of the previous operations of  FIG. 4  ( 402 - 414 ). Following operation  602  flow passes to operation  604  where the server attempts to establish a connection to the data source using connection data. In some embodiments the connection data may be included in the request received at operation  602 . In other embodiments, the connection data may be stored on the server and the request merely includes a reference to the data source. At operation  606  the server sends an indication to the client about whether it successfully connected to the data source. Flow  600  ends at  608 . 
       FIG. 7  illustrates a general computer system  700 , which can be used to implement the embodiments described herein. The computer system  700  is only one example of a computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the computer and network architectures. Neither should the computer system  700  be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the example computer system  700 . In embodiments, system  700  may be used as a client and/or server described above with respect to  FIGS. 1 and 2 . 
     In its most basic configuration, system  700  typically includes at least one processing unit  702  and memory  704 . Depending on the exact configuration and type of computing device, memory  704  may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.) or some combination of the two. This most basic configuration is illustrated in  FIG. 7  by dashed line  706 . System memory  704  stores applications that are executing on system  700 . For example, memory  704  may store report designer application  204  described above with respect to  FIG. 2 . In other embodiments, memory  704  may store a report publishing application  212  such as described with respect to  FIG. 2 . Memory  704  may also include the in memory location  720  where edited metadata is stored for executing a preview of an edited report. 
     The term computer readable media as used herein may include computer storage media. Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. System memory  704 , removable storage, and non-removable storage  708  are all computer storage media examples (i.e. memory storage.) Computer storage media may include, but is not limited to, RAM, ROM, electrically erasable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store information and which can be accessed by computing device  700 . Any such computer storage media may be part of device  700 . Computing device  700  may also have input device(s)  714  such as a keyboard, a mouse, a pen, a sound input device, a touch input device, etc. Output device(s)  716  such as a display, speakers, a printer, etc. may also be included. The aforementioned devices are examples and others may be used. 
     The term computer readable media as used herein may also include communication media. Communication media may be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media. The term “modulated data signal” may describe a signal that has one or more characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media may include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media. 
     Reference has been made throughout this specification to “one embodiment” or “an embodiment,” meaning that a particular described feature, structure, or characteristic is included in at least one embodiment. Thus, usage of such phrases may refer to more than just one embodiment. Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. 
     One skilled in the relevant art may recognize, however, that the invention may be practiced without one or more of the specific details, or with other methods, resources, materials, etc. In other instances, well known structures, resources, or operations have not been shown or described in detail merely to avoid obscuring aspects of the invention. 
     While example embodiments and applications have been illustrated and described, it is to be understood that the invention is not limited to the precise configuration and resources described above. Various modifications, changes, and variations apparent to those skilled in the art may be made in the arrangement, operation, and details of the methods and systems disclosed herein without departing from the scope of the claimed invention.