CA2201276C - Indirect hierarchical views for software application management - Google Patents
Indirect hierarchical views for software application management Download PDFInfo
- Publication number
- CA2201276C CA2201276C CA002201276A CA2201276A CA2201276C CA 2201276 C CA2201276 C CA 2201276C CA 002201276 A CA002201276 A CA 002201276A CA 2201276 A CA2201276 A CA 2201276A CA 2201276 C CA2201276 C CA 2201276C
- Authority
- CA
- Canada
- Prior art keywords
- source code
- hierarchy
- physical
- file
- files
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 238000000034 method Methods 0.000 claims abstract description 9
- 238000012986 modification Methods 0.000 claims abstract description 8
- 230000004048 modification Effects 0.000 claims abstract description 8
- 230000007246 mechanism Effects 0.000 claims description 7
- 238000012545 processing Methods 0.000 claims description 5
- 230000000007 visual effect Effects 0.000 description 3
- 230000009471 action Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 239000003086 colorant Substances 0.000 description 1
- 238000004040 coloring Methods 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000008569 process Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/16—File or folder operations, e.g. details of user interfaces specifically adapted to file systems
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99943—Generating database or data structure, e.g. via user interface
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99944—Object-oriented database structure
Abstract
The invention provides a technique for managing multiple contextual views of source code files. In a file system, different tasks demand that source code files be grouped in different hierarchical directories. When some or all of this manipulation is of the physical files themselves, the directories can become confused, and it may be difficult for the next user to access needed source code files.
In the technique of the invention, the physical location of the files is independent of all contextual views, and is maintained in a separate viewable hierarchy. All items in contextual view hierarchies contain only references to the physical location of the source code files, and so modifications of those items, such as delete, move and copy, only alter the references themselves. A separate set of operations can be used for explicitly maintaining or modifying the physical source code files.
In the technique of the invention, the physical location of the files is independent of all contextual views, and is maintained in a separate viewable hierarchy. All items in contextual view hierarchies contain only references to the physical location of the source code files, and so modifications of those items, such as delete, move and copy, only alter the references themselves. A separate set of operations can be used for explicitly maintaining or modifying the physical source code files.
Description
INDIRECT HIERARCHICAL VIEWS FOR SOFTWARE APPLICATION
MANAGEMENT
Field of the Invention The present invention is directed to information handling systems, and in particular, to a general use software management technique.
Background of the Invention Applications usually consist of a number of independent source files maintained in a file system.
Software developers can work with the source code contained in these in a number of ways. A
source code segment can be edited as part of a larger coding effort, and/or compiled into an executable or even into several different executables. Thus, a single source file can be used in several contexts, and any of these context can also be part of a body of multiple overlapping contexts.
However, the single source file physically exists in only one location.
When developing software, one of the first tasks of the developer or manager is often to determine the nature and location of the source file contents in the application being used. This is frequently done by using disk directories, on an ad hoc basis, as an organizational vehicle. Some common examples are directory structures to reflect project builds or makes, directory structures to reflect source version hierarchies, and project and department organizations.
fihe content of a request may require a change in the containment hierarchies of the directory structure. Therefore, a common approach is to initially organize the directories for the most frequently-used context, and devise dedicated software "tools" to copy or rearrange the directories to support the context required by other task demands, as they arise.
Some file systems provide mechanisms for creating "shadow objects" copies of the original source files, and hierarchies. These are then maintained as file system directories in the ordinary manner:
All of this leaves the structure of the source files and the directories in various states typically understood only by the user that organized it. Often this is simply the last requester.
As the complexity and/or size of a project grows, this problem becomes more of an exposure. Steps must be taken to correct it, but there is currently no known management system providing a flexible point of control, particularly over directory structures that have become standardized and unchangeable.
Summary of the Invention It is therefore an object of the present invention to provide a management system to separate the different hierarchical "views" of source code information taken by requests, from the physical location of the source code and from the limitations of the file system structure generally.
Accordingly, the present invention provides a mechanism and process for managing source code files in file directory hierarchies in a file data processing system. A first hierarchy with at least one branch containing objects representing the physical location of the source code files is created, as are additional hierarchies having branches representing contextual views of items from the source code files. The items are references to individual source code files.
Brief Description of the Drawing Embodiments of the invention will now be described in detail in association with the accompanying drawings in which:
Figure 1 is a simple multiple schematic view of file management;
Figure 2 is a hierarchy similar to Figure 1, of context and physical views, arranged according to the invention; and Figure 3 is a window view showing the hierarchical context and physical views, according to a preferred embodiment of the invention.
Detailed Description of the Preferred Embodiments User tasks or contexts can be described as a set of serial and/or parallel structure. In particular, a large number of contexts can be described by containment relationships.
Containment relationships map very cleanly to hierarchical tree views with the root, or a top node, being the highest parent container.
Figure 1 illustrates a schematic or tree view of a project 2 containing an edit session 4 and a build target or compilation unit 6. Each ofthese branches contains source files 8, 10 and 12 that are either being edited or compiled.
Source file B, generally designated as 10 appears twice, both under the edit session 4 and under the build target 6 branches. Depending on the nature of the user, this could mean that there are two copies of the file, or two references to a single copy. However, in the different contexts or branches of the tree, the meaning and use of the source in one context is different from, and frequently independent of, the other context.
Files are frequently copied in order to support different contexts or usage, and administration is put in place to manage the copying act. The hierarchical views group and manage the various contexts, so that a developer can discover, through inspecting the hierarchical views, that a file exists in different contexts.
Tools exist that support a presentation in which a file item in one context represents the real location of the file, while all other contextual representations of that file are merely references to its real location. Using the example set forth in Figure l, source files A 8 and B l0a could physically exist CA9-97-005 q.
together in a directory for the edit session 4, and the representation of source file B l Ob under the build target 6 would then indicate a reference to the physical location of the source file B in the directory tailored to the edit context. Using a visual tool, the fact that source file B 1 Ob under the build target 6 is a reference can be shown by colouring the line or node in the hierarchy in a contrasting colour, or with textual descriptive attributes of the line or target graphical node.
The value of hierarchies, then, is that they show objects in context and assist developers in managing the fact that an object may exist in many contexts. However, a main weakness of the hierarchies is that they are directly tied to physical locations. This means that administration is still required to deal with the physical location, with copying and with other functions associated with file system maintenance.
Tools currently in existence do permit some indirection in the views, but the views are still anchored in the physical locations. A useability issue that arises is that if colours are not used to differentiate between views of items representing actual physical locations and views of items representing references, it is never clear what a delete or update action means. That is, it is not clear whether deleting a view of an item will delete the physical source and thus all references to it, or merely a reference to a physical source file. The same concerns apply with respect to updating an original or a minor copy of it.
The solution provided by the present is to cut the tie between the view or context and the physical location of the objects. Two separate containments are created, a logical view for all contextual views, and a physical view. This means that every item or object in a context can only have an indirect fink to a physical location. All objects physically exist in only one location, and if a copy of an object is made, it is created as a new object.
This is illustrated schematically in Figure 2. In this tree view, in addition to the Project 14 hierarchy, there is an independent hierarchy called File Physical View 16. File Physical View 16 and the tree source files A 18, B 20 and C 22 it contains, represent the physical location of the directory containing the actual source files.
The hierarchy of views under Project 14 represent pieces of the information required in the different task context of the edit session 24 and build target 26. The items or source files 28, 30, 32 and 34 listed in each view contain only indirect references to the corresponding real file objects 18, 20 and 22. This is shown by the broken lines linking these items to their respective context view roots.
Thus, only a view becomes tailored to a particular context, rather than an underlying physical directory and location of the source file.
A single semantic can be applied to all visual references. For example, deletion or relocation of an item in a context view really modifies its reference to the physical location, rather than modifying the physical location of the actual source file.
The File Physical View 16 is constructed for explicit operations that deal with physical locations, such as copying and relocation.
The invention has been implemented in a tool builder framework having a metadata layering capacity to separate the information on logical views of the data in different contexts from the physical source code files. The aspects of this framework and metadata layering capacity are fully described in the following two concurrently filed, commonly assigned patent applications: Canadian application no. 2,201,279 entitled "An Object Oriented Framework Mechanism Providing Common Object Relationship and Context Management For Multiple Tools" and Canadian application no.
MANAGEMENT
Field of the Invention The present invention is directed to information handling systems, and in particular, to a general use software management technique.
Background of the Invention Applications usually consist of a number of independent source files maintained in a file system.
Software developers can work with the source code contained in these in a number of ways. A
source code segment can be edited as part of a larger coding effort, and/or compiled into an executable or even into several different executables. Thus, a single source file can be used in several contexts, and any of these context can also be part of a body of multiple overlapping contexts.
However, the single source file physically exists in only one location.
When developing software, one of the first tasks of the developer or manager is often to determine the nature and location of the source file contents in the application being used. This is frequently done by using disk directories, on an ad hoc basis, as an organizational vehicle. Some common examples are directory structures to reflect project builds or makes, directory structures to reflect source version hierarchies, and project and department organizations.
fihe content of a request may require a change in the containment hierarchies of the directory structure. Therefore, a common approach is to initially organize the directories for the most frequently-used context, and devise dedicated software "tools" to copy or rearrange the directories to support the context required by other task demands, as they arise.
Some file systems provide mechanisms for creating "shadow objects" copies of the original source files, and hierarchies. These are then maintained as file system directories in the ordinary manner:
All of this leaves the structure of the source files and the directories in various states typically understood only by the user that organized it. Often this is simply the last requester.
As the complexity and/or size of a project grows, this problem becomes more of an exposure. Steps must be taken to correct it, but there is currently no known management system providing a flexible point of control, particularly over directory structures that have become standardized and unchangeable.
Summary of the Invention It is therefore an object of the present invention to provide a management system to separate the different hierarchical "views" of source code information taken by requests, from the physical location of the source code and from the limitations of the file system structure generally.
Accordingly, the present invention provides a mechanism and process for managing source code files in file directory hierarchies in a file data processing system. A first hierarchy with at least one branch containing objects representing the physical location of the source code files is created, as are additional hierarchies having branches representing contextual views of items from the source code files. The items are references to individual source code files.
Brief Description of the Drawing Embodiments of the invention will now be described in detail in association with the accompanying drawings in which:
Figure 1 is a simple multiple schematic view of file management;
Figure 2 is a hierarchy similar to Figure 1, of context and physical views, arranged according to the invention; and Figure 3 is a window view showing the hierarchical context and physical views, according to a preferred embodiment of the invention.
Detailed Description of the Preferred Embodiments User tasks or contexts can be described as a set of serial and/or parallel structure. In particular, a large number of contexts can be described by containment relationships.
Containment relationships map very cleanly to hierarchical tree views with the root, or a top node, being the highest parent container.
Figure 1 illustrates a schematic or tree view of a project 2 containing an edit session 4 and a build target or compilation unit 6. Each ofthese branches contains source files 8, 10 and 12 that are either being edited or compiled.
Source file B, generally designated as 10 appears twice, both under the edit session 4 and under the build target 6 branches. Depending on the nature of the user, this could mean that there are two copies of the file, or two references to a single copy. However, in the different contexts or branches of the tree, the meaning and use of the source in one context is different from, and frequently independent of, the other context.
Files are frequently copied in order to support different contexts or usage, and administration is put in place to manage the copying act. The hierarchical views group and manage the various contexts, so that a developer can discover, through inspecting the hierarchical views, that a file exists in different contexts.
Tools exist that support a presentation in which a file item in one context represents the real location of the file, while all other contextual representations of that file are merely references to its real location. Using the example set forth in Figure l, source files A 8 and B l0a could physically exist CA9-97-005 q.
together in a directory for the edit session 4, and the representation of source file B l Ob under the build target 6 would then indicate a reference to the physical location of the source file B in the directory tailored to the edit context. Using a visual tool, the fact that source file B 1 Ob under the build target 6 is a reference can be shown by colouring the line or node in the hierarchy in a contrasting colour, or with textual descriptive attributes of the line or target graphical node.
The value of hierarchies, then, is that they show objects in context and assist developers in managing the fact that an object may exist in many contexts. However, a main weakness of the hierarchies is that they are directly tied to physical locations. This means that administration is still required to deal with the physical location, with copying and with other functions associated with file system maintenance.
Tools currently in existence do permit some indirection in the views, but the views are still anchored in the physical locations. A useability issue that arises is that if colours are not used to differentiate between views of items representing actual physical locations and views of items representing references, it is never clear what a delete or update action means. That is, it is not clear whether deleting a view of an item will delete the physical source and thus all references to it, or merely a reference to a physical source file. The same concerns apply with respect to updating an original or a minor copy of it.
The solution provided by the present is to cut the tie between the view or context and the physical location of the objects. Two separate containments are created, a logical view for all contextual views, and a physical view. This means that every item or object in a context can only have an indirect fink to a physical location. All objects physically exist in only one location, and if a copy of an object is made, it is created as a new object.
This is illustrated schematically in Figure 2. In this tree view, in addition to the Project 14 hierarchy, there is an independent hierarchy called File Physical View 16. File Physical View 16 and the tree source files A 18, B 20 and C 22 it contains, represent the physical location of the directory containing the actual source files.
The hierarchy of views under Project 14 represent pieces of the information required in the different task context of the edit session 24 and build target 26. The items or source files 28, 30, 32 and 34 listed in each view contain only indirect references to the corresponding real file objects 18, 20 and 22. This is shown by the broken lines linking these items to their respective context view roots.
Thus, only a view becomes tailored to a particular context, rather than an underlying physical directory and location of the source file.
A single semantic can be applied to all visual references. For example, deletion or relocation of an item in a context view really modifies its reference to the physical location, rather than modifying the physical location of the actual source file.
The File Physical View 16 is constructed for explicit operations that deal with physical locations, such as copying and relocation.
The invention has been implemented in a tool builder framework having a metadata layering capacity to separate the information on logical views of the data in different contexts from the physical source code files. The aspects of this framework and metadata layering capacity are fully described in the following two concurrently filed, commonly assigned patent applications: Canadian application no. 2,201,279 entitled "An Object Oriented Framework Mechanism Providing Common Object Relationship and Context Management For Multiple Tools" and Canadian application no.
2,201,278 entitled "Hierarchical Metadata Store For An Integrated Development Environment".
Figure 3 illustrates a window view of the software context management system according to a preferred implementation. In this window 36, Sessionl 38 is a visual representation of the hierarchy containing all of the physical source files with "car" data. These files include CarDatastore 40, CarManagerSequence 42, CarManager 44, CarManagerBase 46, Car 48 and CarDatald 50. A user can construct in a contextual Projectl directory 52, a compile unit in the form of a dynamic link library for a Car 54 containing specific attributes of the car data from the physical source files. The items in Car.dll 54 are references to the physical source code files.
Therefore, the logical item CarDatastore 56 is a reference to the actual file CarDatastore 40, CarManager 58 a reference to CarManager 44 and Car 60 a reference to Car 48. Preferably, the logical items are visually indicated, for example, by the use of contrasting colour.
Embodiments and modifications of the invention that would be obvious to a person skilled in the art are intended to be covered within the scope of the appended claims.
Figure 3 illustrates a window view of the software context management system according to a preferred implementation. In this window 36, Sessionl 38 is a visual representation of the hierarchy containing all of the physical source files with "car" data. These files include CarDatastore 40, CarManagerSequence 42, CarManager 44, CarManagerBase 46, Car 48 and CarDatald 50. A user can construct in a contextual Projectl directory 52, a compile unit in the form of a dynamic link library for a Car 54 containing specific attributes of the car data from the physical source files. The items in Car.dll 54 are references to the physical source code files.
Therefore, the logical item CarDatastore 56 is a reference to the actual file CarDatastore 40, CarManager 58 a reference to CarManager 44 and Car 60 a reference to Car 48. Preferably, the logical items are visually indicated, for example, by the use of contrasting colour.
Embodiments and modifications of the invention that would be obvious to a person skilled in the art are intended to be covered within the scope of the appended claims.
Claims (9)
1. In a file data processing system, a mechanism for managing source code files in file directory hierarchies, comprising:
a first hierarchy having at least one branch containing objects representing a physical location of the source code files; and at least one additional hierarchy having branches representing contextual views of items from the source code files, each said item being a reference to an individual source code file located in accordance with said first hierarchy.
a first hierarchy having at least one branch containing objects representing a physical location of the source code files; and at least one additional hierarchy having branches representing contextual views of items from the source code files, each said item being a reference to an individual source code file located in accordance with said first hierarchy.
2. A mechanism, according to claim 1, further comprising:
means for displaying said first hierarchy and said at least one additional hierarchy on a display associated with said file data processing system.
means for displaying said first hierarchy and said at least one additional hierarchy on a display associated with said file data processing system.
A mechanism, according to claim 2, wherein a user modification of an item displayed in one of said at least one additional hierarchies modifies the item's reference to an individual source code file, and a user modification of an object displayed in said first hierarchy modifies the object's physical source code file.
4. A mechanism, according to claim 3, wherein a user modification to copy a first object displayed in the first hierarchy creates a unique second object representing a physical copy of the first object's physical source code file.
5. In a file data processing system, a method for managing source code files in file directory hierarchies comprising:
maintaining a first hierarchy having at least one branch containing objects representing a physical location of the source code files; and creating at least one additional hierarchy having branches representing contextual views of items from the source code files, each said item being a reference to an individual source code file physically located in accordance with said first hierarchy.
maintaining a first hierarchy having at least one branch containing objects representing a physical location of the source code files; and creating at least one additional hierarchy having branches representing contextual views of items from the source code files, each said item being a reference to an individual source code file physically located in accordance with said first hierarchy.
6. A method, according to claim 5, further comprising:
displaying said first hierarchy and said at least one additional hierarchy on a display associated with the file data processing system.
displaying said first hierarchy and said at least one additional hierarchy on a display associated with the file data processing system.
7. A method, according to claim 6, further comprising:
modifying a descriptive attribute of a reference to an individual source code file in response to a user modification of an item containing the reference in an additional hierarchy on the display.
modifying a descriptive attribute of a reference to an individual source code file in response to a user modification of an item containing the reference in an additional hierarchy on the display.
8. A method, according to claim 6, further comprising:
modifying a physical source code file in response to a user modification of an object representing the physical source code file in the first hierarchy on the display.
modifying a physical source code file in response to a user modification of an object representing the physical source code file in the first hierarchy on the display.
9. A method, according to claim 8, wherein the user modification of the object is a copy function, further comprising:
creating a new object in the first hierarchy representing a physical copy made of a physical source code file.
creating a new object in the first hierarchy representing a physical copy made of a physical source code file.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002201276A CA2201276C (en) | 1997-03-27 | 1997-03-27 | Indirect hierarchical views for software application management |
| US08/956,415 US6098072A (en) | 1997-03-27 | 1997-10-23 | Source code files in a file directory system having multiple hierarchies representing contextual views |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002201276A CA2201276C (en) | 1997-03-27 | 1997-03-27 | Indirect hierarchical views for software application management |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2201276A1 CA2201276A1 (en) | 1998-09-27 |
| CA2201276C true CA2201276C (en) | 2000-01-25 |
Family
ID=4160287
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002201276A Expired - Fee Related CA2201276C (en) | 1997-03-27 | 1997-03-27 | Indirect hierarchical views for software application management |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6098072A (en) |
| CA (1) | CA2201276C (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7708643B2 (en) | 2001-03-09 | 2010-05-04 | Microsoft Corporation | Saving audio source identifiers for soundtracks in a gaming system |
| US7765401B2 (en) | 2001-03-09 | 2010-07-27 | Microsoft Corporation | Multiple user authentication for online console-based gaming |
| US7811174B2 (en) | 2001-03-09 | 2010-10-12 | Microsoft Corporation | Method and apparatus for managing data in a gaming system |
Families Citing this family (58)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6453334B1 (en) * | 1997-06-16 | 2002-09-17 | Streamtheory, Inc. | Method and apparatus to allow remotely located computer programs and/or data to be accessed on a local computer in a secure, time-limited manner, with persistent caching |
| US7024622B1 (en) * | 1997-11-26 | 2006-04-04 | Adobe Systems Incorporated | Keeping track of locations in electronic documents |
| US6466240B1 (en) * | 1998-07-08 | 2002-10-15 | Vadim Maslov | Method for visually writing programs or scripts that transform structured text presented as a tree |
| US6269377B1 (en) * | 1998-09-21 | 2001-07-31 | Microsoft Corporation | System and method for managing locations of software components via a source list |
| US6321229B1 (en) * | 1999-02-26 | 2001-11-20 | Hewlett-Packard Company | Method and apparatus for using an information model to organize an information repository into a hierarchy of information |
| US6345277B1 (en) * | 1999-02-26 | 2002-02-05 | Hewlett-Packard Company | Method and apparatus for using an information model to organize an information repository into an extensible hierarchy of information |
| US6343291B1 (en) * | 1999-02-26 | 2002-01-29 | Hewlett-Packard Company | Method and apparatus for using an information model to create a location tree in a hierarchy of information |
| US6314427B1 (en) * | 1999-02-26 | 2001-11-06 | Hewlett-Packard Company | Method and apparatus for using an information model to organize an information repository into an extensible hierarchy of organizational information |
| US6496842B1 (en) * | 1999-05-28 | 2002-12-17 | Survol Interactive Technologies | Navigating heirarchically organized information |
| US6691282B1 (en) * | 1999-06-22 | 2004-02-10 | Nortel Networks Limited | Method and apparatus for displaying and navigating containment hierarchies |
| US7007034B1 (en) | 2000-01-21 | 2006-02-28 | International Business Machines Corporation | File structure for storing content objects in a data repository |
| US7346844B1 (en) | 2000-01-21 | 2008-03-18 | International Business Machines, Corporation | Method and system for moving content in a content object stored in a data repository |
| US7043488B1 (en) | 2000-01-21 | 2006-05-09 | International Business Machines Corporation | Method and system for storing hierarchical content objects in a data repository |
| US7613993B1 (en) | 2000-01-21 | 2009-11-03 | International Business Machines Corporation | Prerequisite checking in a system for creating compilations of content |
| US8589777B1 (en) | 2000-01-21 | 2013-11-19 | International Business Machines Corporation | Method and system for calculating cost of a compilation of content |
| US7356766B1 (en) | 2000-01-21 | 2008-04-08 | International Business Machines Corp. | Method and system for adding content to a content object stored in a data repository |
| US7089239B1 (en) | 2000-01-21 | 2006-08-08 | International Business Machines Corporation | Method and system for preventing mutually exclusive content entities stored in a data repository to be included in the same compilation of content |
| US7340481B1 (en) | 2000-01-21 | 2008-03-04 | International Business Machines Corp. | Method and system for adding user-provided content to a content object stored in a data repository |
| US6986102B1 (en) | 2000-01-21 | 2006-01-10 | International Business Machines Corporation | Method and configurable model for storing hierarchical data in a non-hierarchical data repository |
| US7401097B1 (en) | 2000-01-21 | 2008-07-15 | International Business Machines Corporation | System and method for creating compilations of content |
| US6839701B1 (en) | 2000-01-21 | 2005-01-04 | International Business Machines | Hitmask for querying hierarchically related content entities |
| US7076494B1 (en) | 2000-01-21 | 2006-07-11 | International Business Machines Corporation | Providing a functional layer for facilitating creation and manipulation of compilations of content |
| US8831995B2 (en) | 2000-11-06 | 2014-09-09 | Numecent Holdings, Inc. | Optimized server for streamed applications |
| US7062567B2 (en) | 2000-11-06 | 2006-06-13 | Endeavors Technology, Inc. | Intelligent network streaming and execution system for conventionally coded applications |
| US20020069223A1 (en) * | 2000-11-17 | 2002-06-06 | Goodisman Aaron A. | Methods and systems to link data |
| US6785693B2 (en) | 2001-02-02 | 2004-08-31 | International Business Machines Corporation | Management of multiple links to a file in a file system |
| US6716102B2 (en) * | 2001-03-09 | 2004-04-06 | Microsoft Corporation | Method and apparatus for displaying information regarding stored data in a gaming system |
| US7194475B2 (en) * | 2001-10-30 | 2007-03-20 | International Business Machines Corporation | Method, system, and program for performing an impact analysis of program statements in at least one source code file |
| US7069547B2 (en) * | 2001-10-30 | 2006-06-27 | International Business Machines Corporation | Method, system, and program for utilizing impact analysis metadata of program statements in a development environment |
| US7428638B1 (en) | 2001-11-13 | 2008-09-23 | Microsoft Corporation | Architecture for manufacturing authenticatable gaming systems |
| US7203835B2 (en) | 2001-11-13 | 2007-04-10 | Microsoft Corporation | Architecture for manufacturing authenticatable gaming systems |
| US6931410B2 (en) | 2002-01-11 | 2005-08-16 | International Business Machines Corporation | Method, apparatus, and program for separate representations of file system locations from referring file systems |
| US7126712B2 (en) * | 2002-03-29 | 2006-10-24 | Kabushiki Kaisha Toshiba | File based request queue handler |
| CA2391717A1 (en) * | 2002-06-26 | 2003-12-26 | Ibm Canada Limited-Ibm Canada Limitee | Transferring data and storing metadata across a network |
| US20040267746A1 (en) * | 2003-06-26 | 2004-12-30 | Cezary Marcjan | User interface for controlling access to computer objects |
| US7472356B2 (en) * | 2004-02-11 | 2008-12-30 | Microsoft Corporation | Collapsible container with semi-collapsed view |
| US8261246B1 (en) * | 2004-09-07 | 2012-09-04 | Apple Inc. | Method and system for dynamically populating groups in a developer environment |
| US20060080288A1 (en) * | 2004-10-11 | 2006-04-13 | Microsoft Corporation | Interaction of static and dynamic data sets |
| US8024523B2 (en) | 2007-11-07 | 2011-09-20 | Endeavors Technologies, Inc. | Opportunistic block transmission with time constraints |
| US8732220B2 (en) * | 2005-06-15 | 2014-05-20 | International Business Machines Corporation | Virtualized file system |
| US7256736B2 (en) | 2005-08-11 | 2007-08-14 | International Business Machines Corporation | Location system with swept digital beacon |
| EP1762946A1 (en) * | 2005-09-09 | 2007-03-14 | Sap Ag | A method and a system for performing a multidimensional categorization of a document repository |
| US8099716B2 (en) * | 2005-11-28 | 2012-01-17 | Ubiquity Software Corporation Limited | Service structured application development architecture |
| US8065351B2 (en) * | 2006-02-23 | 2011-11-22 | Microsoft Corporation | Default location that may be dynamically changed |
| US20070234278A1 (en) * | 2006-03-02 | 2007-10-04 | Microsoft Corporation | Managing source code in a model-based development environment |
| US20070220481A1 (en) * | 2006-03-20 | 2007-09-20 | Microsoft Corporation | Limited source code regeneration based on model modification |
| US7577691B2 (en) * | 2006-08-02 | 2009-08-18 | Microsoft Corporation | Extending hierarchical synchronization scopes to non-hierarchical scenarios |
| GB2473396B (en) * | 2006-09-27 | 2011-04-20 | Yisia Young Suk Lee | A Data object management apparatus and method |
| US7966603B2 (en) * | 2006-10-27 | 2011-06-21 | Sap, Ag | Systems and methods for context-based content management |
| US7756821B2 (en) * | 2006-11-02 | 2010-07-13 | Microsoft Corporation | Virtual deletion in merged file system directories |
| US7877731B2 (en) * | 2007-02-12 | 2011-01-25 | Microsoft Corporation | Formatting and viewing source objects |
| US8892738B2 (en) | 2007-11-07 | 2014-11-18 | Numecent Holdings, Inc. | Deriving component statistics for a stream enabled application |
| US8140581B2 (en) * | 2008-05-15 | 2012-03-20 | Microsoft Corporation | Configurable view on data models |
| US8140593B2 (en) * | 2008-05-15 | 2012-03-20 | Microsoft Corporation | Data viewer management |
| US20130218933A1 (en) * | 2012-02-20 | 2013-08-22 | Microsoft Corporation | Consistent selective sub-hierarchical serialization and node mapping |
| US20130218930A1 (en) * | 2012-02-20 | 2013-08-22 | Microsoft Corporation | Xml file format optimized for efficient atomic access |
| CN105320504B (en) * | 2014-06-25 | 2018-08-17 | 成都普中软件有限公司 | A kind of visual software modeling method constructing software view based on software member view |
| CN113392068A (en) * | 2021-06-28 | 2021-09-14 | 上海商汤科技开发有限公司 | Data processing method, device and system |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5072412A (en) * | 1987-03-25 | 1991-12-10 | Xerox Corporation | User interface with multiple workspaces for sharing display system objects |
| US5388196A (en) * | 1990-09-07 | 1995-02-07 | Xerox Corporation | Hierarchical shared books with database |
| JPH04186447A (en) * | 1990-11-21 | 1992-07-03 | Canon Inc | Directory management system |
| US5187786A (en) * | 1991-04-05 | 1993-02-16 | Sun Microsystems, Inc. | Method for apparatus for implementing a class hierarchy of objects in a hierarchical file system |
| US5274803A (en) * | 1991-04-26 | 1993-12-28 | Sun Microsystems, Inc. | Method and apparatus for aligning a restored parent environment to its child environments with minimal data loss |
| WO1996018947A1 (en) * | 1994-12-13 | 1996-06-20 | Novell, Inc. | Method and apparatus to update or change a network directory |
| US5701137A (en) * | 1995-05-24 | 1997-12-23 | Microsoft Corporation | Method for separating a hierarchical tree control into one or more hierarchical child tree controls in a graphical user interface |
| US5706510A (en) * | 1996-03-15 | 1998-01-06 | Hewlett-Packard Company | Zymbolic history management system |
-
1997
- 1997-03-27 CA CA002201276A patent/CA2201276C/en not_active Expired - Fee Related
- 1997-10-23 US US08/956,415 patent/US6098072A/en not_active Expired - Fee Related
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7708643B2 (en) | 2001-03-09 | 2010-05-04 | Microsoft Corporation | Saving audio source identifiers for soundtracks in a gaming system |
| US7765401B2 (en) | 2001-03-09 | 2010-07-27 | Microsoft Corporation | Multiple user authentication for online console-based gaming |
| US7811174B2 (en) | 2001-03-09 | 2010-10-12 | Microsoft Corporation | Method and apparatus for managing data in a gaming system |
| US7818568B2 (en) | 2001-03-09 | 2010-10-19 | Microsoft Corporation | Multiple user authentication for online console-based gaming |
| US7846025B2 (en) | 2001-03-09 | 2010-12-07 | Microsoft Corporation | Method and apparatus for managing data in a gaming system |
Also Published As
| Publication number | Publication date |
|---|---|
| CA2201276A1 (en) | 1998-09-27 |
| US6098072A (en) | 2000-08-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2201276C (en) | Indirect hierarchical views for software application management | |
| KR100763323B1 (en) | A method and system for extending the file system api | |
| US5905990A (en) | File system viewpath mechanism | |
| US5551028A (en) | Design data management system and associated method | |
| US6105062A (en) | Method and system for pruning and grafting trees in a directory service | |
| US5504892A (en) | Extensible object-oriented file system | |
| US4809170A (en) | Computer device for aiding in the development of software system | |
| US5313646A (en) | Method and apparatus for translucent file system | |
| Meyrowitz | Intermedia: The architecture and construction of an object-oriented hypemedia system and applications framework | |
| US5668966A (en) | System and method for direct manipulation of search predicates using a graphical user interface | |
| US6055527A (en) | System, method and computer program product for superimposing attributes on hierarchically organized file systems | |
| USRE44652E1 (en) | Computer-readable data product for managing sales information | |
| CA2099911C (en) | Method and system for transactioning of modifications to a tree structured file | |
| US5771384A (en) | Method and system for replacement and extension of container interfaces | |
| US5557785A (en) | Object oriented multimedia information system using information and multiple classes to manage data having various structure and dedicated data managers | |
| US6003042A (en) | Systems, methods and computer programs products for storing a new version of an Envy Library file in a teamconnection object oriented programming environment | |
| JPH1173320A (en) | Method for developing framework and software system | |
| WO1996041283A9 (en) | System and method for superimposing attributes on hierarchically organized file systems | |
| Korn et al. | A new dimension for the Unix® file system | |
| US5062039A (en) | Sharing of workspaces in interactive processing using workspace name tables for linking of workspaces | |
| Reichenberger | VOODOO A Tool for orthogonal version management | |
| Garrett et al. | Graphics programming using a database system with dependency declarations | |
| WO1999033006A1 (en) | Evolution of object-relational mapping through source code merging | |
| WO1991017494A1 (en) | Dynamic information management computer system | |
| Hanson | A portable file directory system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |