CROSS-REFERENCE TO RELATED APPLICATIONSThis application claims priority to U.S. Provisional Application Ser. No. 62/585,988, filed on Nov. 14, 2017 and entitled “MULTI-FILE REAL-TIME COLLABORATION ENVIRONMENT,” the entirety of which is incorporated herein by reference.
BACKGROUNDComputers and computing systems have impacted nearly every aspect of modern-day living. For instance, computers are generally involved in work, recreation, healthcare, transportation, and so forth.
A computer operates by executing a set of executable instructions (i.e. code). These instructions were created in a development environment by a developer in order to create an application. In many instances, the developer will generate many different versions of the code in an effort to improve the computer's operations and to remove any bugs that are present in the code. Once the instructions are compiled, interpreted, and/or built, an underlying computer system executes the instructions to provide the application's functionalities.
Different tools have been created to assist a developer in writing, editing, testing, and debugging an application's executable instructions. Some of these tools include program code text editors, source code editors, debuggers, and integrated development environments (IDEs), just to name a few. The process of generating and debugging code can be improved through the participation of additional developers. For example, by working together in a team, team members are able to jointly collaborate to review and improve a project.
The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as those described above. Rather, this background is provided to illustrate only one example technology area where some embodiments described herein may be practiced.
BRIEF SUMMARYAt least some of the embodiments described herein relate to making a port available to other computer systems during a collaboration session. Initially, an application may be built on an owner computer system such that the build is saved on the owner computer system. Then, an instance of the build may be run on the owner computer system. A collaboration session in which the owner computer system and a participant computer system are both members may also be established. Within this collaboration session, the participant computer system is provided access to a port that may be used to access the build instance. Next, this build instance is made accessible to the participant computer system via the port. In response to a change to the build, the participant computer system is then provided access to a new instance of the build via the port.
In this manner, the embodiments are able to use a secure collaboration session to forward a port from one computer system to another. Because of this secure collaboration session, the embodiments directly improve how a computer system operates because the computer system's resources will be utilized in a more efficient manner. The embodiments also provide substantial advantages because each collaborator is provided the full context of the workspace in a shared collaboration session. Furthermore, the embodiments directly improve how a web application can be debugged. These and other benefits will be described in more detail later.
This Summary is not intended to identify key or essential features of the claimed subject matter nor is it intended to be used as an aid in determining the scope of the claimed subject matter. Instead, this Summary is provided to introduce a selection of concepts in a simplified form. These concepts are more fully described below in the Detailed Description.
BRIEF DESCRIPTION OF THE DRAWINGSIn order to describe the manner in which the above-recited and other advantages and features can be obtained, a more particular description of various embodiments will be rendered by reference to the appended drawings. Understanding that these drawings depict only sample embodiments and are not therefore to be considered limiting, the embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:
FIG. 1 illustrates an overall view of a computer system.
FIG. 2 provides an example depiction of how a collaboration session may be initiated.
FIG. 3 illustrates the various forms and characteristics that a collaborator may have.
FIG. 4 illustrates an example architecture that may be used to facilitate a collaboration session.
FIG. 5 shows how an integration component is able to configure a client application's user interface so that it includes collaboration options.
FIG. 6A illustrates how a client application is able to access the local files on a participant computer system.
FIG. 6B illustrates how a client application's communications can be intercepted and re-routed.
FIG. 7 demonstrates how an owner computer system is able to process requests submitted by a participant computer system.
FIG. 8 demonstrates how a multi-file workspace can become accessible to a participant computer system.
FIG. 9 demonstrates how the tools of an owner computer system can become accessible to a participant computer system.
FIG. 10 illustrates an example scenario in which a participant computer system is listening to a port in order to gain access to a web application.
FIG. 11 demonstrates how a web application can be emulated from one computer system to another.
FIG. 12 presents an example architecture for forwarding a port within a collaboration session.
FIG. 13 illustrates an example method for forwarding a port within a collaboration session.
DETAILED DESCRIPTIONAt least some of the embodiments described herein relate to making a port available to other computer systems during a collaboration session. Initially, an application may be built on an owner computer system such that the build is saved on the owner computer system. Then, an instance of the build may be run on the owner computer system. A collaboration session in which the owner computer system and a participant computer system are both members may also be established. Within this collaboration session, the participant computer system is provided access to a port that may be used to access the build instance. Next, this build instance is made accessible to the participant computer system via the port. In response to a change to the build, the participant computer system is then provided access to a new instance of the build via the port.
An advantage of the disclosed embodiments is that they allow an “owner collaborator” (or simply “owner”) to remain in control of his/her multi-file workspace even when outside collaborators (also called hereinafter “participant collaborators” or simply “participant(s)”) are joined with the owner in a “collaborative session.” Here, the term “owner” can refer to either a “human owner” or an “owner computer system.” Similarly, the term “participant” can refer to either a “human participant” or a “participant computer system.” In contrast, an “owner computer system” and a “participant computer system” refer only to a computer system and do not include a human operator. Additionally, “collaborator” refers to any entity (e.g., an owner or a participant) that has joined a collaboration session while “collaborators” refers to some or all of the entities in the collaboration session (e.g., the owner and all of the participants).
As also used herein, a “multi-file workspace” is an assembly of multiple files that operate collectively by interacting with each other. As an example, a code development project may include multiple files of source code that, when executed, operate together to perform complex functions. Thus, a code development project may be considered a multi-file workspace. Other examples of a multi-file workspace include, but are not limited to, text files and/or word processing files (e.g., where the files are linked via a table of contents or some other linking unit), or any other content in which multiple sources of data are joined together. Yet another non-limiting example of a multi-file workspace is a wiki-based workspace that is configured to receive edits and/or markdowns from multiple entities. Accordingly, from this disclosure, it will be appreciated that the embodiments are able to operate with regard to any kind of multi-file workspace. For the sake of brevity, and by way of example only, the remaining portion of this disclosure will focus on a multi-file workspace that includes multiple files of source code.
Here, it is also worthwhile to note that a “collaboration session,” as used herein, is an occurrence in which an owner computer system is joined with one or more participant computer systems in order to jointly collaborate on a multi-file workspace. During this collaboration session, the participant computer systems are provided access to a multi-file workspace that is stored locally on the owner computer system. In this manner, the participants need not download the multi-file workspace. Instead, the participant computer systems act as headless units because editing and other operations may be performed on the owner computer system as opposed to occurring on each of the participant computer systems.
Of note, collaboration sessions may be initiated for a broad variety of reasons. For example, in some instances, a collaboration session may be established so that the participants can assist the owner in performing a certain function. For instance, if the collaboration involves debugging, the owner might be the primary person tasked with generating the code, whereas the participants may be other developers who are helping the owner debug that code. In a learning environment, the owner may be a student, and the participant may be a teacher. In an alternative learning environment, a professor may be the owner and his/her students may be the participants. In such a scenario, the professor is able to guide his/her students in demonstrating how the workspace operates. In this context, the owner is able to retain administrative control over his/her multi-file workspace.
Yet another example scenario includes a coding interview process in which the interviewer sets up a workspace environment (e.g., a coding environment). Here, the interviewer is the owner and the interviewee is the participant. In another example scenario, an owner need not be a human on one end of the system. Instead, an owner computer system may be a build server that has no human owner. In this scenario, as will be discussed in more detail later, a human participant, who is using a participant computer system, is able to join a remote codebase (i.e. an “owner” build instance) for the purpose of collaborating in a debugging scenario. Of note, in situations where the owner is a build instance, the disclosed embodiments enable one (or perhaps more) of the participants to assume control of the multi-file workspace. Relatedly, a participant is also able to assume ownership for specific changes to the multi-file workspace.
Having just described some of the situations in which the embodiments may be practiced, the disclosure will now introduce some of the technical benefits that are provided herein. For example, the disclosed embodiments may be implemented to overcome many of the technical difficulties and computational expenses associated with jointly controlling and collaborating on a multi-file workspace. To illustrate, conventional methods for debugging an application often involve each collaborator installing a workspace's global environment/context and then applying the same data (or steps) in order to reproduce the exact issues that led to finding a bug. Such a process consumes a significant amount of time, computing resources, and manpower. As used herein, the term “context” refers to the state of a workspace.
In contrast, the disclosed embodiments provide significant advantages because they enable multiple computers to connect to a single computer, which is running a workspace's environmental logic (e.g., services) and which is maintaining a global context of the workspace, to thereby allow the collaborators to jointly collaborate on the multi-file workspace (as opposed to having multiple different workspaces operating on multiple different computers). These operations result in a significant increase in the overall efficiency of the collaborating computer systems.
Another advantage of the disclosed embodiments is that because only a single workspace is being operated on, the collaborators' operations are synchronized with each other. For example, when multiple collaborators (e.g., code developers) are joined together in a collaborative session, each collaborator is made aware (in real-time) of at least some, and potentially all, of the actions of all of the other collaborators because each collaborator is working on the same workspace. In other words, each collaborator's individual action is “synced” with the actions of the other collaborators.
Having just described various advantages and high-level attributes of some of the disclosed embodiments, the disclosure will now focus onFIG. 1 which presents an introductory discussion of an example computer system. Following that discussion, the disclosure will focus onFIGS. 2 through 9. In particular, these Figures illustrate various architectures and supporting illustrations for providing a collaboration session according to the disclosed principles. Finally, the disclosure will focus onFIGS. 10 through 13 which present various architectures and methods for forwarding a port within a collaboration session.
Example Computer SystemAs illustrated inFIG. 1, in its most basic configuration, acomputer system100 includes various different components. For example,FIG. 1 shows thatcomputer system100 includes at least one hardware processing unit105 (aka “processor”),storage110, input/output (I/O) interfaces115,graphics rendering engines120, andvarious communication channels125.
Thestorage110 may be physical system memory, which may be volatile, non-volatile, or some combination of the two. Accordingly, thestorage115 may be referred to as a “hardware storage device” on which computer-executable instructions are stored. The term “memory” may also be used herein to refer to non-volatile mass storage such as physical storage media. If thecomputer system100 is distributed, the processing, memory, and/or storage capability may be distributed as well. As used herein, the term “executable module,” “executable component,” or even “component” can refer to software objects, routines, or methods that may be executed on thecomputer system100. The different components, modules, engines, and services described herein may be implemented as objects or processors that execute on the computer system100 (e.g., as separate threads).
The disclosed embodiments may comprise or utilize a special-purpose or general-purpose computer including computer hardware, such as, for example, one or more processors (such as hardware processing unit105) and system memory (such as storage110), as discussed in greater detail below. Embodiments also include physical and other computer-readable media for carrying or storing computer-executable instructions and/or data structures. Such computer-readable media can be any available media that can be accessed by a general-purpose or special-purpose computer system. Computer-readable media that store computer-executable instructions in the form of data are physical computer storage media. Computer-readable media that carry computer-executable instructions are transmission media. Thus, by way of example and not limitation, the current embodiments can comprise at least two distinctly different kinds of computer-readable media: computer storage media and transmission media.
Computer storage media are hardware/physical storage devices, such as RAM, ROM, EEPROM, CD-ROM, solid state drives (SSDs) that are based on RAM, Flash memory, phase-change memory (PCM), or other types of memory, or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code means in the form of computer-executable instructions, data, or data structures and that can be accessed by a general-purpose or special-purpose computer.
Thecomputer system100 may also be connected (via a wired or wireless connection) to external sensors (e.g., data acquisition devices). Further, thecomputer system100 may also be connected through one or more wired or wireless network(s)130 to remote systems(s) that are configured to perform any of the processing described with regard tocomputer system100.
Thegraphics rendering engine120 is configured, with the processor(s)105, to render one or more objects on a display of thecomputer system100. As a result, a user is able to view the results of the various functionalities of thecomputer system100.
A “network,” like the network(s)130 shown inFIG. 1, is defined as one or more data links and/or data switches that enable the transport of electronic data between computer systems, modules, and/or other electronic devices. When information is transferred, or provided, over a network (either hardwired, wireless, or a combination of hardwired and wireless) to a computer, the computer properly views the connection as a transmission medium. As illustrated thecomputer system100 includes one ormore communication channels125 that are used to communicate with the network(s)130. Transmissions media include a network that can be used to carry data or desired program code means in the form of computer-executable instructions or in the form of data structures. Further, these computer-executable instructions can be accessed by a general-purpose or special-purpose computer. Combinations of the above should also be included within the scope of computer-readable media.
Upon reaching various computer system components, program code means in the form of computer-executable instructions or data structures can be transferred automatically from transmission media to computer storage media (or vice versa). For example, computer-executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., a network interface card or “NIC”) and then eventually transferred to computer system RAM and/or to less volatile computer storage media at a computer system. Thus, it should be understood that computer storage media can be included in computer system components that also (or even primarily) utilize transmission media.
Computer-executable (or computer-interpretable) instructions comprise, for example, instructions that cause a general-purpose computer, special-purpose computer, or special-purpose processing device to perform a certain function or group of functions. The computer-executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, or even source code. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or acts described above. Rather, the described features and acts are disclosed as example forms of implementing the claims.
Those skilled in the art will appreciate that the embodiments may be practiced in network computing environments with many types of computer system configurations, including personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, tablets, pagers, routers, switches, cloud-based machines and infrastructures, and the like. The embodiments may also be practiced in distributed system environments where local and remote computer systems that are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network each perform tasks (e.g. cloud computing, cloud services and the like). In a distributed system environment, program modules may be located in both local and remote memory storage devices.
Additionally or alternatively, the functionality described herein can be performed, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-Programmable Gate Arrays (FPGAs), Program-Specific or Application-Specific Integrated Circuits (ASICs), Program-Specific Standard Products (ASSPs), System-On-A-Chip Systems (SOCs), Complex Programmable Logic Devices (CPLDs), Central Processing Units (CPUs), and other types of programmable hardware.
As discussed above, computer systems are able to provide a broad variety of different functions. According to the principles disclosed herein, the embodiments are able to provide a multi-file real-time collaboration environment. Accordingly, attention will now be directed toFIGS. 2 through 9, which figures present various architectures and supporting illustrations for establishing a collaboration session.
Collaboration SessionFIG. 2 illustrates acollaboration session200 in which anowner computer system205 and aparticipant computer system210 are both members. Notably, both theowner computer system205 and theparticipant computer system210 may include all of the features and functionalities that were discussed in relation to thecomputer system100 ofFIG. 1. Accordingly, when reference is made to a “computer system,” it will be appreciated that such a system may include the features ofcomputer system100.
Here, it will be appreciated that there may be any number of participant computer systems in thecollaboration session200. For instance,FIG. 2 shows that Participant “A,” Participant “B,” and/or Participant “C” may be included in thecollaboration session200. As a result, theowner computer system205 may be a first member in thecollaboration session200, Participant “A” may be a second member in thecollaboration session200, Participant “B” may be a third member in the collaboration session (i.e. three or more members are joined), and so on with potentially no limit. Accordingly,FIG. 2 is for example purposes only and should not be considered limiting. Furthermore, the remaining portion of this disclosure focuses on collaboration sessions that depict only a single participant; however, it should be understood that the principles may be practiced with any number of participants.
Returning toFIG. 2, the disclosed embodiments establish thecollaboration session200 so that theparticipant computer system210 is able to gain access to a multi-file workspace stored on theowner computer system205. In this manner, theparticipant computer system210 can operate on the remote workspace as if the remote workspace were local. For instance, a human participant can independently view, edit, and otherwise operate on the remote workspace. By creating this type of collaboration session, all of the collaborators (e.g., the owner and participant(s)) are all able to collaborate on a single multi-file workspace. Accordingly, the disclosed embodiments provide many efficiencies over traditional collaboration processes.
Here, thecollaboration session200 may be initiated in a variety of ways. In some embodiments, the collaborators (e.g., theowner computer system205 and the participant computer system210) are able to communicate with each other over a local area network (LAN)connection215. When this type of connection is available, then thecollaboration session200 may be initiated by sending arequest220 over theLAN connection215. In this manner, the collaborators are able to communicate directly in a peer-to-peer manner. To summarize, the collaboration session may be initiated using a peer-to-peer connection between the collaborator computer systems, where the peer-to-peer connection is established via a local area network connection.
Of note, in some instances, theowner computer system205 may desire that theparticipant computer system210 be authenticated prior to entering thecollaboration session200. As such, the embodiments are able to use the cloud225 to provide authentication services. For example, some embodiments provide anauthentication service230 in the cloud225. Theparticipant computer system210 can use thisauthentication service230 to authenticate itself to theowner computer system205. After the authentication is complete, then thecollaboration session200 can be initiated and theowner computer system205 and the authenticatedparticipant computer system210 can jointly work on a multi-file workspace.
In other embodiments, thecollaboration session200 is initiated by sending therequest220 through arelay service235 operating in the cloud225. Here, thisrelay service235 is able to connect computers that are on different native networks. Accordingly, the embodiments are able to use various services residing in the cloud225 in order to initiate thecollaboration session200.
Other embodiments use a hybrid approach to initiating thecollaboration session200. For instance, if some participant computer systems are located on the same LAN as theowner computer system205, then therequest220 can be sent to those participant computer systems using the LAN. Additionally, if some participant computer systems are not using the same LAN as theowner computer system205, then therequest220 can be transmitted using therelay service235 in the cloud225. Accordingly, the disclosed embodiments are able to use a variety of methods for initiating thecollaboration session200. Here, it is worthwhile to note that the disclosed embodiments are able to intelligently select whichever process is most efficient to initiate thecollaboration session200. On a related note, thecollaboration session200 is able to continue to use the respective network connections to maintain the communications between the collaborators.
Ending thecollaboration session200 may be performed in a variety of ways. In some embodiments, thecollaboration session200 ends through an action of one of the collaborators. For example, one of the collaborators may select an “End Collaboration” option.
In another embodiment, the collaboration session may end upon expiration of a time-out period. For example, the owner may have configured a policy controlling how long the collaboration session will remain active. Upon expiration of that period, the participants' connection to the collaboration session will be terminated. Additionally, the owner may set a policy indicating a time-out period associated with the shutting down of a client (e.g., an IDE). For example, the owner may set a time-out period to cause the collaboration session to terminate after a predetermined period of time has elapsed after the client was shut down. Such a feature is beneficial because it provides the collaborators adequate time to save any changes or to provide documentation within the code.
Alternatively, other embodiments are configured to end the collaboration session when the owner computer system shuts down and/or the owner logs off of the owner computer system. In yet another alternative embodiment, the collaboration session may continue to run even after the owner computer system has shut down, gone to sleep, or been logged off. As an example, suppose the human owner decided to perform a quick reboot or had to quickly attend a meeting. Here, because the collaboration session is still active (even though the owner computer system may not be active), the human owner will be able to quickly resume her work when she returns from her activities. An advantage realized by this embodiment is that if any configuration options are adjusted, then those adjustments can be persisted and will be in place for the remaining duration of the collaboration session. In this manner, the collaborators will be able to quickly resume working at the locations where they left off, and they can continue to operate using the same configuration options.
Other embodiments include audit tracking features that record each collaborators' actions (e.g., their edits). In this manner, these embodiments provide an audit trail that can be reviewed and analyzed at a later time, if the need or desire arises. Once the collaboration session ends based on the principles discussed above, then the audit tracking may also end.
Similar toFIG. 2,FIG. 3 illustrates anothercollaboration session300. Here, it will be appreciated thatcollaboration session300 is analogous to thecollaboration session200 ofFIG. 3. In the scenario presented inFIG. 3, thecollaboration session300 includes anowner305 and aparticipant computer system310.
In particular,FIG. 3 shows some of the various characteristics that theowner305 and theparticipant computer system310 may have. As an example, theowner305 may not be a computer system with a human operator. Instead, it may be a build instance of an application, as shown inFIG. 3. On a related note, theowner305 may be a headless build instance that is residing in the cloud. In such a scenario, then the various participants are able to operate on the codebase on which the build instance is based.
Alternatively, theowner305 may be a computer system (as shown inFIG. 3) that is using a first type of operating system (e.g., Operating System “A”). In some situations, a human owner will operate theowner305. Furthermore, the human owner is able to perform work on the multi-file workspace through the use of a client application that is residing on theowner305. As used herein, a “client application” may be any type of application that enables theowner305 to operate on the multi-file workspace. In situations where the multi-file workspace is a collection of text files, a client application may be a text editor, a word processing program, or any other program suitable to operate on the text files. In situations where the multi-file workspace is a collection of source code files, a client application may be a source code editor, an integrated development environment (IDE), or any other program suitable to operate on source code. Here, it will be appreciated that these client applications are provided permissions to access the multi-file workspace residing on theowner305. AlthoughFIG. 3 shows that theowner305 is able to operate a client application that is in the form of an IDE (e.g., IDE “A”), it will be appreciated that any type of client application may be used, not just an IDE.
Turning now to theparticipant computer system310, theparticipant computer system310 may also be a computer system that is using an operating system (e.g., Operating System “B”). Here it is worthwhile to note that Operating System “B” may be different than Operating System “A.” As a result, theowner305 and theparticipant computer system310 need not use the same type of operating system in order to be joined together in thecollaboration session300 to work on the multi-file workspace. Relatedly, theparticipant computer system310 need not use the same type of client application (e.g., IDE “B”) as theowner305. Therefore, according to the principles disclosed herein, a participant is able to use his/her preferred operating system and client application regardless of the type of operating system and/or client application that the owner (e.g., owner305) is using. Accordingly, the embodiments are operating system agnostic and client application agnostic.
Up to this point, the disclosure has presented some of the ways in which a collaboration session may be initiated and some of the characteristics of the collaborators. In light of that background, attention will now be directed toFIG. 4, which presents some architectural components that may be used to realize the benefits of the disclosed principles.
FIG. 4 illustrates acollaboration session400 in which anowner computer system405 and aparticipant computer system410 are members. Here, theowner computer system405 is a computer system that includes acollaboration agent415. As illustrated, thiscollaboration agent415 includes a set of base tools420 (e.g., Tool A, Tool B, and Tool C). AlthoughFIG. 4 shows thecollaboration agent415 as including only three base tools, it will be appreciated that thecollaboration agent415 may include any number of base tools. Additional details on thebase tools420 will be presented momentarily.
Theowner computer system405 also includes aclient application425. As discussed earlier, a client application (e.g., client application425) may be a text editor, word processing editor, source code editor, IDE, or any other type of application that enables a user to operate on a multi-file workspace. In light of that understanding,client application425 may include aclient tool430. Similar to the above disclosure, although theclient application425 is shown as including only a single tool, it will be appreciated that theclient application425 may have any number of tools. Relatedly, theowner computer system405 may have any number of client applications installed thereon. As an example, theclient application425 may be an integrated development environment (IDE) that has permissions to access the multi-file workspace. Further, this IDE may manage/host a set of client development tools. In this manner, the IDE can be used to work on the multi-file workspace.
Here, it will be appreciated that a base tool (e.g., Tool A, Tool B, or Tool C) may be a service or other type of function/tool that is generally common across many or all of the different types of client applications. For example, in the context of code editing, thebase tools420 may include a code completion service, a code debugging service (e.g., a source code error checking tool), a code highlighting service, a code navigation service, a code colorization service (e.g., syntax highlighting in which different colors are applied to the syntax depending on what category a syntax term belongs to), a code refactoring service (e.g., restructuring code without altering its behavior), a code hinting service (e.g., code completion), a source code search tool, a source code control tool, and/or a lightbulb service (e.g., an icon service that provides an expanded display of options).
Additional services and tools include, but are not limited to, providing member lists, parameter information, symbol services, source code transpilation (e.g., changing the source code so it reads in a different coding language), hover features, smart typing abilities, and quick code information. Relatedly, theclient tool430 may be a tool that is specific to a particular client application and that is not generally common among different client applications. As an example, theclient tool420 may be a tool or service specific to a particular type of IDE.
According to the principles disclosed herein, theowner computer system405 is able to make these set of development tools (i.e. both the set ofbase tools420 and the client tool430) accessible to theparticipant computer system410. Because these tools reside on theowner computer system405, the tools have access to the entire context of the multi-file workspace. By making the tools accessible to theparticipant computer system410, a human participant is able to use the tools in light of the entire context of the multi-file workspace. In this manner, the collaborators are able to operate on the multi-file workspace using a set of tools that understand the workspace's entire context.
Returning toFIG. 4, theowner computer system405 also includes anintegration component435 and a set oflocal files440. In some embodiments, the multi-file workspace is included within the set oflocal files440 on theowner computer system405.
As discussed earlier, it is often desirable to enable a team of developers to jointly work on a project. According to the principles discussed here, thecollaboration session400 may be initiated so as to enable one or more participants (e.g., participant computer system410) to join theowner computer system405 in collaborating on a multi-file workspace that is stored locally on the owner computer system405 (e.g., perhaps in the local files440).
To achieve these benefits, the disclosed embodiments cause theintegration component435 to attach, or rather “hook,” to theclient application425 in a lightweight manner. For example, theintegration component435 may be a plugin or other type of client extension that hooks into theclient application425 to perform “redirection,” “rerouting,” and customization operations. For example, the integration component435 (which is on the owner computer system405) is configured to add additional functionalities to theclient application425. Of note, these additional functionalities are at least directed to establishing and maintaining thecollaboration session400.
To illustrate,FIG. 5 shows anowner computer system500, which is analogous to theowner computer system405 ofFIG. 4. InFIG. 5, theowner computer system500 includes aclient application505 and anintegration component510. Theclient application505 is also shown as including a user interface515. After theintegration component510 hooks itself onto theclient application505, then theintegration component510 is able to expand upon the abilities of theclient application505.
For example, in some embodiments, theintegration component510 will alter the user interface515 so that it includes additional features related to a collaboration session. To illustrate, a set ofnew collaboration options525 have been added to the user interface515 as a result of theintegration component510 attaching itself to theclient application505. The set ofnew collaboration options525 includeOption1,Option2, andOption3. Theellipses520 demonstrates that any number of options may be added to the user interface515. Some of the set ofcollaboration options525 may include, but are not limited to, (1) an option to initiate a collaboration session, (2) an option to terminate a collaboration session, and/or (3) an option to acquire information about a particular participant (e.g., the participant's avatar may be displayed and, when the avatar is selected, identifying information about the participant may be displayed).
Another option is a “pin” to participant's position option. As discussed, the embodiments enable a participant to work on a multi-file workspace that is stored locally on an owner computer system. Included with this functionality is the ability of the participant to independently navigate to areas within the multi-file workspace where the owner computer system is not currently operating (or even in locations where the owner computer system is operating). Furthermore, the embodiments also enable the participant to independently edit files. In light of these abilities, an owner may desire to learn where a participant is currently navigating/operating within his/her multi-file workspace.
By selecting the pin to participant's position option (e.g., the options can be selectable buttons), the embodiments automatically navigate the owner to the same location as a participant within the workspace. If there are multiple participants, then the owner may initially be prompted to select a particular participant. As an example, suppose an owner is editingFile1 shown in the user interface515 inFIG. 5. At the same time, a participant may be independently editingFile2. By clicking the pin to participant's position option, the owner can be automatically navigated toFile2, and in particular to the exact location where the participant is editingFile2. Therefore, although the embodiments enable participants to independently navigate and edit the files within the workspace, the embodiments also enable the owner to be automatically directed to the locations within the workspace where the participants are working. In some embodiments, this feature is also provided to each of the participants. Therefore, in these embodiments, each collaborator is able to follow the actions of the other collaborators.
Another option that may be provided among the set ofnew collaboration options525 is the option to adjust the access controls of the participants. For example, the owner may be provided with an option to adjust a policy so that participants are allowed to navigate to or edit only certain files. Yet another option is related to an audit feature in which the actions of the participants are recorded and are made available for viewing by the owner. Accordingly, theintegration component510 is able to interact with theclient application505 to enhance the owner's control over the participants in a collaboration session.
Returning toFIG. 4, attention will now be directed to theparticipant computer system410. Here, theparticipant computer system410 is shown as including acollaboration agent445, aclient application450, anintegration component455, andlocal files460. Here, thecollaboration agent445 communicates with thecollaboration agent415 to provide theparticipant computer system410 access to the multi-file workspace residing on theowner computer system405. Additional details on this interaction will be presented later. At this point, it is worthwhile to note that theclient application450 also provides a user interface to the participant so that the participant is able to view (and therefore work on) the multi-file workspace.
Similar to theintegration component435, theintegration component455 also attaches itself to theclient application455. The functionalities of thisintegration component455 will now be discussed in relation toFIGS. 6A and 6B.
FIG. 6A shows aparticipant computer system600A that includes a set oflocal files605A, which are analogous to thelocal files460, and a client application610A. In this scenario, theparticipant computer system600A does not have an integration component. Accordingly, when theparticipant computer system600A is thusly configured, the client application610A is able to submitrequests615A to the set oflocal files605A. In this manner, the client application610A operates on files that are stored locally on theparticipant computer system600A.
To enable a participant computer system to operate on a remote multi-file workspace in an operating system agnostic and client application agnostic manner, the participant computer system uses a collaboration agent and an integration component. These features are shown inFIG. 6B. For example, theparticipant computer system600B ofFIG. 6B includes acollaboration agent605, a set oflocal files610B, aclient application615B, and anintegration component620. After attaching itself to theclient application615B, theintegration component620 is able to interceptrequests625B that are issued by theclient application615B. Normally, theserequests625B would be fulfilled using the set oflocal files610B. Now, instead of therequests625B being fulfilled using the information from the set oflocal files610B, theintegration component620 intercepts thoserequests625B and routes the interceptedrequests625B to thecollaboration agent605. Once therequests625B are received, thecollaboration agent605 then routes the interceptedrequests625B to a collaboration agent residing on the owner computer system (e.g.,collaboration agent415 inFIG. 4).
Turning briefly toFIG. 7,FIG. 7 shows how an owner-side collaboration agent handles requests that are received from a participant-side collaboration agent. Here, thecollaboration session700 includes anowner computer system705 and aparticipant computer system710. Theowner computer system705 includes acollaboration agent720, a set ofbase tools725, a set of client tools730, and a set oflocal files735. Theellipses740 demonstrates that theowner computer system705 may have additional features.
In this scenario, a participant-side collaboration agent is able to receive an intercepted request as described in connection withFIG. 6B. This request is shown asrequest715 inFIG. 7. Here, the participant-side collaboration agent transmits therequest715 to thecollaboration agent720. After receiving therequest715, thecollaboration agent720 then processes therequest715. In some instances, processing therequest715 includes making the set ofbase tools725 accessible to theparticipant computer system710. Relatedly, processing therequest715 may include making the set of client tools730 accessible to theparticipant computer system710. In other instances, processing therequest715 may include making the set oflocal files735 accessible to theparticipant computer system710. In this manner, a multi-file workspace residing on theowner computer system705 may be made accessible to theparticipant computer system710. In some instances, processing therequest715 includes making edits to the files in the multi-file workspace. Edits include, but are not limited to, changing text within the file, adding a new file, deleting an existing file, or any other file editing operations.
Here, it is worthwhile to note that theparticipant computer system710 is not downloading the multi-file workspace. Instead, it is being given access to the workspace through the use of its collaboration agent, its integration component, and the owner-side collaboration agent. In this manner, theparticipant computer system710 is able to reach across and perform work on theowner computer system705's multi-file workspace. After therequest715 is processed by theowner computer system705, thecollaboration agent720 then transmits a response back to theparticipant computer system710. In particular, thecollaboration agent720 transmits the response back to the participant-side collaboration agent.
Returning toFIG. 6B, thecollaboration agent605 will then receive any responses generated by an owner computer system. Once a response is received, then some embodiments will cause the response to be transmitted back to theclient application615B via theintegration component620. In other embodiments, however, thecollaboration agent605 is able to directly transmit the response (e.g., response630) to theclient application615B. In this manner, the participant is able to see the results of his/her processed requests.
Here, an example will be helpful. Suppose an owner establishes a collaboration session in which a participant is a member. The owner has asked the participant to assist him/her in debugging source code. The owner begins by debugging a first file while the participant begins by debugging a second file. Of note, both of these files are included in the multi-file workspace and both are stored on the owner's computer system. In this example, the second file is displayed on the participant's computer system even though the file's contents are actually stored only on the owner's computer system.
Additionally, the participant is able to independently view and edit the contents of the second file even though the owner is currently working on the first file. In this manner, multiple collaborators are able to jointly work on a single multi-file workspace. In some instances, the owner and the participant will be working on the same file. When such a scenario is present, then the owner will be able to see (in real-time) the changes made by the participant, and the participant will be able to see (in-real time) the changes made by the owner. Accordingly, the changes made by the collaborators are made in real-time and are synchronized with each other. In light of this discussion, it will be appreciated that the participant is given the illusion that he/she is working on a local workspace whereas, in actuality, the workspace is not local.
By following these principles, the disclosed embodiments are able to provide a participant computer system access to a multi-file workspace that is stored on the owner computer system. Furthermore, a human participant is able to view that workspace and to edit that workspace. This viewing and editing can be performed independently of any viewing and editing that an owner may be performing on the multi-file workspace. In this manner, a participant no longer needs to replicate a workspace's context in order to work on that workspace. Additionally, the participant is able to use his/her preferred client application, even if that client application is different from the owner's client application. Even further, the participant is able to use the owner's set of tools, which tools understand the entire context of the multi-file workspace.
Attention will now be directed toFIG. 8, which provides additional details for enabling a participant to collaborate on a multi-file workspace. Here, thecollaboration session800 includes anowner computer system805 and aparticipant computer system810. Theowner computer system805 includes acollaboration agent815, aclient application820, anintegration component825, and a set oflocal files830. The set oflocal files830 includes amulti-file workspace835. Here, thismulti-file workspace835 includes a set offiles840, acontext845 of themulti-file workspace835, and a file directory850.
When thecollaboration agent815 receives a request from theparticipant computer system810 according to the manner just described, thecollaboration agent815 is able to process the request and return aresponse855 to theparticipant computer system810. As shown, thisresponse855 may include file data860 (i.e. data concerning the set of files840), context data865 (i.e. data concerning the context845), or directory data870 (i.e. data concerning the file directory850). In some instances, this data is metadata while in other instances this data enables theparticipant computer system810 to display the multi-file workspace and receive edits directed to the multi-file workspace. In this manner, providing theparticipant computer system810 access to the multi-file workspace includes providing access to the workspace's file directory, context, and files. From this information, themulti-file workspace835 can be displayed on theparticipant computer system810, and the participant will be able to operate on that multi-file workspace.
From the above disclosure, it will be appreciated that theowner computer system805 is transmitting sufficient information (e.g., metadata and other information) so that theparticipant computer system810 is able to understand what is included within themulti-file workspace835. Furthermore, theparticipant computer system810 is able to receive enough information so that a visualization of themulti-file workspace835 may be rendered on a user interface of theparticipant computer system810. In this manner, theparticipant computer system810 is acting as a headless entity because a majority of the operations are actually being performed on theowner computer system805.
For example, theparticipant computer system810 submits viewing and editing requests to theowner computer system805. Theowner computer system805 then processes those requests and returns results back to theparticipant computer system810. As such, theparticipant computer system810 is provided the illusion that it is working on a local workspace, but in actuality the workspace is not local and the operations on the workspace are being performed by theowner computer system805.
FIG. 9 shows some additional operations that may be performed. Here, thecollaboration session900 includes anowner computer system905 and aparticipant computer system910. Theowner computer system905 includes acollaboration agent915. As discussed, thiscollaboration agent915 is able to maintain a set ofbase tools920. Theowner computer system905 also includes a client application925, which client application925 is able to maintain a set ofclient tools930.
According to the principles discussed herein, the embodiments are also able to make the set ofbase tools920 and the set ofclient tools930 accessible to theparticipant computer system910. For example, theparticipant computer system910 is able to use the tools that are residing on theowner computer system905 in order to perform operations on theowner computer system905's multi-file workspace. Therefore, not only is theparticipant computer system910 able to view and edit the multi-file workspace on theowner computer system905, but it is also able to make use of the tools that are on theowner computer system905. Theparticipant computer system910 is able to receiveinformation935 that includesbase tool data940 and/orclient tool data945. In this manner, theparticipant computer system910 is able make use of theowner computer system905's development tools.
Assistive Debugging of Web Applications with Port ForwardingHaving just described how a collaboration session may be established, attention will now be directed toFIGS. 10 through 12. In particular, these figures demonstrate how a collaboration session may be used to forward a port so that multiple collaborators can see the immediate results of their edits. As used herein, “forwarding” a port refers to the process of providing the collaborators access to the port. As a result, the embodiments enable collaborators to view how their source code edits impact an application's build instance through the use of a shared/forwarded port.
At this point, it is worthwhile to reflect on what a port is. Initially, it is noted that each computer system typically includes an internet protocol (IP) address. This IP address is useful for differentiating the computer from other networked computers. When information is sent over a network (i.e. “streamed”) to a computer that has an IP address, that information may be received at one of the computer's ports. Notably, each IP address is typically associated with a large number of ports; furthermore, the IP address can be associated with various different types of ports. To illustrate, an IP address may be associated with a transmission control protocol (TCP) port and/or a user datagram protocol (UDP) port, just to name a couple. In some situations, a computer may include at least 65,535 TCP ports (i.e. 216minus one which is a 16-bit port protocol convention) and an equal number of UDP ports.
When an application streams data, that application can attach itself to a particular port. Once attached, the application is then able to transmit and/or receive information from other networked computer systems via that port. Therefore, while the IP address functions to identify the computer system to other computer systems, a port allows the computer system (and specific applications running on the computer system) to provide a specific location on the computer system to receive streamed data.
Additional details on some of the various different types of ports will now be presented. First, it is noted that when networked computer systems communicate through the use of the transmission control protocol (TCP), those computer systems actually establish a direct linkage with each other. For instance, when using this protocol, a transmitting computer system will establish a direct link with a receiving computer system. This link will be present throughout the entire course of a data transfer. In this manner, the data may be transferred securely and reliably. Once the data transfer is complete, the link will often be broken. Here, it will be appreciated that a TCP port is used when the transmission control protocol (TCP) is being used.
In contrast to the transmission control protocol (TCP), the user datagram protocol (UDP) transfers data by passing data packages through a series of “intermediate” network nodes. To illustrate, a transmitting computer system may generate a package of data and then send this package to a first intermediate node in the network (e.g., another computer system, a modem, a hub, a bridge, a switch, etc.). From there, the package can be delivered to any number of other intermediate nodes prior to reaching an endpoint (i.e. a receiving computer system). Accordingly, with this protocol, the two computer systems are not connected directly to each other. Here, it will be appreciated that a UDP port is used when the user datagram protocol (UDP) is being used.
Accordingly, the embodiments are able to provide common access to a port. This port may be a TCP port, a UDP port, or any other type of port. Providing access to this port allows the owner of the collaboration session to extend, or rather enhance, the collaborative efforts.
In some embodiments, this port sharing process is performed, at least in part, by sharing (i.e. forwarding) a TCP port, a UDP port, or any other type of port with the participant computer systems. As discussed earlier, computer applications are able to attach themselves to specific ports. With this understanding, it will be appreciated that the multi-file workspace is able be attached/associated to this port. In some circumstances, the multi-file workspace (which may be an application) is a web application that the collaborators are attempting to debug. By gaining access to the port, the collaborators are able to see how the web application changes in response to their debugging efforts. In this manner, the web application is accessible via the port.
The embodiments provide significant benefits over traditional port forwarding technologies in various ways. For example, because the collaborators (e.g., the owner computer system and the participant computer systems) are already joined together via the collaboration session, a secure communication channel is already in place. As a result, the embodiments are able to use this secure channel to forward a connection to the port and/or to forward the traffic that is passing through the port. In this manner, participant computer systems are able to listen to the port so as to gain access to the underlying workspace. Therefore, significant improvements in efficiency are achieved because an additional channel is not necessary to forward the port.
Furthermore, the embodiments provide other benefits. Some benefits include, but are not limited to, providing access to the port and the port's traffic in both a secure manner and via a convenient environment (i.e. the collaboration session). Regarding the convenience aspect, multiple collaborators are able to communicate with each other as a result of the securely shared port. This is accomplished, at least in part, because the embodiments have already established a secure communication environment (i.e. the collaboration session). As a result, the embodiments provide significant benefits because they do not require an additional setup or environment in order to provide access to the port.
As another example, during the initialization of the collaboration session, the collaborators may undergo an authentication process to ensure that only authorized collaborators are present. Because the collaborators are already authenticated, the port may be forwarded without performing an additional authentication process. To clarify, since the port forwarding is done through the collaboration agents residing on the collaborator computer systems, the owner is able to securely set up port forwarding to the application he/she is debugging and is able to limit access only to the authenticated participants who are running the collaboration agents on the participant side.
As yet another example, the collaboration agents that run on each collaborator computer system (e.g., the owner computer system and the participant computer systems) are run locally. As a result, the process of forwarding the port within the collaboration session can achieve total equivalence in the end point addresses (e.g., the IP addresses of the collaborator computer systems). Therefore, providing the port within the collaboration session results in significant improvements to a computer system's efficiency, to a computer system's security, and to various conveniences associated with using a collaboration session to forward access to a port.
By way of example, the localhost:8080 on the owner computer system can be shared as the same localhost:8080 on each of the participant computer systems. As such, the port may be located on the localhost. Such a process also removes some (or all) firewall interferences that occur between the participant computer systems and the owner computer systems. This is achieved because the traffic associated with forwarding the port is funneled through the collaboration session. Therefore, so long as the firewall is properly configured to allow the collaborator agents (on each collaborator computer system) to interact with each other during the collaboration session, the embodiments are able to pass messages with each other without experiencing interference from the firewalls. In other words, other than a potential initial configuration to allow the collaboration agents to operate, the embodiments do not require any additional firewall configuration changes in order to perform “sub-actions” while the collaboration session is active. To illustrate, forwarding access to the port, making edits to a file, and performing debugging operations are all “sub-actions” that may be performed within the collaboration session. Because the firewall was configured to allow the collaboration session to occur, no additional firewall changes will be required for these sub-actions. In this manner, significant efficiency, security, and convenience benefits are realized.
Another benefit of providing access to a port through the use of a collaboration session is related to the use of development tools. For instance, by gaining access to a port associated with the workspace, the development tools are provided with additional context of the workspace. In this manner, the development tools will be able to operate even more efficiently because they have access to the workspace's full context. Additionally, because of these features, the collaborators will be able to perform more informed/educated actions against the workspace because each collaborator is provided with the workspace's entire context. Accordingly, the disclosed embodiments provide port forwarding within the context of a collaboration session. This port forwarding process is seamless, hassle-free, and requires little to no need for additional configuration, setup, or use of a third party external website.
Having just described some of the benefits of the disclosed embodiments, attention will now be directed toFIG. 10. Here, this figure illustrates an example architecture in which the embodiments may be realized.
As illustrated,FIG. 11 shows acollaboration session1000 in which anowner computer system1005 and aparticipant computer system1010 are both members. Here, theowner computer system1005 includes aworkspace1015 and aport1020. As discussed earlier, thisworkspace1015 may be a web application. In the situation presented inFIG. 10, theport1020 is associated with theworkspace1015. As an example, the association may be formed by theworkspace1015 binding itself (e.g., via binding action1025) to theport1020. Here, it is worthwhile to note that theworkspace1015 should be interpreted broadly. For example, theworkspace1015 may include a web application, the web application's build, and any instances of the web application's build. Therefore, it will be appreciated that the build and the build instances are also associated with theport1020.
According to the principles disclosed herein, the embodiments are able to make theport1020 accessible to theparticipant computer system1010. In some instances, making theport1020 accessible to theparticipant computer system1010 includes enabling theparticipant computer system1010 to listen1030 (e.g., on the localhost) to theport1020. Accordingly, it will be appreciated that both theowner computer system1005 and theparticipant computer system1010 are able to use theport1020 to view some (or all) of the build, the build instance(s), and/or any information/output that is associated with the build.
In situations where theworkspace1015 includes a web application, both theowner computer system1005 and theparticipant computer system1010 are able to use theport1020 to see how the web application performs. Therefore, using theport1020, theparticipant computer system1010 is able to open a web browser, navigate to the localhost, and view how the web application operates on the browser. In this manner, the web browser is usable to access the web application using the port. Such a function is beneficial because it enables human collaborators, regardless of whether it is a human participant or a human owner, to see how the web application operates during the debugging process.
Turning now toFIG. 11, this figure provides additional details on how a port is forwarded within a collaboration session. Here, acollaboration session1100 is established in which anowner computer system1105 and aparticipant computer system1110 are both members. As illustrated, theowner computer system1105 is hosting aweb application1115A. By “hosting” it is meant that theweb application1115A's source code is stored on theowner computer system1105; additionally, a build and any build instances of theweb application1115A are also stored locally on theowner computer system1105.
Although not displayed inFIG. 11, theweb application1115A is associated with a port (e.g. theport1020 shown inFIG. 10). Here, theparticipant computer system1110 is provided access to that port so that theparticipant computer system1110 is able to also view the web application (e.g.,web application1115B). In this manner, the disclosed embodiments emulate1120 theweb application1115A so that the web application (e.g.,web application1115B) is viewable on theparticipant computer system1110.
By “[A1]emulate/emulating,” it is meant that separate instances (e.g.,web application1115A andweb application1115B) of the front end of the web application are being displayed on each collaborator's computer system (e.g., theowner computer system1105 and the participant computer system1110). Additionally, each collaborator is able to independently view the web application's underlying workspace (i.e. the source code). Included with the ability to view the workspace is the ability to see the values of the execution lines (e.g., variable values) and the ability to submit debug commands (e.g., step forward, step backward, step through, execute to breakpoint, etc.) against the execution lines (i.e. program statements) of the source code.
Turning now toFIG. 12, this figure shows some of the underlying architecture that may be used to realize some of the embodiments. Here, acollaboration session1200 has been established in which an owner computer system1205 and aparticipant computer system1210 are both members. The owner computer system1205 includes acollaboration agent1215, aport1220, and aworkspace1225. Of note, thisworkspace1225 includes a web application1230A. Theparticipant computer system1210 includes acollaboration agent1240 and aweb application1230B. As shown in this figure, the web application1230A is emulated1235 to theparticipant computer system1210 so that theparticipant computer system1210 is able to view the web application (e.g.,web application1230B). The process of emulating the web application1230A is described above in relation to forwardingaccess1245 to theport1220.
FIG. 12 demonstrates that the process of forwardingaccess1245 to theport1220 may be accomplished in a variety of ways. Initially, it is noted that “forwarding access to the port” and “forwarding the port” mean the same and are interchangeable phrases. In a first embodiment, forwardingaccess1245 to theport1220 is performed via thecloud1250, and, in particular, by arelay service1255 that is residing in the cloud. Such an embodiment is useful in situations where theparticipant computer system1210 and the owner computer system1205 are not on the same local area network. It follows then, that another method of forwardingaccess1245 to theport1220 may be performed via a local area network (LAN)1260 connection. Accordingly, the embodiments are able to use whichever connection is available and/or fastest.
Example MethodsThe following discussion now refers to a number of methods and method acts that may be performed. Although the method acts may be discussed in a certain order or illustrated in a flow chart as occurring in a particular order, no particular ordering is required unless specifically stated, or required because an act is dependent on another act being completed prior to the act being performed. These methods may be implemented by one or more processors of a computer system (e.g., thecomputer system100 ofFIG. 1). By way of example, a computer system includes one or more computer-readable hardware storage media that store computer-executable code. This computer-executable code is executable by the one or more processors to cause the computer system to perform these methods.
FIG. 13 illustrates anexample method1300 for providing multiple collaborators access to a common port within a collaboration session. Initially,method1300 includes an act of creating a build of an application and storing the build locally on an owner computer system (act1305).Method1300 also includes an act of running an instance of that build on the owner computer system (act1310). Here, both of these acts may be performed by a client application (e.g.,client application820 shown inFIG. 8).
Next,method1300 includes an act of establishing a collaboration session in which the owner computer system and a participant computer system are both members (act1315). Within this collaboration session, the participant computer system is provided access to that port so that the participant computer system is able to access the build instance (act1320). Here, these acts may be performed by thecollaboration agent1215 and theport1220 shown inFIG. 12. In some instances, an authentication associated with the collaboration session is used to authenticate the providing of the port to the participant computer system. As a result, a separate port authentication may not be performed when the port is provided.
Method1300 also includes an act of causing the build instance to be accessible to the participant computer system via the port (act1325). This act may be performed by thecollaboration agent1215.
Finally,method1300 is shown as including an act of providing access to a new instance of the build to the participant computer system via the port (act1330). Here, this act may be performed in response to a change to the build. Further, this act may be performed individually or by a combination of theclient application820 and thecollaboration agent1215.
Accordingly, the disclosed embodiments enable collaborators in a collaboration session to use a common port to see how a build changes in response to various actions. As a result, significant advantages are realized because the collaborators are able to see the direct results of their activities.
The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.