Automatic website data migration
By automatically detecting and migrating changes in the data model type through the migration agent of the website generation system, the difficulties of manual identification and modification in cross-CMS migration are solved, achieving efficient website development and resource conservation.
Patent Information
- Application Number
- CN202180049850.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2020-07-14
- Filing Date
- 2021-07-14
- Publication Date
- 2026-01-20
- Estimated Expiration
- 2041-07-14
AI Technical Summary
In existing technologies, website developers need to manually identify and modify data model types when migrating across different content management systems (CMS), resulting in a waste of time and resources and making it difficult to quickly start the website.
A website generation system is used to automatically detect and migrate changes in data model types by communicating with the software development tools through a migration agent, generating migration scripts to migrate the changes from one CMS to another.
It improves website development efficiency and speed, reduces resource consumption, and enables automated migration of data model types across CMS.
Smart Images

Figure CN116057533B_ABST
Abstract
Description
[0001] CLAIM OF PRIORITY
[0002] This application claims the benefit of priority to U.S. Patent Application Serial No. 16 / 946,986, filed July 14, 2020, the entire contents of which are incorporated herein by reference. TECHNICAL FIELD
[0003] The present disclosure relates generally to the generation and presentation of websites. BACKGROUND
[0004] The popularity of users interacting with other users online continues to grow. There are many ways for users to interact with other users online. Users can communicate with their friends using messaging applications and can play multiplayer video games with other users online, or perform other actions using various other applications. Often, the primary way users communicate with each other and obtain content is via websites. BRIEF DESCRIPTION OF DRAWINGS
[0005] In the drawings, which are not necessarily drawn to scale, like numerals can describe similar components in different views. To easily identify the discussion of any particular element or act, the most significant digit or digits in any
[0006] Figure 1 is a diagrammatic representation of a networking environment in which the present disclosure can be deployed according to some examples.
[0007] Figure 2 is a diagrammatic representation of a messaging system having functionality on both the client side and the server side according to some examples.
[0008] Figure 3 is a diagrammatic representation of a data structure maintained in a database according to some examples.
[0009] Figure 4 is a diagrammatic representation of a message according to some examples.
[0010] Figure 5 is a diagrammatic representation of a website generation system according to some examples.
[0011] Figure 6 is an illustrative user interface of a software development tool according to some examples.
[0012] Figure 7 is a diagrammatic representation of a website data model type migration according to some examples.
[0013] Figure 8is an illustrative website generated by a website generation system according to some examples.
[0014] Figure 9 is an illustrative website generated by a website generation system according to some examples.
[0015] Figure 10 is a flowchart illustrating example operations of a website generation system according to example implementations.
[0016] Figure 11 is a diagrammatic representation of a machine in the form of a computer system, according to some examples, within which a set of instructions can be executed to cause the machine to perform any one or more of the methodologies discussed herein.
[0017] Figure 12 is a block diagram illustrating a software architecture, wherein an example can be implemented. DETAILED DESCRIPTION
[0018] The description that follows includes systems, methods, techniques, instruction sequences, and computer program products in accordance with illustrative embodiments of the present disclosure. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide an understanding of various embodiments. It will be apparent, however, to one skilled in the art that embodiments can be practiced without some or all of these specific details. In general, well-known instruction instances, protocols, structures, and techniques have not been shown in detail.
[0019] Generally, a website developer generates a website by defining the content on the website, the behavior of elements on the website, and how the content appears visually on the website. That is, the website developer not only needs to generate the content on the website (e.g., pictures and text), but also needs to write code for how to present the content. Sometimes, the code used to define the website references data model types stored in a centralized repository, such as a content management system (CMS). Specifically, the CMS stores code for different data model types, and such code can be shared between other websites (typically in the same environment or space on the CMS). In some cases, a website developer can desire to modify the behavior or appearance associated with a particular data model type. To do so, the website developer must access the data model type stored on the CMS and make the desired changes to the data stored on the CMS. This process takes a significant amount of time, increases the cost, and slows down the speed at which a website can be launched. Furthermore, the website developer is typically limited to defining the website according to the data model types of a particular CMS and cannot easily apply changes to the data model types across different CMS applications. To apply changes to the data model types on different CMSs, the developer must manually search for and find the appropriate data model types, determine the differences, and apply the appropriate changes, which takes a significant amount of time and effort.
[0020] The disclosed implementations improve the efficiency and speed of developing and launching websites using a website generation system. The website generation system automatically migrates changes made to data model types to the data model types stored on one or more CMSs. Specifically, the disclosed website generation system retrieves website generation data from a CMS that references data model types stored on the CMS. The disclosed system, through a migration agent that communicates with a software development tool, such as GitHub, imports the definitions of the data model types referenced by the website generation data from the CMS as local versions of the data model types. The disclosed system detects changes to attributes of the local versions of the data model types through the migration agent and generates migration scripts to automatically migrate the changes to the data model types stored on the CMS. In some cases, the disclosed system determines mappings between data model types defined across different CMSs. In this way, a developer can make changes to data model types associated with a first CMS and the disclosed system automatically applies these changes to corresponding data model types of a second CMS. In this way, a developer can easily migrate website generation data from one CMS to another without needing to specifically identify and change the data model types on each individual CMS. In some cases, changes to model types on a CMS are detected by the migration agent and reflected in the software development tool. The migration agent or the software development tool can then apply the changes to another CMS.
[0021] The disclosed website generation system also accelerates the website development process and reduces the amount of resources required to generate a website. According to the disclosed implementations, the device resources (e.g., processor cycles, memory, and power usage) required by a device to complete a task are thereby reduced.
[0022] Networked computing environment
[0023] Figure 1 is a block diagram illustrating an example messaging system 100 for exchanging data, such as messages and associated content, over a network. The messaging system 100 includes multiple instances of client devices 102. The client devices 102 can host several applications, including a messaging client 104 and a software development tool 103. Each messaging client 104 is communicatively coupled to a messaging server system 108 and other instances of the messaging client 104 via a network 106, such as the Internet. The messaging server system 108 can include a content management system 107, in which case each software development tool 103 accesses website or website generation data from the content management system 107 via the messaging server system 108. In some implementations, all or a portion of the content management system 107 is implemented external to the messaging server system 108. In these cases, each software development tool 103 accesses a website directly from the content management system 107 via the network 106. While only one content management system (CMS) 107 is shown in Figure 1 multiple instances of the CMS 107 can be included.
[0024] The CMS 107 provides various spaces that store website generation data. Each space shares some code objects within the websites stored in a given space. The CMS 107 provides a data model that defines various looks and feels of websites. For example, the data model defines buttons and other graphical elements that can be added to a website. The data model includes multiple data model types, and stores code for implementing each data model type. The data model types each include attributes and tags. The attributes define various properties of the data model type, such as what happens when a button associated with the data model type is selected. In some cases, a data model type can be modified to add, delete, or modify attributes of the data model type. Any changes made to a data model type can be used by other website generation data stored within the same space or another space to allow the other website generation data to use the modified data model type. The data model types of one CMS 107 can be different from the data model types of another CMS 107. For example, one CMS 107 can define a button data model type that does not have any color attributes, while another CMS 107 can also define a button data model type that has color attributes.
[0025] Website generation data can be created and used to reference data model types stored in the CMS 107. By referencing a data model type stored in the CMS 107, there is no need to write code for generating or including a given data model type, such as a button, on a website. A software developer simply adds the data model type to the website generation data as a reference to the data model type, and when the website generation data is processed to display a web page, the corresponding code for the data model type is retrieved from the CMS 107 and included in the website generation data being requested.
[0026] In some embodiments, the software development tool 103 provides an application and graphical user interface that allows a software developer to write website generation data (e.g., website code). Once the website generation data is written, the website generation data is provided from the software development tool 103 back to the content management system 107. The CMS 107 stores the website generation data at a particular address, and when that address is requested by a web browser application, the CMS provides the code corresponding to the website generation data so that the web browser application can render a web page.
[0027] The software development tool 103 allows a software developer to write code using various tools. Some tools include error checking and undo operations. The software development tool 103 tracks changes made to the code at various stages and allows a software developer to test and revert to previous versions using undo operations. In some cases, the software development tool 103 includes the GITHUB software development tool. In some cases, the software development tool 103 includes a migration agent that monitors changes being made to data model types (on the software development tool or on the CMS) and migrates the changes to the CMS or another CMS. In some cases, the migration agent is a separate software application that communicates with the software development tool and monitors changes being made to data model types to migrate the changes to model types stored on the CMS.
[0028] The message clients 104 are capable of communicating with and exchanging data with one another and with the message server system 108 via the network 106. The data exchanged between the message clients 104 and between the message clients 104 and the message server system 108 includes functionality (e.g., commands to activate functionality) as well as payload data (e.g., text, audio, video, or other multimedia data).
[0029] The message server system 108 provides server-side functionality via the network 106 to particular message clients 104. While certain functions of the message system 100 are described herein as being performed by either a message client 104 or by a message server system 108, the placement of particular functions between the message client 104 or the message server system 108 can be a design choice. For example, it can be technically preferable to initially deploy certain technology and functions within the message server system 108 but to later migrate those technology and functions to the message client 104 where the client device 102 has sufficient processing capacity.
[0030] The message server system 108 supports various services and operations that are provided to the message clients 104. Such operations include sending data to, receiving data from, and processing data generated by the message clients 104. As an example, this data can include message content, client device information, geolocation information, media enhancements and overlays, message content persistence conditions, social network information, and live event information. The exchange of this data within the messaging system 100 is activated and controlled by way of functions available via a user interface (UI) of the messaging client 104.
[0031] Turning now specifically to the message server system 108, an application program interface (API) server 110 is coupled to, and provides a programmatic interface to, an application server 112. The application server 112 is communicatively coupled to a database server 118, which facilitates access to a database 120 that stores data associated with messages processed by the application server 112. Similarly, a web server 124 is coupled to the application server 112, and provides web-based interfaces to the application server 112. To this end, the web server 124 processes incoming network requests using HTTP and several other related protocols to serve a number of web pages to users of client devices 102.
[0032] The application program interface (API) server 110 receives and sends message data (e.g., commands and message payloads) between the client device 102 and the application servers 112. Specifically, the application program interface (API) server 110 provides a set of interfaces (e.g., routines and protocols) that can be called or queried by a message client 104 to activate functionality of the application servers 112. The application program interface (API) server 110 exposes various functions supported by the application servers 112, including: account registration; login functionality; sending messages from a particular message client 104 to another message client 104 via the application servers 112; sending media files (e.g., images or videos) from a message client 104 to the message server 114 and for possible access by another message client 104; setting media data collections (e.g., stories); retrieving a user's list of friends for a client device 102; retrieving such collections; retrieving messages and content; adding and deleting entities (e.g., friends) in an entity graph (e.g., social graph); locating friends in a social graph; and opening application events (e.g., related to a message client 104).
[0033] The application servers 112 host a number of server applications and subsystems, including for example, a message server 114, an image processing server 116, and a social network server 122. The messaging server 114 implements a number of message processing technologies and functions, particularly with respect to the aggregation and other processing of content (e.g., textual and multimedia content) included in messages received from multiple instances of the messaging client 104. As will be described in further detail, textual and media content from multiple sources can be aggregated into content collections (e.g., referred to as stories or libraries). These collections are then made available to the message client 104. Other processor and memory intensive processing of data can also be performed by the message server 114 on the server side, in view of the hardware requirements for such processing.
[0034] The application servers 112 also include an image processing server 116 that is dedicated to performing various image processing operations, typically with respect to images or videos within the payload of messages sent from or received at the message server 114.
[0035] The social network server 122 supports various social networking functions and services and makes these functions and services available to the message server 114. To this end, the social network server 122 maintains and accesses an entity graph 306 (as described in further detail below) within the database 120. Figure 3Examples of functions and services supported by the social network server 122 include identifying other users of the messaging system 100 with which a particular user has a relationship or "follows," as well as identifying interests and other entities of a particular user.
[0036] The migration generation server 128 can be implemented on the application server 112. Some elements or components of the migration generation server 128 can be included in the software development tools 103 of the client device 102. The migration generation server 128 tracks changes made to data model types in the software development tools 103 (e.g., changes to properties of data model types, such as adding a property, removing a property, or modifying an existing property), and automatically migrates these changes to the data model types stored in the CMS 107.
[0037] The CMS 107 stores website generation data for various entities. The CMS 107 can be a central repository for website data used to render websites. When new websites are created, their respective code (e.g., JSON or XML code) is uploaded and stored on the CMS 107, and references the data model types of the CMS 107 in which they are stored. The content management system 107 provides a specification for how object types (data model types) are defined in website generation data that is used by developers to generate the content and behavior of websites. Different entities can develop and upload different website generation data that uses the same schema to define object types.
[0038] In some implementations, the software development tool 103 invokes API functions associated with the CMS 107 to import or obtain all or a portion of the data model types available from the CMS 107. The imported data model types are stored as local versions of the data model types on the client device 102. The software developer can operate the software development tool 103 to generate website code (website generation data). The local versions of the data model types can be modified using the software development tool 103. The migration generation server 128 compares the local versions of the data model types to the versions of the data model types stored on the CMS 107. The migration generation server 128 automatically generates scripts to migrate any differences in the local versions of the data model types to the versions of the data model types stored on the CMS 107. For example, the software developer can add a new property for a given data model type by changing the local version of the data model type. The migration generation server 128 detects the change or the difference between the local version of the given data model type and the data model type stored on the CMS 107. In this case, the migration generation server 128 determines that a new property has been added. The migration generation server 128 uses the API of the CMS 107 to automatically write a migration script to add the new property to the version of the given data model type stored on the CMS 107.
[0039] Before modifying the version of the data model type stored on the CMS 107, the migration generation server 128 verifies that the modification is backward compatible. For example, the migration generation server 128 generates a demo version of the data model type with the modification made to the local version of the data model type. The migration generation server 128 runs the demo version without utilizing the property that was added or modified to the data model type to determine whether the demo version runs successfully. If no errors are detected, the migration generation server 128 allows the migration and modifies the version of the data model type stored on the CMS 107. If errors are detected, the migration generation server 128 will notify the user of the software development tool 103 of the errors to allow the user to correct the errors.
[0040] In this way, because various website generation data references the same data model types, the migration generation server 128 verifies that changes made to shared data model types do not produce errors in other website generation data that references the same data model types. For example, first website generation data can reference a first data model type (e.g., a button), and second website generation data also references the same first data model type. Both the first website generation data and the second website generation data can be stored in the same space on the CMS 107. A software developer or user can use the software development tool 103 to modify the first website generation data to add a new attribute to the first data model type. The first website generation data uses the new attribute in the code. The new attribute is not used by the second website generation data. Because the second website generation data references the same first data model type that does not have the new attribute, a verification is performed to ensure that the addition of the new attribute does not have adverse effects or produce errors when the second website generation data accesses the modified first data model type before the shared first data model type is modified. Thus, the migration generation server 128 verifies that a change made to a data model type is backward compatible with website generation data that does not use the modified attribute of the data model type and that references the same data model type in the CMS 107 before applying the change to the attributes of the data model type on the CMS 107.
[0041] In some implementations, when a software developer or user selects a revert operation in the software development tool 103, the migration generation server 128 reverts the change to a previous version of the data model type. The software development tool 103 periodically or continuously tracks changes made to website generation data. When a user selects a revert operation, a particular change to an attribute of a data model type (e.g., adding a new attribute) is undone (e.g., the newly added attribute is removed). In this way, the software development tool 103 allows a user to access previous versions of software code and data model types while writing code. The migration generation server 128 similarly detects such changes to data model types and applies or migrates such changes to the corresponding data model types stored on the CMS 107.
[0042] System Architecture
[0043] Figure 2is a block diagram illustrating further details regarding the messaging system 100, according to some examples. In particular, the messaging system 100 is shown to include the messaging client 104 and the application server 112. The messaging system 100 includes several subsystems that are supported on the client-side by the messaging client 104 and on the server-side by the application server 112. These subsystems include, for example, a ephemeral timer system 202, a collection management system 204, an augmentation system 206, a map system 208, and a game system 210.
[0044] The ephemeral timer system 202 is responsible for enforcing temporary or time-limited access to content by the messaging client 104 and the messaging server 114. The ephemeral timer system 202 includes several timers that selectively enable access (e.g., for presentation and display) of messages and associated content via the messaging client 104 based on a duration and display parameters associated with a message or collection of messages (e.g., a story). Additional details regarding the operation of the ephemeral timer system 202 are provided below.
[0045] The collection management system 204 is responsible for managing collections or sets of media (e.g., collections of text, images, video, and audio data). Collections of content (e.g., messages, including images, video, text, and audio) can be organized into “event galleries” or “event stories.” Such collections can be made available for a specified period of time (e.g., a duration of an event related to the content). For example, content related to a concert can be made available as a “story” for the duration of the concert. The collection management system 204 can also be responsible for publishing icons to the user interface of the messaging client 104 that provide notification of the existence of particular collections.
[0046] In addition, the collection management system 204 also includes a curation interface 212 that enables collection managers to manage and curate particular collections of content. For example, the curation interface 212 enables event organizers to curate collections of content related to a particular event (e.g., to remove inappropriate content or redundant messages). In addition, the collection management system 204 employs machine vision (or image recognition techniques) and content rules to automatically curate collections of content. In certain examples, users can be paid compensation for including user-generated content into a collection. In such cases, the collection management system 204 operates to automatically pay such users for the use of their content.
[0047] The augmentation system 206 provides various functionality that enables users to augment (e.g., annotate or otherwise modify or edit) media content associated with messages. For example, the augmentation system 206 provides functionality related to generating and publishing media overlays for messages processed by the messaging system 100. The augmentation system 206 operatively provides media overlays or augmentations (e.g., image filters) to the messaging client 104 based on a geographic location of the client device 102. In another example, the augmentation system 206 operatively supplies media overlays to the messaging client 104 based on other information such as social network information of a user of the client device 102. The media overlays can include audio and visual content as well as visual effects. Examples of audio and visual content include pictures, text, logos, animations, and sound effects. Examples of visual effects include color overlays. The audio and visual content or visual effects can be applied to a media content item (e.g., a photo) at the client device 102. For example, a media overlay can include text or an image that can be overlaid on a photo taken by the client device 102. In another example, a media overlay includes a location identification overlay (e.g., Venice Beach), a name of a real-time event, or a name of a business overlay (e.g., Beachside Café). In another example, the augmentation system 206 uses a geographic location of the client device 102 to identify a media overlay that includes a name of a business at the geographic location of the client device 102. The media overlay can include other indicia associated with the business. The media overlays can be stored in the database 120 and accessed by the database server 118.
[0048] In some examples, the augmentation system 206 provides a user-based publishing platform that enables users to select a geographic location on a map and upload content associated with the selected geographic location. The user can also specify circumstances under which the particular media overlay should be provided to other users. The augmentation system 206 generates a media overlay that includes the uploaded content and associates the uploaded content with the selected geographic location.
[0049] In other examples, the augmentation system 206 provides a business-based publishing platform that enables businesses to select particular media overlays associated with geographic locations via a bidding process. For example, the augmentation system 206 associates a media overlay of a highest bidding business with a respective geographic location for a predefined amount of time.
[0050] The map system 208 provides various geographic positioning functionality and supports the presentation of map-based media content and messages by the messaging client 104. For example, the map system 208 is capable of displaying user icons or avatars (e.g., stored in the profile data 308) on a map to indicate the current or past locations of a user's "friends," as well as media content (e.g., collections of messages including photos and videos) generated by those friends within the context of the map. For example, a message posted by a user from a particular geographic location to the messaging system 100 can be displayed to a particular user's "friends" within the context of that particular location on a map interface of the messaging client 104. A user can also share his or her location and status information with other users of the messaging system 100 (e.g., using an appropriate status avatar) via the messaging client 104, where the location and status information is displayed to the selected users within the context of a map interface of the messaging client 104.
[0051] The game system 210 provides various gaming functionality within the context of the messaging client 104. The messaging client 104 provides a game interface that provides a list of available games (e.g., web-based games or web-based applications) that can be launched by a user within the context of the messaging client 104 and played with other users of the messaging system 100. The messaging system 100 also enables a particular user to invite other users to participate in playing a particular game by issuing invitations from the messaging client 104 to such other users. The messaging client 104 also supports both voice and text communications (e.g., chats) within the context of playing games, provides a leaderboard for games, and also supports the provision of in-game rewards (e.g., coins and items).
[0052] Data Architecture
[0053] Figure 3 FIG. 3 is a schematic diagram illustrating a data structure 300 that can be stored in the databases 120 of the messaging server system 108, in accordance with certain examples. While the contents of the databases 120 are illustrated as including a number of tables, it will be appreciated that data can be stored in other types of data structures (e.g., as an object-oriented database).
[0054] The databases 120 include message data stored in a messages table 302. For any particular message, the message data includes at least message sender data, message recipient (or receiver) data, and a payload. The messages table 302 is described in more detail below with reference to FIG. 4. Figure 4 Additional details regarding information that can be included in a message and included in the message data stored in the messages table 302 are described below.
[0055] The entity table 304 stores entity data and is linked to (e.g., references) the entity graph 306 and the profile data 308. Entities recorded within the entity table 304 can include individuals, corporate entities, organizations, objects, places, events, etc. Regardless of the entity type, any entity for which the messaging server system 108 stores data can be an identified entity. A unique identifier is provided for each entity as well as an entity type identifier (not shown).
[0056] The entity graph 306 stores information about relationships and associations between entities. Such relationships can be social, professional (e.g., working at a common company or organization), interest-based, or activity-based, to name a few examples.
[0057] The profile data 308 stores various types of profile data about a particular entity. Based on privacy settings specified by the particular entity, the profile data 308 can be selectively used and presented to other users of the messaging system 100. In the case of an entity being a person, the profile data 308 includes, for example, a user name, a phone number, an address, settings (e.g., notification and privacy settings), and a user-selected avatar representation (or a collection of such avatar representations). The particular user can then selectively include one or more of these avatar representations in the content of messages communicated via the messaging system 100 as well as on the map interface displayed by the messaging client 104 to other users. The collection of avatar representations can include a "status avatar" that presents a graphical representation of a status or activity that the user can select to be in communication at a particular time.
[0058] In the case of an entity being a group, the profile data 308 for the group can similarly include one or more avatar representations associated with the group in addition to the group name, members, and various settings (e.g., notifications) for the related group.
[0059] The database 120 also stores augmentation data, such as overlays or filters, in an augmentation table 310. The augmentation data is associated with and applied to videos (data for which is stored in a video table 314) and images (data for which is stored in an image table 316).
[0060] In one example, the filter is a sticker that is displayed as an overlay on the image or video during presentation to the recipient user. The sticker can be of various types, including a sticker that is selected by the user from a set of stickers presented to the sender user by the messaging client 104 while the sender user is composing the message. Other types of stickers include a geolocation sticker (also referred to as a geosticker) that can be presented to the sender user based on geolocation. For example, a geolocation sticker that is specific to a nearby or specific location can be presented by the messaging client 104 within the user interface based on geolocation information determined by a global positioning system (GPS) unit of the client device 102
[0061] Another type of filter is a data filter that can be selectively presented to the sender user by the messaging client 104 based on other inputs or information collected by the client device 102 during the message creation process. Examples of data filters include a current temperature at a specific location, a current speed at which the sending user is traveling, a battery life of the client device 102, or a current time.
[0062] Other augmentation data that can be stored within the image table 316 includes augmented reality content items (e.g., corresponding to an application lens or augmented reality experience). The augmented reality content items can be real-time special effects and sounds that can be added to the image or video.
[0063] As described above, augmentation data includes augmented reality content items, overlays, image transformations, AR images, and similar items that refer to modifications that can be applied to image data (e.g., video or images). This includes real-time modifications, which modify images as they are captured using device sensors (e.g., one or more cameras) of the client device 102 and then display the modified images on the screen of the client device 102. This also includes modifications to stored content, such as modifications to video clips in a gallery that can be modified. For example, in a client device 102 that has access to multiple augmented reality content items, a user can use a single video clip with multiple augmented reality content items to see how different augmented reality content items would modify the stored clip. For example, by selecting different augmented reality content items for the content, multiple augmented reality content items that apply different pseudo-random motion models can be applied to that same content. Similarly, real-time video capture can be used with shown modifications to display how video images currently being captured by the sensors of the client device 102 would modify the captured data. Such data can simply be displayed on the screen without being stored in memory, or the content captured by the device sensors can be recorded and stored in memory with or without modifications (or both). In certain systems, a preview function can show different augmented reality content items at the same time in different windows of the display. For example, this can enable multiple windows with different pseudo-random animations to be viewed on the display at the same time.
[0064] Accordingly, systems that use augmented reality content items for data or other such transformation systems that modify content using the data can involve detection of objects (e.g., faces, hands, bodies, cats, dogs, surfaces, objects, etc.) in video frames, tracking of the objects as they move in and out of the field of view and around the field of view, and modification or transformation of the objects as they are tracked. In various implementations, different methods for implementing such changes can be used. Some examples can involve generating three-dimensional mesh models of one or more objects, and using transformations and animated textures of the models within the video to implement the transformations. In other examples, images or textures (which can be two-dimensional or three-dimensional) can be placed at tracked locations using tracking of points on the objects. In still further examples, neural network analysis of video frames can be used to place images, models, or textures in content (e.g., images or video frames). Accordingly, augmented reality content items refer both to images, models, and textures used to create transformations in content, and to additional modeling and analysis information needed to implement such transformations through object detection, tracking, and placement.
[0065] Real-time video processing can be performed with any kind of video data (e.g., video streams, video files, etc.) saved in the memory of any type of computerized system. For example, a user can load a video file and save it in the memory of a device, or can generate a video stream using a sensor of the device. Moreover, any object can be processed using computer animation models, such as the face of a person and parts of the human body, animals, or non-living things (e.g., chairs, cars, or other objects).
[0066] In some examples, when a particular modification is selected together with the content to be transformed, the elements of the object to be transformed are identified by the computing device and then detected and tracked if they exist in the frames of the video stream. The elements of the object are modified according to the modification request, thus transforming the frames of the video stream. The transformation of the frames of the video stream can be performed by different methods for different types of transformation. For example, for frame transformations that mainly refer to a change in the form of the elements of the object, feature points of each element of the object are calculated (e.g., using an Active Shape Model (ASM) or other known methods). Then, a mesh based on the feature points is generated for each of the at least one element of the object. The mesh is used to track the elements of the object in the subsequent stages. In the tracking process, the mentioned mesh for each element is aligned with the location of each element. Then, additional points are generated on the mesh. A first set of points is generated for each element based on the modification request, and a second set of points is generated for each element based on the first set of points and the request for modification. Then, the frames of the video stream can be transformed by modifying the elements of the object based on the first set of points and the second set of points and the mesh. In such a method, the background of the modified object can also be changed or distorted by tracking and modifying the background.
[0067] In some examples, the transformation of some areas of the object using the elements of the object can be performed by calculating feature points of each element of the object and generating a mesh based on the calculated feature points. Points are generated on the mesh, and then various areas based on the points are generated. Then, the elements of the object are tracked by aligning the areas of each element with the location of each of the at least one element, and the properties of the areas can be modified based on the modification request, thus transforming the frames of the video stream. According to the specific modification request, the properties of the mentioned areas can be transformed in different ways. Such modifications can involve: changing the color of the areas; removing at least some parts of the areas from the frames of the video stream; including one or more new objects in the areas based on the modification request; and modifying or distorting the areas or the elements of the object. In various implementations, any combination of such modifications or other similar modifications can be used. For certain models to be animated, some of the feature points can be selected as control points for determining the entire state space of options for the animation of the model.
[0068] In some examples of computer animation models that use face detection to transform image data, a particular face detection algorithm (e.g., Viola-Jones) is used to detect faces on an image. Then, an Active Shape Model (ASM) algorithm is applied to the face region of the image to detect facial feature landmarks.
[0069] In other examples, other methods and algorithms suitable for face detection can be used. For example, in some implementations, landmarks are used to locate features, which are distinguishable points that exist in most images under consideration. For example, for face landmarks, the position of the left eye pupil can be used. If the initial landmark is not identifiable (e.g., if a person has an eye patch), a secondary landmark can be used. Such a landmark identification process can be used for any such object. In some examples, a set of landmarks forms a shape. A shape can be represented as a vector using the coordinates of the points in the shape. One shape is aligned to another by a similarity transformation (allowing translation, scaling, and rotation) that minimizes the average Euclidean distance between the shape points. The average shape is the average of the aligned training shapes.
[0070] In some examples, a search for landmarks starts from an average shape that is aligned to the position and size of the face determined by a global face detector. Such a search then repeats the following steps until convergence occurs: the position of the shape points is adjusted by template matching of the image texture around each point to suggest a tentative shape, and then the tentative shape is brought into conformity with a global shape model. In some systems, individual template matching is unreliable, and the shape model pools the results of weak template matching to form a stronger overall classifier. The entire search is repeated at each level of an image pyramid, from coarse resolution to fine resolution.
[0071] The transformation system can capture images or video streams on a client device (e.g., client device 102) and perform complex image manipulations locally on the client device 102, while maintaining a proper user experience, computation time, and power consumption. Complex image manipulations can include size and shape changes, emotion transformations (e.g., changing a face from frowning to smiling), state transformations (e.g., aging a subject, reducing apparent age, changing gender), style transformations, application of graphical elements, and any other suitable image or video manipulations implemented by convolutional neural networks that have been configured to efficiently execute on the client device 102.
[0072] In some examples, a computer animation model for transforming image data can be used by a system in which a user can use a client device 102 having a neural network to capture an image or video stream of the user (e.g., a selfie) that operates as part of a messaging client 104 operating on the client device 102. A transform system operating within the messaging client 104 determines the presence of a face in the image or video stream and provides a modification icon associated with a computer animation model to transform the image data, or the computer animation model can be presented in association with an interface described herein. The modification icon includes a change that can be the basis for modifying the face of the user within the image or video stream as part of a modification operation. Once the modification icon is selected, the transform system initiates a process to convert the image of the user to reflect the selected modification icon (e.g., generate a smiling face on the user). Once the image or video stream is captured and the specified modification is selected, the modified image or video stream can be presented in a graphical user interface displayed on the client device 102. The transform system can implement a complex convolutional neural network on a portion of the image or video stream to generate and apply the selected modification. That is, once the modification icon is selected, the user can capture the image or video stream and present the modification results in real-time or near real-time. Further, the modification can be persistent while a video stream is being captured and the selected modification icon remains toggled. Machine-learned neural networks can be used to implement such modifications.
[0073] A graphical user interface presenting modifications performed by the transform system can provide additional interaction options for the user. Such options can be based on the interface used to initiate content capture and selection of a particular computer animation model (e.g., initiated from a content creator user interface). In various implementations, the modification can be persistent after an initial selection of the modification icon. The user can turn the modification on or off by tapping or otherwise selecting the face modified by the transform system and store it for later viewing or browsing to other areas of the imaging application. In cases where the transform system modifies multiple faces, the user can turn the modification on or off globally by tapping or selecting a single face modified and displayed within the graphical user interface. In some implementations, individual faces among a group of multiple faces can be modified individually, or such modifications can be toggled individually by tapping or selecting an individual face or series of individual faces displayed within the graphical user interface.
[0074] Story table 312 stores data regarding collections of messages and associated image, video, or audio data that are compiled into collections (e.g., stories or galleries). The creation of a particular collection can be initiated by a particular user (e.g., for each user for which a record is maintained in entity table 304). A user can create a "personal story" in the form of a collection of content that has been created and sent / broadcast by that user. To this end, the user interface of messaging client 104 can include a user-selectable icon to enable a sender user to add particular content to his or her personal story.
[0075] A collection can also constitute a "live story" that is a collection of content from multiple users that is created manually, automatically, or using a combination of manual and automatic techniques. For example, a "live story" can constitute a curated stream of user-submitted content from various locations and events. Users whose client devices are enabled for location services and are at a common location event at a particular time can be presented with an option to contribute content to a particular live story, e.g., via a user interface of messaging client 104. A live story can be identified to a user by messaging client 104 based on the user's location. The end result is a "live story" told from a group perspective.
[0076] Another type of collection of content is referred to as a "location story," which enables users whose client devices 102 are located within a particular geolocation (e.g., at a college or university campus) to contribute to a particular collection. In some examples, contribution to a location story can require secondary authentication to verify that an end user belongs to a particular organization or other entity (e.g., is a student in a university campus).
[0077] As mentioned above, video table 314 stores video data that, in one example, is associated with messages whose records are stored within message table 302. Similarly, image table 316 stores image data that is associated with messages whose message data is stored in entity table 304. Entity table 304 can associate various augmentations from augmentation table 310 with various images and videos stored in image table 316 and video table 314.
[0078] Data Communication Architecture
[0079] Figure 4is a schematic diagram showing the structure of a message 400 generated by a message client 104 for transmission to another message client 104 or message server 114, according to some examples. The content of a particular message 400 is used to populate a message table 302 stored in a database 120, which is accessible by a messaging server 114. Similarly, the content of a message 400 is stored in memory as “in-transit” or “in-flight” data by a client device 102 or application server 112. The message 400 is shown to include the following example components:
[0080] • message identifier 402: a unique identifier that identifies the message 400.
[0081] • message text payload 404: text to be generated by a user via a user interface of a client device 102 and included in the message 400.
[0082] • message image payload 406: image data captured by a camera component of the client device 102 or retrieved from a memory component of the client device 102 and included in the message 400. Image data for a message 400 sent or received can be stored in an image table 316.
[0083] • message video payload 408: video data captured by a camera component or retrieved from a memory component of the client device 102 and included in the message 400. Video data for a message 400 sent or received can be stored in a video table 314.
[0084] • message audio payload 410: audio data captured by a microphone or retrieved from a memory component of the client device 102 and included in the message 400.
[0085] • message augmentation data 412: augmentation data (e.g., filters, stickers, or other annotations or augmentations) representing an augmentation to be applied to the message image payload 406, message video payload 408, or message audio payload 410 of the message 400. Augmentation data for a message 400 sent or received can be stored in an augmentation table 310.
[0086] • message duration parameter 414: a parameter value indicating an amount of time in seconds that the content of the message (e.g., message image payload 406, message video payload 408, message audio payload 410) will be presented to or made accessible to a user via the message client 104.
[0087] • Message geolocation parameters 416: Geolocation data (e.g., latitude and longitude coordinates) associated with the content payload of the message. Multiple message geolocation parameter 416 values can be included in the payload, with each of the parameter values associated with a content item included in the content (e.g., a particular image within the message image payload 406, or a particular video in the message video payload 408).
[0088] • Message story identifiers 418: Identifier values that identify one or more content collections (e.g.,“stories” identified in the story table 312) with which a particular content item in the message image payload 406 of the message 400 is associated. For example, multiple images within the message image payload 406 can each be associated with multiple content collections using identifier values.
[0089] • Message tags 420: Each message 400 can be tagged with multiple tags, each of which indicates a subject of content included in the message payload. For example, where a particular image included in the message image payload 406 depicts an animal (e.g., a lion), a tag value indicating the relevant animal can be included in the message tags 420. Tag values can be generated manually based on user input, or can be generated automatically using, for example, image recognition.
[0090] • Message sender identifier 422: An identifier (e.g., a messaging system identifier, email address, or device identifier) that indicates the user of the client device 102 on which the message 400 was generated and from which the message 400 was sent.
[0091] • Message recipient identifier 424: An identifier (e.g., a messaging system identifier, email address, or device identifier) that indicates the user of the client device 102 to which the message 400 is addressed.
[0092] The content (e.g., values) of the various components of the message 400 can be pointers to locations in tables within which the content data values are stored. For example, an image value in the message image payload 406 can be a pointer to (or the address of) a location within the image table 316. Similarly, values within the message video payload 408 can point to data stored within the video table 314, values stored in the message augmentation data 412 can point to data stored in the annotation table 310, values stored in the message story identifiers 418 can point to data stored in the story table 312, and values stored in the message sender identifier 422 and the message recipient identifier 424 can point to user records stored in the entity table 304.
[0093] Website generation system
[0094] Figure 5 is a diagrammatic representation of a website generation system 500 according to some examples. The software development tool 520 can be the same as the software development tool 103 implemented on the client device 102. The software development tool 520 (or a migration agent in communication with the software development tool 520) uses the API of the first CMS 510 to obtain a local version of the data model types stored and provided by the first CMS 510. The software development tool 520 also obtains website generation data from a particular space on the first CMS 510. The software development tool 520 stores the local version of the data model types 527 along with the obtained website generation data. In some cases, the software development tool 520 (or the migration agent) only retrieves from the first CMS 510 the data model types referenced and used by the obtained website generation data. In such cases, the software development tool 520 obtains the website generation data and parses through the website generation data to identify a list of data model types used and referenced by the website generation data. The software development tool 520 then uses the API of the first CMS 510 to obtain the code corresponding to the list of data model types used and referenced by the website generation data. Any of the functionality discussed with respect to the software development tool 103 or 520 for migrating data model types from the software development tool to the CMS 510 can alternatively or additionally be performed by a migration agent that is part of the software development tool 103 or 520 or separate from the software development tool 103 or 520.
[0095] The software developer can access the website generation data using the software development tool 520 and make modifications to the website generation data to create a website using the software development tool 520. In some cases, the software developer can make modifications to the website generation data to create a new version of the website. In some cases, the software developer can make modifications to the website generation data to create a new version of the website that is different from the website generated by the first CMS 510. Figure 6 An illustrative screenshot 610 of a graphical user interface provided by the software development tool 520 is provided in FIG. 6. The software development tool 520 includes various tools and options for authoring website generation data or code. Such tools include color coding different segments of the website generation data that include segments corresponding to data model types referenced and stored by the first CMS 510. Such tools also include an undo operation that allows the software developer to undo a restricted set or unrestricted set of changes to revert to a previous version of the code.
[0096] In some implementations, a software developer can change a given data model type. The software developer can access a local data model type stored on the client device 102 and can add, change, or remove properties from the particular local data model type that is accessed. The data model type migration agent 524 continuously or periodically monitors and detects changes to data model types stored in the local data model types 527. As an example, the data model type migration agent 524 continuously or periodically compares the data model types stored in the local data model types 527 to the corresponding data model types stored in the first CMS 510. In response to detecting a change or difference between the data model types, the data model type migration agent 524 generates a script using the API of the first CMS 510 to apply such changes to or migrate to the data model types stored on the first CMS 510. In this way, when the software development tool submits changes and uploads updated website generation data to the first CMS 510, the data model types with changes referenced by the updated website generation data are already available and stored on the first CMS 510.
[0097] In some implementations, the data model type migration agent 524 runs or generates a demo version referencing the updated data model type before applying the changes to the corresponding data model type stored on the first CMS 510. The demo version verifies that the changes made to the data model type are backward compatible with other website generation data that does not use the modified properties of the data model type. If such changes do not produce errors, the data model type migration agent 524 updates the corresponding data model type stored on the first CMS 510 using the API of the first CMS 510. If errors are identified in the demo version, the data model type migration agent 524 displays the errors to the user of the software development tool and does not use the changes made to the local corresponding data model type to update the data model type stored in the first CMS 510.
[0098] In some embodiments, a software developer or user can desire to store and apply the modified website generation data on a second CMS 530. The second CMS 530 can include a different set of data model types than the first CMS 520. The second CMS 530 can include a common set of data model types as the first CMS 520, but some of the data model types can include different attributes between the first CMS 520 and the second CMS 530. The data model type migration agent 524 receives instructions to store the website generation data obtained from the first CMS 510 to the second CMS 530. In response, the data model type migration agent 524 uses the API of the second CMS 530 to obtain or import a list of data model types available and used from the second CMS 530. The data model type migration agent 524 can use a mapping to identify a correspondence between a given data model type of the first CMS 510 referenced by the website generation data and an identical given data model type of the second CMS 530. Once the data model type correspondence is determined, the data model type migration agent 524 detects differences between the locally versioned data model types 527 and the data model types imported or obtained from the second CMS 530. The data model type migration agent 524 generates scripts based on the locally versioned data model types 527 to update or change the data model types stored on the second CMS 530. The data model type migration agent 524 uses a demo version to ensure that such changes are backward compatible before committing the changes to the data model types stored on the second CMS 530. After successfully executing the demo version without errors, the data model type migration agent 524 automatically updates the data model types stored on the second CMS 530 and stores the website generation data to the second CMS 530. Although the data model type migration agent 524 is shown as included in the software development tool 520, the data model type migration agent 524 can be implemented as a separate application that communicates constantly or periodically with the software development tool 520.
[0099] In some embodiments, the first CMS 510 stages production of website generation data. For example, the first CMS 510 can store website generation data in two places and have two versions, a pre-production stage and a production stage. The first stage can not be published or accessible until the first stage is transitioned to the next production stage. Website generation data in the production stage is presented to users accessing the website generation data. In this way, changes to website generation data in the first pre-production stage can be made continuously without being immediately presented to users. Once the changes are acceptable and ready for production, the pre-production stage version of the website generation data is used to replace the production stage version of the website generation data. This allows changes to be rolled back seamlessly and without interrupting the website to users.
[0100] Figure 7 is a graphical representation of website data model type migration according to some examples. For example, CMS data model type 710 is stored on CMS 107. CMS data model type 710 includes a plurality of properties and a plurality of tags. Such properties define the look and feel (behavior) of a data model type such as a button. For example, as shown in Figure 8 webpage 800 is shown accessed at address 810. This webpage is generated for display based on website generation data that references CMS data model type 710. As shown, the look and feel of button 830 corresponding to CMS data model type 710 has a first set of properties that does not include a color for button 830.
[0101] CMS data model type 710 is imported by software development tool 103 (migration agent) and stored as a local version. A user of software development tool 103 or software developer makes changes to the local version of the data model type and such changes are recorded and tracked by local data model type changes 720. For example, the user added a color property to locally stored CMS data model type 710. These changes are provided to data model type migration script 730. Data model type migration script 730 compares the changes received from local data model type changes 720 to CMS data model type 710 stored on CMS 107. In response to detecting a difference, data model type migration script 730 uses an API of CMS 107 to apply (migrate) these changes to CMS data model type 710 stored on CMS 107.
[0102] As an example, the identified change is the addition of a new property to the CMS data model type 710. After applying or migrating these changes, the CMS data model type 740 stored on the CMS 107 is modified to include the new property 742. This updated CMS data model type 740 can be used and referenced by other site generation data on the CMS 107. For example, as shown in Figure 9 the web page 900 accessed at address 910 is shown. The web page is generated for display based on the site generation data referencing the CMS data model type 740 with the new property 742 (e.g., the color of the button is added). As shown, the appearance and feel of the button 920 corresponding to the CMS data model type 740 has a second set of properties that includes the color of the button 920 that is different from the button 830 Figure 8 ).
[0103] Figure 10 is a flowchart showing example operations of a site generation system in performing the process 1000 according to an example implementation. The process 1000 can be embodied in computer-readable instructions for execution by one or more processors, such that the operations of the process 1000 can be performed, in part or in whole, by the functional components of the software development tool 103; thus, the process 1000 is described below by way of example with reference thereto. However, in other implementations, at least some of the operations of the process 1000 can be deployed on various other hardware configurations, such as on the application server 112. The operations in the process 1000 can be performed in any order, in parallel, or can be skipped and omitted altogether.
[0104] At operation 1001, the client device 102 retrieves site generation data from the CMS that references data model types stored on the CMS. For example, the software development tool 103 accesses the CMS 107 to retrieve site generation data, such as data stored in a pre-production stage. For example, the site generation data can include hypertext markup language with various elements (data model types) such as <audio>, <button>, <title>, <code>, etc.
[0105] At operation 1002, the client device 102 imports definitions of data model types referenced by the site generation data as local versions of the data model types by a migration agent that communicates with the software development tool from the CMS. For example, the data model type migration agent 524 uses the API of the CMS 107 to obtain all data model types available from the CMS 107 or a subset used and referenced by the retrieved site generation data. Specifically, for the <button> data model type, the definition specifies properties (attributes) (e.g., autofocus, form, form action, form target, name, type, etc.) and labels (specific names and non-behavioral elements).
[0106] At operation 1003, the client device 102 detects changes to the properties of the local version of the data model type. For example, the migration generation server 128, the data model type migration agent 524, or the software development tool 103 compares the obtained local version of the data model type to the version stored on the CMS 107 to detect any differences to the properties (as opposed to the tags) of the data model type. Specifically, for the <button> data model type, the CMS definition does not include a color property or attribute, and the software development tool 103 version adds the color property or attribute to the <button> data model type. The migration generation server 128 is configured to ignore or disregard any hypertext markup language segments that are given as tags for a given data model type.
[0107] At operation 1004, the client device 102 (data model type migration agent 524) generates a migration script to migrate the changes to the properties of the local version of the data model type to the data model type stored on the CMS. For example, the data model type migration agent 524 generates a script based on the differences or changes to the properties of the local version of the data model type stored on the client device 102 to migrate or modify the version of the data model type stored on the CMS 107. In some cases, such changes are only migrated without error after a successful demonstration version of the changes is run. Specifically, the migration generation server 128 uses the API of the CMS to call certain functions for modifying the properties or attributes of the data model type. Using the specific functions of the API, the migration generation server 128 automatically generates the code necessary to modify the properties of the data model type that have been changed locally.
[0108] Machine architecture
[0109] Figure 11is a diagrammatic representation of the machine 1100 within which instructions 1108 (e.g., software, a program, an application, an applet, an app, or other executable code) for causing the machine 1100 to perform any one or more of the methodologies discussed herein can be executed. For example, the instructions 1108 can cause the machine 1100 to execute any one or more of the methods described herein. The instructions 1108 transform the general, non-programmed machine 1100 into a particular machine 1100 programmed to carry out the described and illustrated functions in the manner described. The machine 1100 can operate as a standalone device or can be coupled (e.g., networked) to other machines. In a networked deployment, the machine 1100 can operate in the capacity of a server machine or a client machine in server-client network environments, or as a peer machine in peer-to-peer (or distributed) network environments. The machine 1100 can comprise, but not be limited to, a server computer, a client computer, a personal computer (PC), a tablet computer, a laptop computer, a netbook, a set-top box (STB), a personal digital assistant (PDA), an entertainment media system, a cellular telephone, a smart phone, a mobile device, a wearable device (e.g., a smart watch), a smart home device (e.g., a smart appliance), other smart devices, a web appliance, a network router, a network switch, a network bridge, or any machine capable of executing the instructions 1108, sequentially or otherwise, that specify actions to be taken by machine 1100. Further, while only a single machine 1100 is illustrated, the term “machine” shall also be taken to include a collection of machines that individually or jointly execute the instructions 1108 to perform any one or more of the methodologies discussed herein. For example, the machine 1100 can include the client device 102 or any one of a number of server devices forming a part of the messaging server system 108. In some examples, the machine 1100 can further include both the client and server systems, where certain operations of a particular method or algorithm are performed on the server side and certain operations of the particular method or algorithm are performed on the client side.
[0110] The machine 1100 can include processors 1102, memory 1104, and input / output (I / O) components 1138, which can be configured to communicate with each other via a bus 1140. In an example, the processors 1102 (e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a radio-frequency integrated circuit (RFIC), another processor, or combinations of any of these processors) can include, for example, a processor 1106 and a processor 1110 that execute instructions 1108. The term “processor” is intended to encompass a multi-core processor that can include two or more independent processors (sometimes referred to as “cores”) that can execute instructions contemporaneously. Although FIG. 1 illustrates a single bus 1140, the bus 1140 can be interlinked with other busses in a network topologies and the like. The memory 1104 can include a main memory 1112, a static memory 1114, and a storage unit 1116, which can be accessed by the processors 1102 via the bus 1140. The main memory 1112, the static memory 1114, and the storage unit 1116 store the instructions 1108 embodying any one or more of the methodologies or functions described herein. The instructions 1108 can also reside, completely or Figure 11 Although illustrated with multiple processors 1102, the machine 1100 can include a single processor with a single core, a single processor with multiple cores (e.g., a multi-core processor), multiple processors with a single core, multiple processors with multiple cores, or any combination thereof.
[0111] The memory 1104 includes a main memory 1112, a static memory 1114, and a storage unit 1116, which can be accessed by the processors 1102 via the bus 1140. The main memory 1112, the static memory 1114, and the storage unit 1116 store the instructions 1108 embodying any one or more of the methodologies or functions described herein. The instructions 1108 can also reside, completely or
[0112] The I / O components 1138 can include a wide variety of components to receive input, provide output, produce output, transmit information, exchange information, capture measurements, and so on. The specific I / O components 1138 that are included in the machine 1100 will depend on the type and Figure 11Many other components not shown in FIG. 11 can also be included. In various examples, the I / O components 1138 can include user output components 1124 and user input components 1126. The user output components 1124 can include visual components (e.g., a display such as a plasma display panel (PDP), a light-emitting diode (LED) display, a liquid crystal display (LCD), a projector, or a cathode ray tube (CRT)), acoustic components (e.g., speakers), haptic components (e.g., a vibratory motor, resistance mechanisms), other signal generators, and so forth. The user input components 1126 can include alphanumeric input components (e.g., a keyboard, a touch screen configured to receive alphanumeric input, a photo-optical keyboard, or other alphanumeric input components), point-based input components (e.g., a mouse, a touchpad, a trackball, a joystick, a motion sensor, or another pointing instrument), tactile input components (e.g., a physical button, a touch screen that provides location and force of touches or touch gestures, or other tactile input components), audio input components (e.g., a microphone), and the like.
[0113] In further examples, the I / O components 1138 can include biometric components 1128, motion components 1130, environmental components 1132, or position components 1134, among a myriad of other components. For example, the biometric components 1128 include components to detect expressions (e.g., hand expressions, facial expressions, vocal expressions, body gestures, or eye tracking), measure biosignals (e.g., blood pressure, heart rate, body temperature, perspiration, or brain waves), identify a person (e.g., voice identification, retinal identification, facial identification, fingerprint identification, or electroencephalogram-based identification), and the like.
[0114] The environmental components 1132 can include, for example, one or more cameras (with still and / or video capabilities), illumination sensors (e.g., photometers), temperature sensors (e.g., one or more thermometers that detect ambient temperature), humidity sensors, pressure sensors (e.g., barometers), acoustic sensors (e.g., one or more microphones that detect background noise), proximity sensors (e.g., infrared sensors that detect nearby objects), gas sensors (e.g., gas detection sensors to detect concentrations of hazardous gases for safety or to measure pollutants in the atmosphere), or other components that can provide indications, measurements, or signals corresponding to a physical environment.
[0115] With respect to cameras, the client device 102 can have a camera system that includes, for example, a front-facing camera on a front surface of the client device 102 and a rear-facing camera on a rear surface of the client device 102. The front-facing camera can be used, for example, to capture still and video images of a user of the client device 102 (e.g., a “selfie”), which can then be enhanced with the above-described enhancement data (e.g., filters). The rear-facing camera can be used, for example, to capture still and video images in a more traditional camera mode, which are similarly enhanced using the enhancement data. In addition to front- and rear-facing cameras, the client device 102 can also include a 360° camera for capturing 360° photos and videos.
[0116] In addition, the camera system of the client device 102 can include dual rear-facing cameras (e.g., a primary camera and a depth-sensing camera), or even a triple, quadruple, or penta-configuration of rear-facing cameras on the front and rear sides of the client device 102. These multi-camera systems can include, for example, a wide-angle camera, an ultra-wide-angle camera, a telephoto camera, a macro camera, and a depth sensor.
[0117] The position component 1134 can include location sensor components (e.g., a GPS receiver component), altitude sensor components (e.g., altimeters or barometers that detect atmospheric pressure from which altitude can be derived), orientation sensor components (e.g., magnetometers), and the like.
[0118] Communication can be implemented using a wide variety of technologies. The I / O component 1138 also includes a communication component 1136 that can be operable to couple the machine 1100, via the respective coupling or connection, to a network 1120 or to another device 1122. For example, the communication component 1136 can include a network interface component or another suitable device to interface with the network 1120. In further examples, the communication component 1136 can include a wired communication component, a wireless communication component, a cellular communication component, a Near Field Communication (NFC) component, Components (e.g., Low Energy), Bluetooth® component, a Wi-Fi® component, a WiMAX® component, a
[0119] Moreover, the communication components 1136 can detect identifiers or include components operable to detect identifiers. For example, the communication components 1136 can include radio frequency identification (RFID) tag reader components, NFC smart tag detection components, optical reader components (e.g., an optical sensor to detect one-dimensional bar codes such as Universal Product Code (UPC) bar codes, multi-dimensional bar codes such as Quick Response (QR) codes, Aztec codes, Data Matrix, Dataglyph, MaxiCode, PDF417, Ultra Code, UCC RSS-2D bar codes, and other optical codes), or acoustic detection components (e.g., microphones to identify tagged audio signals). In addition, a variety of information can be derived via the communication components 1136, such as location via Internet Protocol (IP) geolocation, location via Wi-Fi® signal triangulation, location via cellular signal triangulation, location via the detection of NFC beacon signals that can indicate a particular location, and so forth.
[0120] The various memories (e.g., main memory 1112, static memory 1114, and memory shared with the processor 1102) and memory unit 1116 can store one or more sets of instructions and data structures (e.g., software) embodied in either computer-readable storage media or machine-readable storage media. These instructions (e.g., instructions 1108), when executed by the processor 1102, cause the various operations to implement the disclosed examples.
[0121] The instructions 1108 can be transmitted or received over the network 1120 via the network interface device (e.g., a network interface component included in the communication components 1136) using a transmission medium and any one of a number of well-known transfer protocols (e.g., hypertext transfer protocol (HTTP)). Similarly, in
[0122] Software Architecture
[0123] Figure 12is a block diagram 1200 illustrating software architecture 1204, which can be installed on any one or more of the devices described herein. The software architecture 1204 is supported by hardware such as machine 1202 that includes processors 1220, memory 1226, and I / O components 1238. In this example, the software architecture 1204 can be conceptualized as a stack of layers, where each layer provides particular functionality. The software architecture 1204 includes, for example, layers such as an operating system 1212, libraries 1210, frameworks 1208, and applications 1206. Operationally, the applications 1206 are
[0124] The operating system 1212 manages hardware resources and provides common services. The operating system 1212 includes, for example, a kernel 1214, services 1216, and drivers 1222. The kernel 1214 acts as an abstraction layer between the hardware and the other software layers. For example, the kernel 1214 provides memory management, processor management (for example, scheduling), component management, networking, and security settings, among other functionality. The services 1216 can provide other common services for the other software layers. The drivers 1222 are responsible for controlling or interfacing with the underlying hardware. For instance, the drivers 1222 can include display drivers, camera drivers, Bluetooth® drivers, flash or memory drivers, serial communication drivers (for example, USB drivers), WI-FI® drivers, etc. The frameworks 1208 provide a common high-level
[0125] The libraries 1210 provide a common low-level infrastructure used by the applications 1206. The libraries 1210 can include system libraries 1218 (e.g., C standard library) providing functions such as memory allocation functions, string manipulation functions, mathematic functions, and the like. In addition, the libraries 1210 can include API libraries 1224, such as media libraries (e.g., libraries to support presentation and manipulation of various media formats such as Moving Picture Experts Group-4 (MPEG4), Advanced Video Coding (H.264 or AVC), Moving Picture Experts Group Layer-3 (MP3), Advanced Audio Coding (AAC), Adaptive Multi-Rate (AMR) audio codec, Joint Photographic Experts Group (JPEG or JPG), or Portable Network Graphics (PNG)), graphics libraries (e.g., an OpenGL framework used to render two and three dimensional graphics on a display), database libraries (e.g., SQLite to provide various relational database functions), web libraries (e.g., WebKit to provide web browsing functionality), and the like. The libraries 1210 can also include a wide variety of other libraries 1228 to provide many other APIs to the applications 1206.
[0126] The frameworks 1208 provide a common high-level infrastructure used by the applications 1206. For example, the frameworks 1208 provide various graphical user interface (GUI) functions, high-level resource management, and high-level positioning
[0127] In an example, the applications 1206 can include a home application 1236, a contacts application 1230, a browser application 1232, a book reader application 1234, a location application 1242, a media application 1244, a messaging application 1246, a game application 1248, and a broad assortment of other applications such as a third-party application 1240. The applications 1206 are programs that execute functions defined in the programs. One or more of the applications 1206 can be created using a variety of programming languages such as object-oriented programming languages (e.g., Objective-C, Java, or C++) or procedural programming languages (e.g., C or assembly language). In a specific example, the third-party application 1240 (e.g., an application developed by an entity other than the vendor of the particular platform) can be mobile software running on the platform such as a mobile operating system such as the IOS TM operating system (IOS TM ) or the ANDROID TM operating system (ANDROID TM ). or other mobile operating systems. In this example, the third-party application 1240 can activate the API call 1250 provided by the operating system 1212 to facilitate the functionality described herein.
[0128] Glossary
[0129] “Carrier signal” means any intangible medium that is capable of storing, encoding, or carrying the instructions for execution by a machine and includes digital or analog communications signals or other intangible media to facilitate communication of such instructions. Instructions can be transmitted or received by one or more network interface devices via the network.
[0130] “Client device” means any machine that interfaces to a communications network to access resources from a server or other client device. A client device can be, but is not limited to, a mobile phone, desktop computer, laptop computer, portable digital assistants (PDAs), smart phones, tablets, ultrabooks, netbooks, laptops, multi-processor systems, microprocessor-based or programmable consumer electronics, game consoles, set-top boxes, or any other communication device that a user can use to access a network.
[0131] “Communication network” means one or more portions of a network that can be an ad hoc network, intranet, extranet, virtual private network (VPN), local area network (LAN), wireless LAN (WLAN), wide area network (WAN), wireless WAN (WWAN), metropolitan area network (MAN), the Internet, a portion of the Internet, a portion of the Public Switched Telephone Network (PSTN), a plain old telephone service (POTS) network, a cellular telephone network, a wireless network, a Wi-Fi® network, another type of network, or a combination of two or more such networks. For example, a network or a portion of a network can include a wireless or cellular network, and a coupling can be a Code Division Multiple Access (CDMA) connection, a Global System for Mobile communications, or other type of cellular or wireless coupling. In this example, the coupling can enable any of a variety of types of data transfer technology, such as Single Carrier Radio Transmission Technology (lxRTT), Evolution-Data Optimized (EVDO) technology, General Packet Radio Service (GPRS) technology, Enhanced Data rates for GSM Evolution (EDGE) technology, third Generation Partnership Project (3GPP) including 3G, fourth generation wireless (4G) networks, Universal Mobile Telecommunications System (UMTS), High Speed Packet Access (HSPA), Worldwide Interoperability for Microwave Access (WiMAX), Long Term Evolution (LTE) standards, others defined by various standards setting organizations, other long range protocols, or other data transfer technology.
[0132] A“component” refers to a device, physical entity, or logic having boundaries defined by a function or a routine, a branch point, APIs, or other techniques for providing
[0133] A component can constitute either software components (e.g., code embodied on a machine-readable medium) or hardware components. A“hardware component” is a tangible unit capable of performing certain operations and can be configured or arranged in a certain physical manner. In various example embodiments, one or more computer systems (e.g., a standalone computer system, a client computer system, or a server computer system) or one or more hardware components of a computer system (e.g., a processor or a group of processors) can be configured by software (e.g., an application or application portion) as a hardware component that operates to perform certain operations as described herein.
[0134] A hardware component can also implement transformations by
[0135] Without loss of generality, the functionality of the various hardware components can be provided as software instructions scheduled to be executed by a general purpose computer (e.g., a central processing unit of the computer). In such embodiments, the computer can be programmed to function as the various hardware components described herein. In other embodiments, the functionality of the various hardware components can be provided by hardware only instructions (e.g., in a hardware-only state machine).
[0136] The hardware components can provide information to, and receive information from, other hardware components. Accordingly, the described hardware components can be considered to be communicatively coupled. Where multiple hardware components exist contemporaneously, communications can be achieved through signal transmission (e.g., over appropriate circuits and buses) between or among two or more of the hardware components. In embodiments in which multiple hardware components are configured or instantiated at different times, communications between such hardware components can be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple hardware components have access. For example, one hardware component can perform an operation and store the output of that operation in a memory device to which it is communicatively coupled. A further hardware component can then, at a later time, access the memory device to retrieve and process the stored output. The hardware components can also initiate communications with input or output devices, and can operate on a resource (e.g., a collection of information).
[0137] The various operations of example methods described herein can be performed, at least partially, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors can constitute processor-implemented components that conduct operations described herein. As used herein, “processor-implemented component” refers to a hardware component implemented with one or more processors. Similarly, the methods described herein can be at least partially processor-implemented, with a particular processor or processors being an example of hardware. For example, at least some of the operations of a method can be performed by one or more processors or processor-implemented components. Moreover, a processor or processors can also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” (SaaS). For example, at least some of the operations can be performed by a group of computers (as examples of machines comprising processors), with these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., an API). The performance of certain of the operations can be distributed among the processors, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the processors or processor-implemented components can be located in a single geographic location (e.g., within a home environment, an office environment, or a server farm). In other example embodiments, the processors or processor-implemented components can be distributed across a number of geographic locations.
[0138] “Computer-readable storage medium” refers to both machine-storage media and transmission media. Thus, the terms “machine-readable medium,” “computer-readable medium,” and “device-readable medium” mean the same thing and can be used interchangeably in this disclosure.
[0139] “Ephemeral message” refers to a message that is accessible for a limited duration of time. An email message can be text, images, video, etc. The access time for an ephemeral message can be set by the message sender. Alternatively, the access time can be a default setting or a setting specified by the recipient. Regardless of the setting technique, the message is temporary.
[0140] “machine-storage medium” refers to a single or multiple storage devices and media (e.g., a centralized or distributed database, and associated caches and servers) that store executable instructions, routines, and data. Thus, the term should be understood to include, but not be limited to, solid-state memories, and optical and magnetic media, including memory internal or external to processors. Specific examples of machine-storage media, computer-storage media, and / or device-storage media include non-volatile memory, including by way of example semiconductor memory devices, e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), FPGA, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The terms “machine-storage medium,” “device-storage medium,” “computer-storage medium,” and “device-storage medium” mean the same thing and can be used interchangeably in this disclosure. The terms “machine-storage medium,” “computer-storage medium,” and “device-storage medium” specifically exclude carrier waves, modulated data signals, and other such media, at least some of which are covered under the term “signal medium.”
[0141] “non-transitory computer-readable storage medium” refers to a tangible medium that is capable of storing, encoding, or carrying the instructions for execution by a machine.
[0142] “signal medium” refers to any intangible medium that is capable of storing, encoding, or carrying the instructions for execution by a machine and includes digital or analog communications signals or other intangible media to facilitate communication of software or data. The term “signal medium” shall be taken to include any form of a modulated data signal, carrier wave, and so on. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. The terms “transmission medium” and “signal medium” mean the same thing and can be used interchangeably in this disclosure.
[0143] Changes and modifications can be made to the disclosed embodiments without departing from the scope of the present disclosure. These and other changes or modifications are intended to be included within the scope of the present disclosure, as expressed in the appended claims.
Claims
1. A method for website generation and presentation, comprising: retrieving, by one or more processors, first website generation data from a content management system (CMS) that references a shared data model type stored on the CMS, the shared data model type also referenced by second website generation data; importing, by a migration agent in communication with a software development tool, a definition of the shared data model type referenced by the first website generation data from the CMS as a local version of the shared data model type; detecting, by the migration agent, a change to a property of the local version of the shared data model type; generating, by the migration agent, a migration script to migrate the change to the property of the local version of the shared data model type to the shared data model type stored on the CMS and modify the shared data model type; and verifying, prior to implementing the modification to the shared data model type to reflect the change to the property of the local version of the shared data model type, that the second website generation data runs without error when the second website generation data accesses the modified shared data model type. the shared data model type comprises object source code, and wherein the migration agent continuously or periodically monitors the change to the property of the local version of the shared data model type.
2. The method of claim 1, wherein, the software development tool enables a user to undo the change to the shared data model type.
3. The method of claim 1 or 2, wherein, the shared data model type stored on the CMS is shared by a plurality of websites.
4. The method of claim 1 or 2, wherein, 5. The method of claim 1 or 2, further comprising: applying, by the CMS, the migration script to a demo version of the shared data model type that includes the change to the property; verifying, by the CMS, whether the demo version is backward compatible with other website generation data; and in response to verifying that the demo version is backward compatible, modifying the shared data model type to include the change to the property.
6. The method of claim 5, further comprising: in response to verifying that the demo version is not backward compatible, notifying a user of the software development tool that the change to the property is not backward compatible; and preventing the shared data model type stored on the CMS from being updated with the change to the property.
7. The method of claim 1 or 2, further comprising: after updating the shared data model type stored on the CMS with a second change to a second property, receiving a request through the software development tool to undo the second change to the second property of the shared data model type; modifying the local version of the shared data model type to undo the second change to the second property; and generating, by the migration agent, another migration script to migrate the modification of the local version of the shared data model type in which the second change is undone to the shared data model type stored on the CMS. the migration script uses application programming interface functionality of the CMS to modify the shared data model type stored on the CMS. 8. The method of claim 1 or 2, wherein, 9. The method of claim 1 or 2, further comprising: querying, by the migration agent, the CMS to obtain a plurality of shared data model types stored on the CMS; identifying, from the plurality of shared data model types obtained from the CMS, a given shared data model type corresponding to a shared data model type referenced by the first website-generated data; and comparing the shared data model type referenced by the first website-generated data to the given shared data model type to detect a change in attributes of the local version of the shared data model type.
10. The method of claim 1 or 2, wherein, the CMS is a first CMS, the method further comprising: querying, by the migration agent, a second CMS to obtain a plurality of shared data model types stored on the second CMS, the shared data model types stored on the second CMS being different from the shared data model types stored on the first CMS; identifying, from the plurality of shared data model types obtained from the second CMS, a given shared data model type corresponding to a shared data model type referenced by the first website-generated data obtained from the first CMS; comparing the shared data model type referenced by the first website-generated data to the given shared data model type to detect a difference; and generating, by the migration agent, a second migration script to migrate the difference to the given shared data model type stored on the second CMS.
11. The method of claim 10, wherein, identifying the given shared data model type comprises storing a mapping between shared data model types of the first CMS and shared data model types of the second CMS.
12. The method of claim 1 or 2, further comprising: deploying the shared data model types stored on the CMS in phases with the change such that in a first phase shared data model types without the change are stored and in a second phase shared data model types with the change are stored.
13. The method of claim 12, wherein, in the first phase of deployment, using shared data model types without the change to provide a website corresponding to the first website-generated data, and after moving the shared data model types from the second phase to the first phase, using shared data model types with the change to provide a website corresponding to the first website-generated data.
14. The method of claim 1 or 2, wherein, the shared data model types include a first set of attributes, and wherein the change in attributes of the local version of the shared data model type comprises adding a new attribute to the first set of attributes.
15. The method of claim 14, wherein, the shared data model types include a button, and wherein the new attribute comprises a visual graphic.
16. The method of claim 1 or 2, wherein, the shared data model types include a first set of attributes, and wherein the change in attributes of the local version of the shared data model type comprises modifying one of the first set of attributes.
17. A system comprising: a processor configured to perform operations comprising: retrieving, from a content management system (CMS), first website generation data that references a shared data model type stored on the CMS, the shared data model type also referenced by second website generation data; importing, by a migration agent in communication with a software development tool, from the CMS, a definition of the shared data model type referenced by the first website generation data as a local version of the shared data model type; detecting, by the migration agent, a change in a property of the local version of the shared data model type; generating, by the migration agent, a migration script to migrate the change in the property of the local version of the shared data model type to the shared data model type stored on the CMS and modify the shared data model type; and verifying, prior to implementing the modification to the shared data model type to reflect the change in the property of the local version of the shared data model type, that the second website generation data runs without error when the second website generation data accesses the modified shared data model type.
18. The system of claim 17, wherein, the shared data model type comprises object source code, and wherein the migration agent continuously or periodically monitors the change in the property of the local version of the shared data model type.
19. A non-transitory machine-readable storage medium comprising instructions that, when executed by one or more processors of a machine, cause the machine to perform operations comprising: retrieving, from a content management system (CMS), first website generation data that references a shared data model type stored on the CMS, the shared data model type also referenced by second website generation data; importing, by a migration agent in communication with a software development tool, from the CMS, a definition of the shared data model type referenced by the first website generation data as a local version of the shared data model type; detecting, by the migration agent, a change in a property of the local version of the shared data model type; generating, by the migration agent, a migration script to migrate the change in the property of the local version of the shared data model type to the shared data model type stored on the CMS and modify the shared data model type; and verifying, prior to implementing the modification to the shared data model type to reflect the change in the property of the local version of the shared data model type, that the second website generation data runs without error when the second website generation data accesses the modified shared data model type. the shared data model type comprises object source code, and wherein the migration agent continuously or periodically monitors the change in the property of the local version of the shared data model type.
20. The non-transitory machine-readable storage medium of claim 19, wherein,
Citation Information
Patent Citations
SOA (Service-Oriented Architecture) and WebService based data migration method
CN105740411A
Migrating a web hosting service between a one box per client architecture and a multiple box per client architecture
US20110179176A1