Abstract: Described is a technology in which a destination machine (e.g., a server) is synchronized with source data via an API, including to configure the destination machine. The API includes functions for specifying the source data, the destination machine, and the deployment/synchronization type, along with a function for synchronizing the source data to the destination machine. The API allows combining content, configuration data and/or database data into a single unit (object). The API handles communication with a service/agent on the destination machine that configures that destination machine based on the source data. The API may include functions for packaging web applications, deploying web applications, synchronizing websites, deploying archive data, and/or deploying manifest data. In this manner, deployment/synchronization (including backup operations) may be performed against a group of objects using an API.

Abstract: Described is a technology in which a non-administrator computer/web user is allowed to perform an administrative-level task within a certain context and/or scope. An authorization store is queried based on information (e.g., a provider, a username, and a path) provided with an authorization request, e.g., from an application via an API. The information in the authorization store, set up by an administrator, determines the administrative action is allowed. If so, a credential store provides credentials that allow the action to be runs before reverting the user to the prior set of credentials. Also described is a pluggable provider model through which the authorization store and/or delegation store are accessed, whereby the data maintained therein can be any format and/or at any location known to the associated provider.

Abstract: Secure and stateless data transfer between a source agent at a first computer system and a destination agent at a second computer system is provided. A first list of labels of content structures is generated at the first computer system. During a first data transfer session, the first list, authentication information, at least one object included in the content structures, and file identifiers for one or more files included in the content structures are transferred from the first computer system to the second computer system. A second list is generated at the second computer system and received at the first computer system. The second list lists at least one requested file identified by the transmitted file identifier(s). During a second data transfer session, authentication information, the first list, the at least one object, and the requested file(s) are transferred from the first computer system to the second computer system.

Abstract: A web application may be developed in an environment which has different components than a target environment, so determining component dependencies and identifying which dependencies are met in a given environment can be helpful when deploying the application. Toward that end, test code makes a request that test file(s) be sent from a protected location in the target environment, such as from a randomly-named folder or from another location that is not directly browsable by a user. Received test file(s) and network protocol headers are parsed, and component dependency metadata such as component names and version numbers are extracted. Based on the extracted metadata, information is determined about the target environment's installed component(s). By comparing component dependency(ies) of the program with the identified installed component(s) of the target environment, compatibility of the target environment can then be reported.

Abstract: The customized execution of an executable accessed from a web server. Upon receiving a request for the executable, the web server determines a customization to be applied to the executable. For instance, arguments may be parsed from the Uniform Resource Locator (URL) of the request. The web server then sends a copy of the executable to the client, and provides customization argument(s) in the name of the executable. Thus, the name of the executable may differ, depending on the customization to be applied, although the executable binary itself may be the same. The client receives the executable copy, and interprets its name to determine the customization to be applied. For instance, the client may extract the argument(s) from the name of the executable, and provide those argument(s) to the executable when executed.

Abstract: A particular method includes storing a manifest file and a parameters file at a data store. The manifest file and the parameters file are associated with a software deployment package. An application associated with the software deployment package is published to a first remote computing device and to a second remote computing device. The method includes receiving first parameter values from the first remote computing device and receiving second parameter values from the second remote computing device. The first parameter values are stored in a first region of the data store that is specific to the first computing device. The second parameter values are stored in a second region of the data store that is specific to the second computing device.

Abstract: A web application may be developed in an environment which has different components than a target environment, so determining component dependencies and identifying which dependencies are met in a given environment can be helpful when deploying the application. Toward that end, test code makes a request that test file(s) be sent from a protected location in the target environment, such as from a randomly-named folder or from another location that is not directly browsable by a user. Received test file(s) and network protocol headers are parsed, and component dependency metadata such as component names and version numbers are extracted. Based on the extracted metadata, information is determined about the target environment's installed component(s). By comparing component dependency(ies) of the program with the identified installed component(s) of the target environment, compatibility of the target environment can then be reported.

Abstract: An installation package may have metadata concerning optional parameters for a software package to be installed. The metadata may be read by an installation system, and a user interface presented to a user for input on the parameters values. The installation system may store the parameters for later replication of the installation. The installation system may perform the installation on a local device or a remote device, and may further be capable of presenting the user interface on another device. In some embodiments, the metadata may be available to the installation system without having to open the installation package.

Abstract: Described is a technology in which a destination machine (e.g., a server) is synchronized with source data via an API, including to configure the destination machine. The API includes functions for specifying the source data, the destination machine, and the deployment/synchronization type, along with a function for synchronizing the source data to the destination machine. The API allows combining content, configuration data and/or database data into a single unit (object). The API handles communication with a service/agent on the destination machine that configures that destination machine based on the source data. The API may include functions for packaging web applications, deploying web applications, synchronizing websites, deploying archive data, and/or deploying manifest data. In this manner, deployment/synchronization (including backup operations) may be performed against a group of objects using an API.

Abstract: Secure and stateless data transfer between a source agent at a first computer system and a destination agent at a second computer system is provided. A first list of labels of content structures is generated at the first computer system. During a first data transfer session, the first list, authentication information, at least one object included in the content structures, and file identifiers for one or more files included in the content structures are transferred from the first computer system to the second computer system. A second list is generated at the second computer system and received at the first computer system. The second list lists at least one requested file identified by the transmitted file identifier(s). During a second data transfer session, authentication information, the first list, the at least one object, and the requested file(s) are transferred from the first computer system to the second computer system.

Abstract: Described is a technology in which a non-administrator computer/web user is allowed to perform an administrative-level task within a certain context and/or scope. An authorization store is queried based on information (e.g., a provider, a username, and a path) provided with an authorization request, e.g., from an application via an API. The information in the authorization store, set up by an administrator, determines the administrative action is allowed. If so, a credential store provides credentials that allow the action to be runs before reverting the user to the prior set of credentials. Also described is a pluggable provider model through which the authorization store and/or delegation store are accessed, whereby the data maintained therein can be any format and/or at any location known to the associated provider.