Patent Publication Number: US-11048488-B2

Title: Software code optimizer and method

Description:
This application claims the benefit of priority of U.S. Patent Application Ser. No. 62/718,809, filed Aug. 14, 2018, entitled Software Code Optimizer, the teachings of which are incorporated by reference herein. 
    
    
     BACKGROUND OF THE INVENTION 
     The invention pertains to digital data processing and more particularly, by way of non-limiting example, to the optimization of software. The invention has application in facilitating the download and execution of so-called web apps, as well as other computer programs that download and execute in source code format. 
     Enterprises are increasingly turning to web apps to service customer and other end user needs. This is an opportunity made possible by the ubiquity of feature-rich browsers supporting JavaScript, CSS and other user interface (UI) standards on mobile and other devices in the hands and/or on the desktops of billions of users worldwide. Whereas software distribution was once the sole province of high-tech companies with teams of dedicated developers, these feature-rich browsers now define such a large and powerful platform that enterprises of all varieties, from high-tech to low-tech, can benefit by distributing apps to them, whether for customer service, marketing or otherwise. Browser technologies have become so versatile in fact, that enterprises often rely on them for distribution of apps within the enterprise to employees—not just to customers and others on the outside. 
     Unfortunately, just like conventional software applications, browser apps often include code to support capabilities that most individual users do not require or cannot use. For example, browser apps typically include software supporting end users of diverse classes, even though each individual user who runs the app only falls into only one of those classes. Likewise, the apps provide code supporting user access from a variety of portals (e.g., developer portal, support portal, etc.) even though each end user is likely to access the app from only one of them. 
     A consequence of excess code is that web apps are large, and their downloads are slow. While end users who run a given app for hours on end may not be bothered by this on an initial download, occasional users will be—as are those who download “once and done” apps, e.g., customer service requests. 
     An object of the invention is to provide improved methods and apparatus for digital data processing. 
     A further object is to provide such methods and apparatus is to improve the download and execution of web apps and other computer programs that download and execute in source code format. 
     SUMMARY OF THE INVENTION 
     The above objects are among those attained by the invention which provides, in some aspects, methods of optimizing an app for download to and/or execution on a client device by identifying components of the app used in such execution by a user having a designated role who accesses the app for download via a designated portal. A component can be, for example, a source code file or portion thereof, including, for example, a portion defining a widget or other user interface element. 
     For each component, the method (i) identifies source code files on which execution of that component depends, e.g., in connection with execution of the particular app by the particular user, and (ii) generates a dependency-ordered stack of the source code files for that component. In further accord with those aspects of the invention, the method combines the dependency-ordered stacks into a single such stack and transfers the source code in an order specified by that stack to the client device for loading and execution. 
     Related aspects of the invention provide optimization methods, e.g., as described above, where the step of identifying source code file dependencies and generating a dependency-ordered stack for each component includes (i) recursively iterating, in both depth and breadth, through the identified components and, in turn, through the components on which they depend, and (ii) creating a dependency stack for each component encountered during such recursive iteration if none exists. 
     Further related aspects of the invention provide optimization methods, e.g., as described above, where a sort (e.g., a bubble sort or otherwise) is used to combine the dependency-ordered stacks into a single dependency-ordered stack. 
     Yet further related aspects of the invention provide optimization methods, e.g., as described above, where combining the dependency-ordered stacks includes iteratively appending one of the dependency-ordered stacks to an intermediate stack and deleting prior entries in that intermediate stack. 
     Still yet other related aspects of the invention provide optimization methods, e.g., as described above, where transferring the source code to the client device includes doing so in multiple bundles, each based on the dependency order specified in the single dependency-ordered stack. Those bundles can include, according to other related aspects of the invention, a top bundle including source code that is loaded as soon as a page is visible upon execution of the app on the client digital data device; a template bundle include source code loaded before control rendering begins upon execution of the app on the client digital data device; and a bottom bundle including source code loaded at an end of an initial page load upon execution of the app on the client digital data device. 
     Yet still other aspects of the invention provide optimization methods, e.g., as described above, where the step of identifying components used in execution of the app includes crawling the app source code starting at an entry point and recursively descending in both depth and breadth, crawling designated components even if they will not be used in execution of the app on the client digital data device by the user, and not crawling designated components even if they will be used in execution of the app on the client digital data device by the user. 
     Still further related aspects of the invention provide methods, e.g., as described above, where source code files defining components are JavaScript files. 
     Other aspects of the invention provide methods, e.g., as described above, that include identifying, in style sheets, a set of user interface components, features of those components, and formats of those components or features, used in execution of an app on a client digital data devices by users having a plurality of different respective roles and/or portals from which they request transfer of the app for loading and execution. The method further includes identifying a subset of those components, features and formats not used in execution of the app on a client digital data device by a user having at least one of a designated role and a designated portal from which the client digital data device requests transfer of the app for loading and execution. 
     The method calls for transferring to the client digital data device for loading and execution thereon those style sheets files or portions thereof that define components, features and formats that are in the set, while refraining from transferring those that define components, features and formats that are in the subset. Thus, for example, if a first subset of components, features and formats are identified as not used on a first client digital data device by a first user having a first role who downloads the app from a first portal, and a second subset of components, features and formats are identified as not used on a second client digital data device by a second user having a second role who downloads the app from a second portal, the method calls for transferring to the first client digital data device for loading and execution source code files that define the set while foregoing transfer those at define the first subset and transferring to the second client digital data device for loading and execution source code files that define the set while foregoing transfer those at define the second subset. 
     Related aspects of the invention provide methods, e.g., as described above, that include generating and transferring to the client digital data device for loading and execution source code files that define the set but that are not in the subset, while foregoing at least one of generating and transferring those source code files that define the subset. 
     Still further related aspects of the invention provide methods, e.g., as described above, where source code files defining formats of the user interface components are cascading style sheets (CSS). 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       A more complete understanding of the invention may be attained by reference to the drawings, in which: 
         FIG. 1  depicts a digital data processing system for practice of the invention, as well as a system in which the invention may be practiced; 
         FIG. 2  depicts operation of an optimization application in a system according to one practice of the invention; 
         FIG. 3  depicts operation of a crawler in a system according to one practice of the invention; 
         FIG. 4  depicts operation of the CSS optimizer in a system according to one practice of the invention; 
         FIG. 5  depicts further aspects of operation of the CSS optimizer in a system according to one practice of the invention; 
         FIG. 6  depicts generation of a style sheet bundle in a system according to one practice of the invention; and 
         FIG. 7  depicts operation of an optimizer in a system according to one practice of the invention. 
     
    
    
     DETAILED DESCRIPTION OF THE ILLUSTRATED EMBODIMENT 
     Architecture 
       FIG. 1  depicts a digital data processing system  10  for practice of the invention, as well as a system  10  in which the invention may be practiced. The system  10  includes a server digital data processor  12  that is coupled to client digital data processors  14 ,  16  and  18  via a network  20  comprising a combination of one or more of the Internet, a wide area network (WAN), metropolitan area network (MAN), local area network (LAN), telephone networks and/or a combination of these and other networks (wired, wireless, public, private or otherwise). 
     The illustrated client digital data processors  14 - 18  are conventional tablet computers, PDAs, mobile phones or other digital data apparatus (including, for example, desktop computers, workstations, minicomputers, and laptop computers) of the type that are commercially available in the marketplace and that are suitable for operation in the illustrated system as described herein and all as adapted in accord with the teachings hereof. 
     The digital data devices  14 - 18  each comprise central processing, memory, storage and input/output units and other constituent components (not shown) of the type conventional in the art that cooperate to execute applications  14   a - 18   a , each of which comprises a web application of the type commercially available in the marketplace or otherwise known in the art and operative on the respective devices  14 - 18  for, by way of example, for purposes of presenting user interfaces on the respective devices  14 - 18 , presenting data in connection therewith received from the server  12 , user or otherwise, accepting user input with respect to those interfaces, issuing HTTP/HTTPS (collectively, “HTTP”) requests to the server  12  for those interfaces and/or for requesting and/or submitting information with respect thereto, and so forth, all as per convention in the art as adapted in accord with the teachings hereof. Those web apps can comprise HTML, JavaScript, cascading style sheets (CSS), and so forth, and they can execute within the context of a web browser (not shown), a WebKit, or otherwise—again, per convention in the art as adapted in accord with the teachings hereof. 
     The central processing, memory, storage and input/output units of client digital data processors  14 - 18  may be configured to form and/or may be supplemented by other elements of the type known in the art desirable or necessary to support applications  14   a - 18   a , respectively, in accord with the teachings hereof, as well as to support other operations of the digital data processor  12 . These can include, by way of non-limiting example, peripheral devices (such as keyboards and monitors), operating systems, and network interface cards and software, e.g., for supporting communications with server digital data processor  12  and other devices over network  20 . 
     Although client digital data processors  14 - 18  are depicted and described in like manner here, it will be appreciated that this is for sake of generality and convenience: in other embodiments, these devices may differ in architecture and operation from that shown and described here and/or from each other, all consistent with the teachings hereof. 
     Like client digital data processors  14 - 18 , server digital data processor  12  is a digital data processing apparatus of the type commercially available in the marketplace suitable for operation in the illustrated system as described herein, as adapted in accord with the teachings hereof. Though the server  12  is typically implemented in a server-class computer, such as a minicomputer, it may also be implemented in a desktop computer, workstation, laptop computer, tablet computer, PDA or other suitable apparatus (again, as adapted in accord with the teachings hereof). 
     Server digital data processor  12 , too, comprises central processing, memory, storage and input/output units and other constituent components (not shown) of the type conventional in the art that are configured in accord with the teachings hereof to form rules engine  22  and rules base  24 , transaction database  26 , language database  28  and context registry  30 , one or more of which may be absent in various embodiments of the invention. 
     Although only a single server digital data processor  12  is depicted and described here, it will be appreciated that other embodiments may have greater or fewer numbers of these devices. 
     Those other servers may differ in architecture and operation from that shown and described here and/or from each other, all consistent with the teachings hereof. Still further, although server  12  of the illustrated embodiment is depicted as being remotely disposed from the client digital data processors  14 - 18 , in other embodiments, one or more of the client devices may be co-housed with the server. 
     Rules base  24  comprises a conventional rules base of the type known in the art (albeit configured in accord with the teachings hereof) for storing digitally encoded rules  25  and other application-related information in tables, database records, database objects, and so forth. Such stored rules  25  are likewise formatted and stored in the conventional manner known in the art (albeit configured in accord with the teachings hereof). Here, rules base  24  is configured and contains rules for use in business process management applications, though in other embodiments it may be configured and used for other applications. Such a rules base can be of the type described in the US patents and patent applications assigned to the assignee hereof, e.g., U.S. Pat. Nos. 5,826,250, 6,976,144, 7,665,063, 8,335,704, 7,711,919, 7,640,222, 8,250,525, US 20080208785, US 20090132232, U.S. Pat. Nos. 8,843,435, 8,479,157, 8,468,492, 8,880,487, 8,924,335, 9,189,361, US 20130231970, U.S. Pat. Nos. 9,678,719, 8,959,480, 9,270,743, US 20150127736, U.S. Pat. No. 9,658,735, US 20160098298, US 20170090685, US 20170255341, the teachings of which are incorporated by reference herein; though, a rules base that is architected and/or operated differently may be used as well or in addition, as may be another store and/or repository of applications, apps and other software suitable for use in connection herewith. 
     Although shown in the illustrated embodiment as part of server  12 , rules base  24  (or other repository) may reside elsewhere, e.g., remote to server  12 . Moreover, some embodiments may utilize multiple rules bases, e.g., an enterprise-wide rules base  24  on the server  12  and domain-specific rules bases on one or more of client devices  14 - 18 , all by way of example. To the extent that multiple rules bases are provided in any given embodiment, they may be of like architecture and operation as one another; though, they may be disparate in these regards, as well. Utilization of multiple rules bases may be accomplished in the manner described in one or more of the above-cited incorporated-by-reference U.S. patents and patent applications, e.g., U.S. Pat. No. 8,924,335, entitled “Systems and Methods for Distributed Rules Processing,” the teachings of which are incorporated heron by reference. 
     Transactional database  26  comprises a conventional database of the type known in the art (albeit configured in accord with the teachings hereof) for storing corporate, personal, governmental or other data that may be any of generated, stored, retrieved and otherwise processed (hereinafter, collectively referred to as “processed”) by rules in rules base  24  and/or rules stored/executed elsewhere. The data may be financial data, customer records, personal data, run-time data related to an application, or other type of data and it may be stored in tables, database records, database objects, and so forth. 
     As above, some embodiments may utilize multiple transactional databases, e.g., an enterprise-wide database  26  on the server  12  and branch-office specific databases on the client devices  14 - 18 , all by way of example. To the extent that multiple transactional databases are provided in any given embodiment, they may be of like architecture and operation as one another; though, may they be disparate in these regards, as well. Utilization of multiple transactional databases may be accomplished in the manner described in incorporated-by-reference U.S. Pat. No. 8,924,335. 
     Language base  28  encodes information regarding the syntax of the language (or languages) in which user interfaces generated by server  12  are presented on devices  14 - 18  and, more particularly, in the illustrated embodiment, by applications  14   a - 18   a . That syntax can include one or more of grammar, spelling, usage, punctuation, and/or style. The language base  28  may comprise a language database of the variety commercially available in the marketplace—e.g., in the manner of spelling and grammar dictionaries provided with conventional word processors (which “dictionaries” often include usage-, punctuation- and/or style-related entries). Alternatively, the language syntax information may be embodied in one or more rules  25  of the rules base  24 , or otherwise. 
     Context registry  30  is a store that includes information related to the respective contexts or circumstances in which the requested user interfaces (e.g., web pages) are and/or will be communicated to and executed on the respective client devices  14 - 18 . That context or circumstance can include, by way of non-limiting example, user “properties” or business attributes (e.g., access requirements, disability settings, market segment, behavioral segment, age, locale, and so forth), client device  14 - 18  properties (e.g., processor speed, display size, keyboard capabilities, locale, and so forth), communication channel properties (e.g., the speed and type of connection between server  12  and the respective client devices  14 - 18 ) and portal properties (e.g., download file size limits, quality-of-service requirements and so forth). That context or circumstance can further include, by way of non-limiting example, the language, country and/or other locale settings and preferences of the user of a device on which the web page is to be displayed. Still other variations in the possible range of values stored in the context registry  30  are possible. 
     Illustrated digital data processor  12  also includes rules engine  22  of the type conventionally known in the art (albeit configured in accord with the teachings hereof) for use in processing rules from a rules base in order to process data, e.g., in (and/or for storage to) a transactional database in view of a language base and/or context registry or other data sources described above, for example, in connection with events signaled to and/or detected by the engine. In the illustrated embodiment, the rules engine is of the type used for business process management applications, though in other embodiments it may be of the type used for other applications. Preferred such rules engines are of the type described in the aforementioned incorporated-by-reference U.S. Pat. No. 5,826,250, entitled “Rules Bases and Methods of Access Thereof” and U.S. Pat. No. 7,640,222, entitled “Rules Base Systems and Methods with Circumstance Translation” and/or U.S. Pat. No. 8,250,525, entitled “Proactive Performance Management For Multi-User Enterprise Software Systems,” the teachings too of which are incorporated by reference herein-all as adapted in accord with the teachings hereof. 
     The rules engine  22  may be implemented in a single software program or module, or a combination of multiple software modules/programs. Moreover, it may comprise programming instructions, scripts, rules (e.g., rules stored in rules base  24 ) and/or a combination of thereof. And, even though the rules engine  22  of the illustrated embodiment is depicted as executing on just server digital data processor  12 , in other embodiments, the engine may execute on or across multiple digital data processors (e.g.,  12 ,  14 ,  16  and  18 ). Executing the engine  22  over multiple digital data processors may be accomplished in the manner described in incorporated-by-reference U.S. Pat. No. 8,924,335, by way of non-limiting example. 
     Described below is a method of operating system  10  and, particularly, server  12  and still more particularly, by way of example, rules engine  22 , to optimize instantiations of a model app  42  for download from that device  12 , rules base  24  and/or engine  22  to one or more client devices  14 - 18  for execution thereon, e.g., as a web app  14   a - 18   a . This may be, for example, at the request of a user of one of those devices issued via a web browser executing thereon or otherwise; conversely, such download may be effected sans user request, e.g., upon boot-up of a respective one of the devices  14 - 18  or otherwise—all as per convention in the art as adapted in accord with the teachings hereof. 
     As used here, to “optimize” the app  42  means to reduce the footprint of JavaScript code and/or cascading style sheets (CSS) that make up the app  42  as downloaded vis-à-vis instantiations thereof to the requesting device  14 - 18 , e.g., based on the nature of that device, the access requirements (i.e., “role”) of the user of that device making the request and/or on behalf of whom the request is made, and the portal (i.e., the web site or web address) to the which download request was made and/or from which the request is fulfilled. The app  42  is occasionally referred to herein as an app “model” because it includes rules and style sheets for all combinations of portals, requesting devices and user roles. 
     In the illustrated embodiment, that method is carried out by an optimization application  32  alone and/or in cooperation with other functionality of the server  12  and/or client devices  14 - 18 , as evident in the discussion below. Application  32  of the illustrated embodiment is implemented in rules that are stored in rules base  24  and executed by rules engine  22  upon invocation. However, other embodiments may vary in this regard. Thus, for example, application  32  may be embodied in other software formats, sourced from other repositories and executed other than on a rules engine. 
     Likewise, in the illustrated embodiment, model apps which are instantiated for download to requesting devices  14 - 18  (e.g., model app  42  mentioned above and discussed below) are sourced from rules base  24 . In such an embodiment, the app  42  is represented by a set of rules (e.g., from the rules base  24 ) that combine to define the app&#39;s functions and features when executed, e.g., as an app  14   a - 18   a  within a browser or otherwise the requesting device. In other embodiments, the app  42  may be represented in other software formats and executed according within browsers or otherwise on the respective devices  14 - 18 . 
     Optimization Application 
     Referring to  FIG. 2 , in step  200 , the optimization application  32  is invoked in real-time mode or batch mode by rules engine  22  or other functionality executing on server  12 . Real-time mode refers to invocation in real-time response to a request by a client device  14 - 18  for download of an instantiation of app  42  to be executed on that device. Batch mode refers to invocation of the application  32  in advance of such a request—e.g., as where the application  32  is invoked to generate instantiations of the app  42  that are expected to meet possible future such requests. Invocation of the application  32 , whether implemented in rules or otherwise in real-time mode or in batch mode, is within the ken of those skilled in the art in view of the teachings hereof. 
     In step  202 , an application crawler  44  that forms part of optimization application  32  parses and/or otherwise crawls the source code of app  42 , that is, the rules or other source code instructions (hereinafter, collectively, “source code rules” or, simply, “rules”) comprising app  42  to identify source code files or portions thereof, including user interface components—all, collectively, referred to herein as “components”—for use with an instantiation of app  42  ( i ) for download from a designated portal, (ii) for execution on a designated (requesting) device  14 - 18 , and/or (iii) by a user having a designated role or, put another way, for use with an instantiation of app  42  for download and execution in connection with a specific combination of portal, device and/or user role. In the illustrated embodiment, the source code  42  is JavaScript and related programming instructions/declarations, e.g., embedded scripting languages, style sheets, and the like, all as within the ken of those skilled in the art in view of the teachings hereof. In other embodiments, the source code files may include other source code programming languages, instead or in addition. 
     The crawler  44  generates, in step  202 , a report  46  referred to in the drawings as a “crawler usage report”; although, it need not be a report in the conventional sense of a human-readable document but, rather, may comprise any memorialization of identified components, e.g., in binary, XML, or otherwise, as is within the ken of those skilled in the art in view of the teachings hereof. The report can be stored in a dedicated file, as part of a database or otherwise, on server  12  or otherwise. Operation of the crawler  44  may be further appreciated in connection with  FIG. 3  and the discussion thereof below. 
     In addition to the foregoing, the crawler usage report  46  is supplemented to include, for each listed component, names or identities of one or more JavaScript (“JS”) files that implement (i.e., contain code defining) the component—or, put another way, the JS files on which the component depends. In addition, the report  46  can identify user interface features implemented by those files—or, put another way, the JS files on which those features depend. The crawler usage report  46  can, moreover, be supplemented to indicate when each JS file is preferably loaded. For example, such load order can be designated as “top,” “template” or “bottom” bundle (as described further below). 
     The foregoing component-to-file and feature-to-file dependencies and bundle designations can be added to the report  46  automatically by the application crawler  44  and/or with the assistance of an administrator, software engineer or other human agent. Alternatively, or in addition, the crawler  44  can rely on a file or other listing of such dependencies and/or load order for purposes of supplementing the report  46 . 
     As used above and elsewhere herein, a portal designation can be with respect to a specific portal address (or portion of such address) from which the instantiation is to be downloaded (or, as used synonymously therewith herein, to which a request for download is made), or with respect to a role served by such portal (e.g., a portal that serves production code vs test code, etc.), and so forth, as is within the ken of those skilled in the art in view of the teachings hereof. Likewise, above and elsewhere a device designation can be with respect to a specific device address (e.g., as specified by MAC address, or other unique identifier) or device type (e.g., as specified by operating system, browser or webkit type, processor class, memory or other storage capacity, display type/size, data communication speed and type, and so forth), or otherwise, as is within the ken of those skilled in the art in view of the teachings hereof. Furthermore, above and elsewhere a user role designation can be with respect to a specific role, e.g., end user, developer, administrator and so forth, as reflected in an active directory, user name requirement codes or otherwise, as is within the ken of those skilled in the art in view of the teachings hereof. In some embodiments, the user role designation/identification can extend to a level of granularity of individual users in which case the designation/identification can be by user name, ID or other unique identifier. 
     In step  206 , a JavaScript optimizer  48  that forms part of optimization application  32  generates for the components identified in Step  202  and reflected in the report  46  (i.e., the components identified as being for use with an instantiation of app  42  for download and execution in connection with a specific combination of portal, device and/or user role) a dependency-ordered stack of source code files containing the components so identified. In step  208 , the JavaScript optimizer combines the dependency-ordered stacks generated in step  206  into a single dependency-ordered stack. In step  210 , the JavaScript optimizer  48  prepares for transfer to and loading on a requesting client device  14 - 18  (and, particularly, for example, within the environment of a browser or webkit of such device) the source code files identified in the dependency-ordered stack generated in step  208 . The optimizer  48  prepares for such transfer in an order that is based on the dependency order specified in that stack. In embodiments, in which the steps  200 - 210  are executed in real-time mode, the optimizer  48  can, alone or in cooperation with other elements of server  12 , proceed with transfer of those files in that order, via HTML stream or otherwise, as is within the ken of those skilled in the art in view of the teachings hereof. Where, on the other hand, steps  200 - 210  are executed in batch mode the optimizer can delay such transfer until such a corresponding request is received. Operation of the optimizer  48  as per steps  206 - 210  may be further appreciated in connection with  FIG. 7  and the discussion thereof below. 
     In some embodiments, the optimizer  48  transfers (or prepares for transfer) the source code files to the requesting client  14 - 18  in multiple bundles, including (i) a top bundle  50  comprising source code loaded as soon as page is visible upon execution of the app on the client digital data device by the user, (ii) a template bundle  52  comprising source code loaded before control rendering begins upon execution of the app on the client digital data device by the user, and (iii) a bottom bundle  54  comprising source code loaded at an end of an initial page load upon execution of the app on the client digital data device by the user. In each instance, the bundles are transferred in accord with the dependency order specified in the single dependency-ordered stack. In other embodiments, the JavaScript optimizer  48  may transfer the source code files in greater, fewer and/or different bundles. The segregation of files into such bundles and their transfer to the client devices  14 - 18  is within the ken of those skilled in the art in view of the teachings hereof. 
     As discussed above, in step  202 , the application crawler  44  can parse/crawl rules comprising app  42  to identify components for use with an instantiation of app  42  for download and execution in connection with a specific combination of portal, device and/or user role. In step  202  of some embodiments, the crawler  42  can, alternatively or in addition, identify the cascading style sheets (hereinafter, simply, “style sheets”) used by the app  42 , a set of user interface components, features of those user interface components, and formats of those user interface components or features—all, collectively, referred to herein as a set of “style features”—for use with instantiations of app  42  downloaded from a plurality of different portals for execution on a plurality of different (requesting) devices  14 - 18 , and/or by a plurality of users having different role. The crawler can, furthermore, identify a subset of those style features that are not for use with an instantiation of app  42  ( i ) for download from a designated portal, (ii) for execution of a designated (requesting) device  14 - 18 , and/or (iii) by a user having a designated role or, put another way, that are not for use with an instantiation of app  42  for download and execution in connection with a specific combination of portal, device and/or user role. In embodiments where step  202  includes identifying style features, step  202  can include generating the report  46  to include such style features as fall within the aforesaid set, along with those that fall in the aforesaid subset. 
     Moreover, in such embodiments, a CSS optimizer  56  that forms part of optimization application  32  can, in step  212 , prepare for transfer to and loading and execution on the client device  14 - 18  (and, particularly, for example, the browser of such a device) files that define style sheets that are in the aforesaid set but that are not in the aforesaid subset. In embodiments in which the steps  200 - 202  and  212  are executed in real-time mode, the optimizer  56  can, alone or in cooperation with other elements of server  12 , proceed with the file transfer via HTML stream or otherwise, as is within the ken of those skilled in the art in view of the teachings hereof. Where, on the other hand, those steps are executed in batch mode the optimizer can delay such transfer until such a corresponding request is received. 
     Operation of the CSS optimizer  56  may be further appreciated in connection with  FIGS. 4-5  and the discussion thereof below. 
     Application Crawler 
       FIG. 3  depicts operation of an application crawler  44  according to one practice of the invention. As noted above, the crawler parses/crawls a set of rules defining an app model  42  to identify components used in execution of an instantiation of that model for a specific combination of portal, device and/or user role. 
     In step  300 , the crawler  44  discerns the portal in connection with which the components of app  42  are to be identified. In real-time mode, the crawler  44  can determine the portal of a just-received request from the identity of a function or page from which it (the crawler  44 ) is invoked, from the identity of a server  12  upon which the crawler  44  is executing, or as otherwise within the ken of those skilled in the art in view of the teachings hereof. In batch mode, the portal associated with a possible future request can be passed as a parameter to the crawler  44 , e.g., by the rules engine  22  or other functionality executing on server  12  that iterates through portal/device/user-role combinations for purposes of generating such instantiations in advance, or otherwise, as is within the ken of those skilled in the art in view of the teachings hereof. 
     In step  302 , the crawler  44  discerns the user role (or “access group”) in connection with which the components of app  42  are to be identified. In real-time mode, the crawler  44  can determine the role/access group of a user from a cookie maintained on that user&#39;s device, from a parameter passed by a function or page from which the crawler  44  is invoked, or as otherwise within the ken of those skilled in the art in view of the teachings hereof. The crawler  44  can likewise determine the role/access group associated with at possible future request, i.e., in batch mode, from a parameter passed by the functionality that iterates through portal/device/user-role combinations, or otherwise, as is within the ken of those skilled in the art in view of the teachings hereof. 
     In step  304 , the crawler  44  discerns the device in connection with which the components of app  42  are to be identified. In real-time mode, the crawler  44  can determine the role/access group of a user by querying the browser, webkit or other functionality executing on the user device  14 - 18  from which the download request was initiated, from a parameter passed by a function or page from which the crawler  44  is invoked, or as otherwise within the ken of those skilled in the art in view of the teachings hereof. The crawler  44  can likewise determine the device associated with at possible future request, i.e., in batch mode, from a parameter passed by the functionality that iterates through portal/device/user-role combinations, or otherwise, as is within the ken of those skilled in the art in view of the teachings hereof. 
     Although  FIG. 3  illustrates determination by crawler  44  of each of the portal, user role and device for purposes of identifying components used in execution of an instantiation of app model  42 , other embodiments may use only one or two of those determinants—e.g., user role and portal, by way of non-limiting example—and, hence, in the discussion that follows they are connected by the grammatical conjunction “and/or.” 
     In step  306 , the crawler  44  recursively iterates, in both depth and breadth, through rules contained in app model  42  beginning at the execution entry point for the specified combination of portal, device and/or user role. In the illustrated embodiment, the crawler  44  iterates through the rules on a file-by-file basis, as reflected by the source code files depicted as elements  48  in the drawing. As used here, “entry point” (or “app root”) refers to the programming instruction and, more generally, the component at which execution of the instantiated app will begin, upon user request or otherwise, following download. The identification of that entry point, as typically, based on requirements associated with one or more of the designated portal, user role and/or device, is within the ken of those skilled in the art in view of the teachings hereof. 
     Such recursive iteration can be effected by executing the following steps, beginning at the entry point: (i) iterating (or stepping) through each instruction (or “rule,” as used herein synonymously therewith) of source code in a component and (ii) identifying each further component (if any) that instruction references which further component is available and suitable for execution in view of the designated combination of portal, user role and/or device—and, repeating those steps (i) and (ii), in turn (i.e., recursively), for each such referenced component. As each component available and suitable for execution in view of the designated combination of portal, user role and device is identified through this iterative recursion, the crawler  44  stores the component&#39;s name or other identification to report  46 . Such instruction-by-instruction iteration can be effected through a line-by-line examination of the source code. Alternatively, it can be effected using information in a source code model that represents each source code file, e.g., with metadata that includes component dependencies (as defined by an administrator, software engineer, automated analysis or otherwise). A benefit of this latter approach is avoidance of line-by-line parsing of the source code concurrently with execution of optimization application  32 . 
     In addition to identifying component dependencies during recursive iteration of the app model  42 , the crawler  44  also identifies user interface features that depend on the examined source code files. For example, a source code file may be marked (in the aforesaid source code model) with metadata indicating that file is used for a button component that is formatted (i.e., displayed) as a text link. Another file may be marked by such metadata that indicates the same button component is formatted as an image. By storing those file-based UI feature dependencies, e.g., to report  46 , the crawler  44  makes possible the building of bundles that avoid inclusion of unnecessary source code, as discussed further below. 
     In some embodiments, in step  306 , the crawler  44  recursively iterates through all rules that are available and suitable for execution for the designated combination of portal, user role and/or device, as described above. In other embodiments, the crawler  44  skips (i.e., does not perform aforesaid steps (i) and (ii)) on components that are marked as “blacklisted”, e.g., as indicated by the black triangle superimposed over one of the files  48  in the drawing. A listing of files to be skipped in this regard can be reflected in a store (not shown) associated with the crawler  44 , the engine  32 , the server  12  or otherwise, as per convention in the art as adapted in accord with the teachings hereof. Such components can be identified in such a store by file name, line range, rule name or id, and/or via other convention within the ken of those skilled in the art as adapted in accord with the teachings hereof. As a consequence, components on which blacklisted ones depend (e.g., components that are themselves specified within a blacklisted component and that, therefore, are necessary for the blacklisted component to execute) will not be identified as necessary for execution—unless those depended-upon components are crawled during processing of other, non-blacklisted components of the app  42 . 
     Conversely, in other embodiments, the crawler  44  can, in step  308 , recursively iterate through all rules that make up components that are “whitelisted,” e.g., regardless of whether those components are available and suitable for execution in view of the designated combination of portal, user role and/or device. As above, such whitelisted components can be identified in such a store by file name, line range, rule name or id, and/or via other convention within the ken of those skilled in the art as adapted in accord with the teachings hereof. 
     Application crawler  44  stores to the usage report  46  a report of rules and, more generally, components used in execution of an instantiation of app model  42  for the specific combination of portal, device and/or user role. It can supplement that with dependencies and load-order pertaining to each component, as discussed above. 
     CSS Optimizer 
       FIGS. 4-5  depict operation of the CSS optimizer  56  according to one practice of the invention in regard to building optimization representations from the usage report  46 .  FIG. 4  depicts the first part of that process resulting in identification of CSS generation elements required for an instantiation of model app  42  for a specific combination of portal, device and/or user role.  FIG. 5  depicts the second part of that process, resulting in a listing of a subset of CSS style feature-related files not necessary for that particular instantiation, which subset is defined with respect to the set of all CSS style feature-related files used by the app  42  independent of portal, device and user role. 
     In step  400 , the optimizer  56  maps (i) cascading style sheets (CSS) for buttons, check boxes and other user interface widgets (collectively, referred to here as “generation elements” or “Gen El”) used in the model  42  as a whole to (ii) components identified as used in execution of an instantiation of the model  42  for a specific combination of portal, device and/or user role. The components are reflected in the crawler usage report  46 , which is generated as discussed above in connection with  FIGS. 2-3 . The CSS for generation elements is reflected in a map  58 , which is generated from an application rule  24  that describes the complete set of CSS Generated Elements and formats that may be used by an application model  42 . In the illustrated embodiment, the mapping by the optimizer in step  400 , that is, the mapping of CSS generation elements to components is 1 to m, where m is an integer greater than or equal to one. 
     The mapping of generation elements to components or other values, as reflected in step  400  and elsewhere herein, is within the ken of those skilled in the art in view of the teachings hereof. Such mappings can be reflected in tables, arrays, linked lists or otherwise, whether stored in binary, text or otherwise, as is within the ken of those skilled in the art in view of the teachings hereof. 
     In step  402 , the optimizer  56  maps each CSS generation element used in the model  42  as a whole to a Boolean value (e.g., true or false) reflecting whether that element appears in the mapping generated in step  400 . Put another way, the optimizer  56  in step  402  assigns each CSS Gen El used in model  42  as a whole a value of true or false, depending on whether that CSS Gen El is used in a component that appears in the usage report  46 . In addition to assigning a value of false to each CSS Gen El not used in a component in that report  46 , the optimizer assigns a value of false to each generation element that is blacklisted, e.g., as reflected in the store referred to above in connection with step  306  or otherwise. See step  404 . By this mechanism, embodiments can prevent the download of CSS generation elements that have been deprecated. 
     Although Boolean values are mentioned above and elsewhere herein, it will be appreciated that other values may be used instead or in addition. Moreover, it will be appreciated that in lieu of mapping CSS Gen El to Boolean (or other) values, alternative techniques within the ken of those skilled in the art for reflecting the same information may be used instead or in addition. 
     In step  406 , the optimizer  56  stores the resultant mapping of CSS generation elements—i.e., the mapping of CSS Gen El to true or false values reflecting whether (or not) those elements are used by components in the report  46  or, regardless, whether they have been deprecated or otherwise blacklisted—as a so-called component usage map  60 . As noted above, this can be represented in tables, arrays, linked lists or otherwise; moreover, it can be stored internal to the optimizer  56 , the engine  22 , the server  12  or otherwise. In embodiments operating in real-time mode, it can be stored to the requesting client device  14 - 18 , in addition or instead. 
     In step  408 , the optimizer  56  maps each CSS generation element identified in step  400  as used by a component in the usage report to one or more formats available to that element. This allows the comparison of formats that are possibly used (i.e., as defined in the “Skin” rule mentioned above) with the formats that crawler had seen as being used, skipping the generation of CSS for any Formats that aren&#39;t used. 
     As used above and throughout, a “format” is a collection of CSS styles that are used together to provide a particular look (e.g., a “bold button” definition that calls for boldface text and a rounded rectangle outline with a 2 px border). In the illustrated embodiment, the mapping by the optimizer in step  408  of CSS to Gen El to formats is 1 to m, where m is an integer greater than or equal to one. 
     In step  410 , the optimizer  56  supplements the mapping generated in step  408  to include synonyms of the formats generated by that prior step. Such synonyms can be obtained from definition files (not shown here), entered by an administrator or otherwise. Additional formats required for a given implementation, e.g., formats for standard fonts and colors used by a given enterprise, website or otherwise, can likewise be added in step  412 . 
     In step  414 , the optimizer  56  stores the resultant mapping of CSS generation elements—i.e., the mapping of CSS Gen El to formats, their synonyms and required formats—as a so-called format usage map  62 . As noted above, this can be represented in tables, arrays, linked lists or otherwise; moreover, it can be stored internal to the optimizer  56 , the engine  22 , the server  12  or otherwise. In embodiments operating in real-time mode, it can be stored to the requesting client device  14 - 18 , in addition or instead. 
       FIG. 5  depicts further operation of the CSS optimizer  56  according to one practice of the invention; here, in regard to generating a listing  64  of the subset of CSS style feature-related files not necessary for instantiation of the model app  42  for given combination of portal, device and/or user role. 
     The listing is generated from the crawler usage report  46  and the usage maps  60 ,  62 . Significantly, it is also generated from a base listing  66  of the set of files containing CSS source code associated with model app  42  for all combinations of portal, device and user role. That base listing is referred to, here, as the pzBase. The listing  66  may be generated automatically, e.g., by a integrated development environment, or by an administrator or other person, and/or by a combination of the foregoing, and it may be a text file, binary or otherwise, all as is within the ken or those skilled in the art in view of the teachings hereof. 
     In step  500 , the optimizer  56  stores to the file containing listing  64  (which file may be a text file, binary or otherwise, as is within the ken of those skilled in the art in view of the teachings hereof) the names or other identifiers of files listed in the pzBase file  66  which are blacklisted, e.g., as reflected in the store discussed above in connection with step  306 . 
     In step  502 , the optimizer  56  stores to the file containing listing  64  the names or other identifiers of files listed in the pzBase file  66  which contain CSS generation elements that are not necessary for instantiation of the model app  42  for a given combination of portal, device and/or user role, e.g., as evident from the report  46  and/or maps  60  and  62 . 
     In step  504 , the optimizer  56  stores to the file containing listing  64  the names or other identifiers of files listed in the pzBase file  66  which reflect formats that are not used for CSS generation elements for instantiation of the model app  42  for a given combination of portal, device and/or user role, e.g., as evident from the report  46  and/or maps  60  and  62 . 
     In step  506 , the optimizer  56  stores to the file containing listing  64  the names or other identifiers of files listed in the pzBase file  66  which are associated with user interface components that are not necessary for instantiation of the model app  42  for a given combination of portal, device and/or user role, e.g., as evident from the report  46  and/or maps  60  and  62 . 
     In step  508 , the optimizer  56  stores to the file containing listing  64  the names or other identifiers of files listed in the pzBase file  66  which contain CSS generation elements and user interface components that are not necessary for instantiation of the model app  42  for a given combination of portal, device and/or user role, e.g., as evident from the report  46  and/or maps  60  and  62 . 
     In step  510 , the optimizer  56  stores to the file containing listing  64  the names or other identifiers of files listed in the pzBase field  66  associated with user interface components for which formats are not necessary for instantiation of the model app  42  for a given combination of portal, device and/or user role, e.g., as evident from the report  46  and/or maps  60  and  62 . 
     In step  510 , the optimizer  56  stores to the file containing listing  64  the names or other identifiers of files listed in the pzBase file  66  associated with user interface components for which features are not necessary for instantiation of the model app  42  for a given combination of portal, device and/or user role, e.g., as evident from the report  46  and/or maps  60  and  62 . 
     Steps  500 - 512  can be run in parallel, in serial and/or in any order or combination in order to generate the listing  64 , which may be internal to the optimizer  56 , the engine  22 , the server  12  or otherwise. In embodiments operating in real-time mode, it can be stored to the requesting client device  14 - 18 , in addition or instead. 
       FIG. 6  depicts generation of a style sheet bundle  600  (“CSS Bundle” or “static content”), i.e., a collection of style feature-related files, for instantiation of the model app  42  for given specific combination of portal, device and/or user role. In the illustrated embodiment, this is done in three phases: a first phase  602  that includes selected files from the pzBase listing in file  66 ; a second phase  604  that includes selected CSS generation elements; and a third phase  606  that includes additional files selected from the pzBase listing  66 . Other embodiments may utilize a greater or lesser number of phases. 
     In phase  602 , the optimizer  56  prepares for download to the requesting device as part of the CSS Bundle  600  the set of files in base listing  66  ( FIG. 4 ) that are not in the listing  64  of the subset of files not necessary for instantiation of the model app  42  for a specific portal, device and/or user role combination. In some embodiments, the set can be the entirety of the files in base listing  66 ; however, in the illustrated embodiment, it is just those files that are designated for initial download. Typically, these are file associated with style sheets corresponding to JavaScript that will be loaded as soon as a page (or other screen) of the instantiation of app  42  begins execution on the requesting client device. 
     In phase  604 , the optimizer  56  iterates over CSS generation elements contained in store  58  ( FIG. 4 ), skipping over any listed in listing  64  and/or marked in format usage map  62  as unused for the specific portal, device, and/or user role combination. For each used (i.e., not skipped) generation element, the optimizer  56  iterates over each format potentially used by that element (e.g., as reflected in store  58  or otherwise) skipping over any formats listed in listing  64  and/or marked in component usage map  60  as unused for the specific portal, device, and/or user role combination. For each used (i.e., not skipped) format, the optimizer generates a cascading style sheet (or entry) for that format and prepares it for download as part of the CSS Bundle  600 . 
     In phase  606 , the optimizer  56  prepares for download to the requesting device as part of the CSS Bundle  600  remaining files in the set of in base listing  66  ( FIG. 4 ) that are not in the listing  64  of the subset of files not necessary for instantiation of the model app  42  for a specific portal, device and/or user role combination. In the set comprises those in listing  66  that are designated for final download. Typically, these are file associated with style sheets loaded at the ends of a page (or other screen) of the instantiation of app  42  after it begins execution on the target client device. 
     In embodiments operating in real-time mode, the bundle  600  can be downloaded to a target client device  14 - 18  at the time of its request and in connection with the download of JavaScript files to those devices. In embodiments operating in batch mode, the CSS bundle can be generated for download at a later time, or its generation and download can be deferred until corresponding requests are received, or otherwise, all as is within the ken of those skilled in the art in view of the teachings hereof. 
       FIG. 7  depicts generation of JavaScript source code files for download and execution in connection with a specific combination of portal, device and/or user role as discussed above in connection with steps  206 - 210 ; here, shown as steps  700 - 710 . 
     As shown in the drawing, the crawler usage report  46  provides an input to the illustrated processing sequence. That report  46  contains, as evident in the discussion above, a list of components used/unused in an instantiation of model  42  for download to the specific portal, device and/or user role. In addition, for each component that is marked as used, the report  46  includes a listing of features of that component, with each of them marked as used/unused, as well. 
     For each component in the report  46  marked as used by the specific portal/device/user-role combination, the JS optimizer  48  performs the recursive step(s) below and illustrated in the drawing:
         Step  700 : Create a “stack” of JS file dependencies for the component and store it for further processing. For each JS file in that stack, the JS optimizer  48  performs the step(s) of:
           Step  702 : Create a “stack” of JS file dependencies for the component and store it for further processing. For each JS file in that stack, the JS optimizer  48  performs the step(s) of:
               Create a “stack” of JS file dependencies for the component and store it for further processing.
                   Etc.   
                   
               
               

     The depth-and-breadth recursive descent stops when one of the recursive processing steps  700 ,  702 , etc.:
         (a) results in an empty dependency list (leaf node),   (b) results in a “cycle,” that is, uncovers a dependency already represented in an existing stack.       

     Stacks built as a result of recursive processing steps  700 ,  702 , etc., can be illustrated by the following example, which assumes that the report contains records identifying user interface components U1 through U3 and JavaScript components A through I as used for a specific portal/device/user-role combination, with the following dependencies (where “→” means “depends on”), including a circular dependency, reflected above, to wit, A→B→C→A . . . (etc.): 
     User Interface (U)I Components:
         U1→A   U2→D   U3→A and G       

     JavaScript Files:
         A→B   B→C   D→E   E→F   G→H and I   C→A (circular)       

     As a result of the processing in steps  700 ,  702 , etc., a stack is built for each JavaScript component or JS file encountered in the report  46 . Specifically, when a component or JS file is encountered, a dependency stack is created for that component file (if one doesn&#39;t exist). Then, its dependencies are opened in the order they appear (which can cause creation of that component/file dependency stack, etc.). Then, as the recursion is “unwound”, the “child” dependencies are read and pushed onto the “dependent&#39;s” stack. 
     In the illustrated embodiment, UI components themselves are not placed in a stack; only the JS components they are dependent upon are. Moreover, UI components do not depend upon other UI components; they are only dependent on JS components. However, in the illustrated embodiment JS components can be dependent upon other JS components and therefore can create circular references, e.g., as illustrated below. 
     For the specific example above, the annotations below show the order of the stacks being created, added to, etc. Further explanation is provided parenthetically. 
     U1 triggers a stack for A and subsequently B and C, as follows:
         Stack for A: B, (get stack B→C, A) stop at repeat, result: B, C   Stack for B: C, (get stack C→A, B) stop at repeat, result: C, A   Stack for C: A, (get stack A, stack A is in progress, so retrieve what it has, namely B), result: A, B       

     U2 triggers a stack for D and subsequently E, as follows:
         Stack for D: E (get stack E→F), result: E, F   Stack for E: F (leaf)       

     U3 triggers for stack A (already done previously) and a stack G, as follows:
         Stack for A: B, C   Stack for G: H (leaf), I (leaf)       

     As a result of the foregoing, the following stacks are built:
         Stack for U1: A, (get stack A→B, C), result: A, B, C   Stack for U2: D, (get stack D→E, F), result: D, E, F   Stack for U3 A (get stack A→B, C), G (get stack G→H, I), result: A, B, C, G, H, I       

     Combining U1, U2 and U3 dependency stacks produces the following:
         U1: A, B, C   Add U2: A, B, C, D, E, F   Add U3:   D, E, F, A, B, C, G, H, I       

     The final contents of the new (combined) stack can be read as file needing to be loaded in reverse order. In the example, this means load I, then load H, then G, etc. This also means C will be loaded before B which will be loaded before A, as the dependency indicates. These data representations also allow the optimizer  48  to note that a cyclic dependency remains (A needs to be loaded before C and C needs to be loaded before B which loads before A) indicating work that needs to be resolved in the code, e.g., by generating a warning message to an administrator or other. As a consequence, the optimizer  48  is able to generate a single dependency stack (reverse order—which is the desired load order). In this example, that would be
         I, H, G, C, B, A, F, E, D       

     In step  710 , the JavaScript optimizer  48  prepares for transfer to and loading on a requesting client device  14 - 18  the source code files identified in the dependency-ordered stack generated in step  708 . The optimizer  48  prepares for such transfer in an order that is based on the dependency order specified in that stack. In embodiments, in which the steps  700 - 710  are executed in real-time mode, the optimizer  48  can, alone or in cooperation with other elements of server  12 , proceed with transfer of those files in that order, via HTML stream or otherwise, as is within the ken of those skilled in the art in view of the teachings hereof. Where, on the other hand, steps  700 - 710  are executed in batch mode the optimizer can delay such transfer until such a corresponding request is received. In either case, the transfer of files can be effected in a conventional manner known in the art, e.g., via a compiler (e.g., GCC) or otherwise. 
     CONCLUSION 
     Described herein are systems and methods meeting the objects set forth above among others. It will be appreciated that the illustrated embodiments are merely examples of the invention and that other embodiments varying therefrom fall within the scope of the invention. Thus, for example, although in the illustrated embodiments, the illustrative app  42  comprises rules from rules base  24 , in other embodiments it may comprise software of other varieties from other repositories. This is likewise true of optimization application  32 . And, while the illustrated embodiment is designed to process JavaScript file source code, other embodiments may process source code in other languages. Other aspects of the invention provide methods, e.g., as described above, for identifying for download to a requesting client device a set of user interface components, features of those components, and formats of those components or features, used in execution of an app on a client digital data devices by users having a plurality different respective roles and/or portals from which they request transfer of the app for loading and execution.