KR100425681B1 - Apparatus and method for carrying out api of dsm-cc based device - Google Patents

Abstract

The present invention relates to an APIA implementation device and a method of a DSM-CC-based device, and analyzes a path name string received from an application task, and analyzes the path name length, directory, and file name in a string format. A parser for storing as; A resolver that finds the same directory or file name as that parsed by the parser among the directories and file names in the sub-list of the directory currently being resolved, and receives a location where the actual object is stored in the module manager; A module manager for searching for and transferring a required object from a module list cache in which a DSM-CC object is stored, based on the location information indicated by the resolver; When an exception occurs such that no object exists during the operation of the resolver, the exception processing unit is configured to handle exceptions, and file data transfer between the "Application" task and the "DSM-CC API" task is performed at once. By shortening the speed, it increases the speed of operation and reduces the memory usage and the load on the system.

Description

APPARATUS AND METHOD FOR CARRYING OUT API OF DSM-CC BASED DEVICE}

The present invention relates to a DSM-CC application programming interface (API) used for receiving data from a DSM-CC (Data Storage Media Command Control) -based device such as a digital TV. The present invention relates to an API implementation apparatus and method of a DSM-CC based device.

Recently, the transition from the existing analog TVs to digital TVs in the United States, Japan, and the United Kingdom has been made.

Digital TVs provide high quality video and audio based on the digitization of signals, and in addition, various data services such as news, TV program guide, weather, and games are available.

To provide such data services, digital TVs use the Data Storage Media Command Control (DSM-CC) protocol.

This protocol (DSM-CC) is based on CORBA, regardless of platform, and uses the same API (Application Programming Interface) to transmit data by broadcasting using local, network, even terrestrial or satellite. It also features that it allows users to access using the same API.

Here, DSM-CC (Digital Storage Media-Command and Control) is a protocol that defines the control functions and functions for handling MPEG-1 and MPEG-2 bit streams, and is a general application, Multimedia and Hypermedia Information coding Expert Group) Allows applications and script applications to access streams and data.

Next, an application programming interface (API) is a set of rules that make certain data generated by different applications available to one application. The representative standards include OLE, CORBA, and Plug-in.

At present, data broadcasting using the protocol (DSM-CC) has already been carried out in Europe, and using Java as well as files used in applications such as the MHEG engine implemented on TV. A service that sends the application itself is also in preparation.

1 is an exemplary view showing an interface between a conventional "DSM-CC API" task and an "Application" task.

As shown in this figure, in order to obtain a file object represented by a path name of "DSM: //Dir1/a.mhg", a service represented by "DSM: //" using "GetName () API" is first used. Obtain a gateway (Service Gateway) object (pSRG) (S11).

Here, "DSM: //" is a kind of root directory based on DSM-CC, such as "C: //" or "D: //" in a DOS environment, and the sub It will be a directory.

Next, after analyzing the path name to obtain the name of the directory object "Dir1" (S12), the directory corresponding to "Dir1" using the "resolve () API" of the service gateway from the name. The object pDir1 is obtained (S13).

Next, the path name is analyzed in the same manner to obtain the name of the file object "a.mhg" (S14), and from that name, the "resolve () API" of the directory corresponds to "a.mhg". Obtain a file object (pFile) (S15),

Next, the content (pContent) of the actual file is obtained using the "_get_Content () API" of the file (S16), and the content (pContent) is displayed through internal processing (S17).

2 is a block diagram showing the configuration of a conventional "DSM-CC API".

As shown therein, the resolver 2 finds the same directory or file name as requested by the "Application" 1 and requests the module manager 3 to receive the location where the actual object is stored. .

The module manager (3) is based on the location information pointed to by the resolver (1), the object needed by the resolver (2) in the object list cache (4) that stores several objects To pass.

The object list cache 4 is a means for storing the DSM-CC object.

Next, FIG. 3 is a flowchart illustrating an operation of the resolver 2 in FIG.

As shown therein, the resolver 2 receives a directory object (pDir) requested by the 'Application' and a path name (Path) corresponding to the sub-object thereof and performs initialization to process it (S21).

In this case, the path name is not a multipath separated by '/', but a path to a single object in the directory.

Next, an IOR (Inter-Operable Reference: location of an actual module to which a path is delivered) of the corresponding path is searched (S22).

Accordingly, the actual module is searched from the searched IOR (S24).

Here, the module is a kind of data packet transmitted to the "DSM-CC API" through a certain path (in the case of digital TV, broadcast propagation), and is composed of one or several objects and is received at a hardware dependent level. , Are combined.

Next, the object to be searched is searched based on the IOR among the actual modules (S26).

As a result, if there is an object, the object is returned to 'Application' (S28), and if there is no object, "null" is returned (S29).

Of course, if the search result of the IOR or module does not come out during the IOR search or the module search process (S23, S25), it also returns a "null" value (S29).

However, the above structure reduces the processing speed since data must be transmitted several times between two tasks (DSM-CC API, Application) whenever "Application" performs a number of tasks that need to be performed using actual files. do.

In addition, since the code corresponding to various APIs must be written, the code size is increased, and since a number of objects such as directories and files must be created, the amount of memory required is increased.

Accordingly, the present invention has been created to solve the above-mentioned conventional problems, and the file data transfer between the "Application" task and the "DSM-CC API" task in the "DSM-CC" based device and the "Application" is short. Reduced to one time, increases the operation speed, reduces the memory usage and the load on the system, and design efficiency by applying to "DSM-CC" based devices and applications, such as the digital TV MHEG engine And an apparatus and method for implementing APIs of a DSM-CC based device for improving operation performance.

1 is an exemplary view showing an interface between a conventional "DSM-CC API" task and an "Application" task.

Figure 2 is a block diagram showing the configuration of a conventional 'DSM-CC API'.

3 is a flowchart illustrating an operation of a resolver in FIG. 2.

4 is an exemplary view showing an interface between an "Applicaton" and a "DSM-CC API" task when using the "DSM-CC API" according to the present invention.

5 is a functional block diagram for implementing the "DSM-CC API" according to the present invention.

FIG. 6 is a flowchart showing the operation of the fuser in the configuration of FIG. 5; FIG.

7 is a flowchart showing the operation of the resolver in the configuration of FIG.

FIG. 8 is a flowchart showing an operation of an exception processing unit in the configuration of FIG. 5. FIG.

*** Explanation of symbols for the main parts of the drawing ***

10: parser 20: resolver

30: exception handling unit

The present invention for achieving the above object, the parser for analyzing the path name string (String) received from the Application task, and stores the length (Depth) and directory, file name of the path name in the form of a string; A resolver that finds the same directory or file name as that parsed by the parser among the directories and file names in the sub-list of the directory currently being resolved, and receives a location where the actual object is stored in the module manager; A module manager for searching for and transferring a required object from a module list cache in which a DSM-CC object is stored, based on the location information indicated by the resolver; When an exception occurs, such as an object does not exist during the operation of the resolver, it is characterized by comprising an exception processing unit in charge of exception processing.

Hereinafter, an embodiment according to the present invention will be described in detail with reference to the accompanying drawings.

First, Figure 4 is an exemplary view showing the interface between the "Applicaton" task and the "DSM-CC API" task when using the "DSM-CC API" according to the present invention.

As shown in this figure, the "Applicaton" task passes a string represented by "FilePath" to the "DSM-CC API" task, and in the "DSM-CC API" task, the conventional "GetName" as shown in FIG. () "," resolve () "," _get_Content () "Iteratively repeats the operations in itself, and delivers the final result of the file object (pFile) to the" Application "task.

As a result, only one interface transfer is performed between two tasks (DSM-CC API, Application), thereby improving processing speed and eliminating the need to create various objects such as code, directories, and files corresponding to various APIs. This reduces the amount of memory required.

Then, a method for only one data transmission between two tasks (DSM-CC API, Application) as described above will be described with reference to FIGS.

5 is a functional block diagram for implementing the "DSM-CC API" according to the present invention.

Here, "Application" 1 represents an arbitrary task using "DSM-CC API" such as MHEG, and Parser 10 analyzes the path name string received from the "Application" task. The counter stores how long the path name depth is, and stores each directory and file name in string format.

Next, the resolver 20 performs a function of the "resolve () API". Among the directories and file names in the sub-list of the directory currently being resolved, the resolver 20 or the directory analyzed by the parser 10 It finds the same name as the file name and requests the module manager 3 to receive the location where the actual object is stored.

Next, the module manager 3 determines the resolver 20 in the module list cache 4 in which several DSM-CC objects are stored, based on the location information indicated by the resolver 20. Pass in the object that is needed.

Next, the object list cache 4 serves to store the DSM-CC object, and the exception handler 30 exceptions such that no object exists during the operation of the resolver 20. It takes care of exception handling when a situation occurs.

For example, when a file corresponding to a path name of "DSM: // Dir1 / Dir2 / File" is requested by the "Application" task, the operation of the "DSM-CC API" according to the present invention will be described.

First, the "Application" task passes the path name ("DSM: // Dir1 / Dir2 / File1") of the required object to the "DSM-CC API" as a string.

Then, the parser 10 analyzes the string and stores how long the length of the path name Depth is in a counter (not shown), and stores each directory Dir1 and Dir2 and the file name File1 in a string format.

In this case, 3 is stored in the counter, and "Dir1", "Dir2", and "File1" are stored separately as strings.

Next, the resolver 20 requests the module manager 3 for a service gateway corresponding to the root directory of the general file system. This corresponds to "GetName () API" of "DSM-CC API".

Accordingly, the module manager 3 finds an object corresponding to the service gateway from the module list stored in the object storage unit 4 and delivers the object to the resolver 20.

Then, the resolver 20 searches the binding list of the service gateway (Binding List: a list of subdirectories or file names with their actual locations), and finds the actual location of the binding with the name "Dir1" in order. Request the object by passing the location to the module manager (3).

Accordingly, the module manager 3 finds an object corresponding to "Dir1" in the object storage unit 4 and delivers the object to the resolver 20.

In the same way, if the object corresponding to the directory ("Dir2") and the file ("File1") is found, and the object corresponding to the file ("File1") is found, the resolver 20 reads the contents of the file object as "Application". (1) to pass.

However, when there is no matching binding or no object exists at the actual location during the operation, the corresponding information is transmitted to the exception processing unit 30, and accordingly the exception processing unit 30 receives an error for each case. Pass the code to "Application" (1).

At this time, the module manager 3 and the object storage unit 4 are not significantly different from the conventional operation in their functions.

Therefore, in the present invention, the operation of a newly added or expanded function block will be described in more detail with reference to FIGS. 6 to 8.

First, Figure 6 is a flow chart of the operation of the parser 10 according to the present invention, after the initialization process is completed (S31), from the path name (full path name separated by '/') received in the "Application" task (S32) " Analyzes each path separated by '/' using strstr () "function (S33).

Next, the string up to the separated position is separated using the "Strcpy ()" function and stored in a separate path name (S35).

Next, the counter is incremented (S36) and the path name separated by '/' is searched again (S33).

This process is repeated until the return value of the "strstr ()" function is "null" (S34). If the return value is "null", the end of the path name is indicated, so the final path name is saved and terminated (S37). , S38).

At this time, it is obvious that the function used to perform the operation may have a different name depending on the user or the system while the basic operation is the same.

Next, FIG. 7 is an operation flowchart of the resolver 20 according to the present invention. First, an object pSRG is initialized with a service gateway (root directory) obtained by calling the "GetName () API", and the remaining variables are initialized to "null". (S41).

Next, the first path name obtained from the parser 10 is taken and the position of the object is searched in the same manner as the existing resolver (S42, S44, S49).

When the search is completed through the above process, the counter (not shown) designated by the variable "i" is increased (S51), the service gateway searches for the stored object (pDir), changes the result to the object, and changes the next path name to the parser (10). ) And start the next search.

Accordingly, when the counter is equal to the value of "Path_Count" of the parser 10 (S52), the "_get_Content () API" is called from the final object pObj to obtain the actual content of the object and deliver it to the "Application" task. (S53).

On the other hand, if an exception occurs during the process (Resolve) (S43, S46, S49), the corresponding error code (Error_Code) is set to the corresponding exception value, and then delivered to the exception handler (Exception Handler) 30 ( S45, S47, S50).

Next, FIG. 8 is an operation flowchart of the exception processing unit 30 according to the present invention. First, the exception processing unit initializes an error code (S61), and when an error code is transmitted from the resolver 20 according to this value. Various processing is necessary (S62).

That is, when the error code means no object (Error_Code = No_Object), the path of the object exists but the actual object content does not exist, and the error code is transmitted to the "Application" task ( S64).

Next, when the error code means that the path is wrong (Error_Code = InvalidName), the path of the corresponding object is not found and the object is not found. Therefore, the error code is transmitted to the "Application" task (S65).

Next, when the error code means that the object is not received (Error_Code = Not_yet_Dnld), the object exists, but the reception is not yet completed at the hardware level (S66), in this case, the error code may be passed but "Application" For the convenience of designing the task, after the object is received (S67), it is processed again (resolved) and delivered to the "Application" task (S68).

Of course, the above-described operation of the exception processing unit is only an embodiment, and exception handling may be implemented in other manners appropriate to the requirements of the system.

As described above, the AP-implementation apparatus and method of the DSM-C based apparatus of the present invention shortens the file data transfer between the "Application" task and the "DSM-CC API" task to be performed only once, thereby speeding up the operation. Increase the memory usage and reduce the memory usage and load on the system.

In addition, the present invention is effective to improve the efficiency and operation performance of the design by applying to the "DSM-CC" -based device and "Application", such as MHEG engine of the digital TV.

Claims (7)

A parser for analyzing a path name string received from an application task and storing a path name length, a directory, and a file name in a string format; A resolver that finds the same directory or file name as that parsed by the parser among the directories and file names in the sub-list of the directory currently being resolved, and receives a location where the actual object is stored in the module manager; A module manager for searching for and transferring a required object from a module list cache in which a DSM-CC object is stored, based on the location information indicated by the resolver; Appearance device of the SM-C based device, characterized in that configured to include an exception handling unit for handling exceptions when an exception occurs such that the object does not exist during the operation of the resolver. The DSM-CC API, which receives the path name of the object required from the application task in the form of a string, analyzes the string and stores the path name length, directory, and file name in a string format. A first step of doing; A second step of finding a directory and a file name of a directory and a file name in a lower list of a directory currently being resolved, the same as the directory or file name analyzed in the first step, and receiving a location where the actual object is stored from the module manager; And a third step of searching for the actual object required from the object storage unit based on the position information obtained in the second step. The method of claim 2, wherein the second step searches the binding list of the service gateway (list enclosing the actual location with the subdirectory or file name) and finds the actual location of the binding having the name of the directory or file in order. Appearance method of the APM of the SM-C based device, characterized in that to find the required object based on the location to pass to the application task. The application task according to claim 2 or 3, wherein when an exception occurs such that a matching binding does not exist or an object does not exist in a real position during the operation of the second step, an error code corresponding to each case is applied. The method of implementation of APM of the SM-C based device, characterized in that it further comprises a transfer to. The method of claim 2, wherein the first step comprises: a first step of finding each string separated by '/' from the full path name received by the application task; In the first process, an API of the SM-C based device comprising a second process of separating a string up to a location separated by '/' and sequentially storing the final path name in an individual path name. How to implement. The method of claim 4, wherein the exception occurs during the resolve operation when the path of the object exists but the contents of the actual object do not exist, or when the object is not found because the path of the object is incorrect. And a corresponding error code is returned to the application task. The method of claim 4, wherein, when the object is present but the reception is not completed at the hardware level, the exception occurs during the resolve operation. After waiting for the reception of the object to be completed and resolving it again, A method for implementing APM of a SM-C based device, characterized in that it is configured to return to an application task.