Skip to main content

OCAP.persistent.root and OCAP.persistent.host, differences and similarities

4 replies [Last post]
david_crandall
Offline
Joined: 2010-01-05

I'm curious if OCAP.persistent.root and OCAP.persistent.host have the potential to overlap.

I ask because typically in usage I see OCAP.persistent.root used for applications where every application gets a /org_id/application_id. This makes sense because it keeps things very sandboxed.

OCAP.persistent.host, seems to create a host subdirectory in addition to the already specified host directory, and then write its files appropriately.

So it seems like one could get away with setting ocap.persistent.host and ocap.persistent.root to the same directory with no carnage. However, there may be a use case or two I'm not considering, or a case in the future I'm not considering.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
david_crandall
Offline
Joined: 2010-01-05
greg80303
Offline
Joined: 2008-07-03

I agree. The code that handles persisting Host values is not consistent with how we do things. Typically, each module that needs to persist data will define its own property (i.e. OCAP.persistent.host). If that property is not defined, the module has a hard-coded subdirectory name that it will append to the value of OCAP.persistent.root to determine the location.

A complete audit of all the stack modules that use persistent storage is in order. Can you please file a bug on this in IssueTracker?

Also, keep in mind -- the only directory that uses an org_id/application_id subdirectory naming convention is OCAP.persistent.dvbroot. This is the location specified by MHP which will define the Java system property "dvb.persistent.root" where applications can go to store their own files. This directory structure is mandated by MHP. All the rest of the locations defined by the OCAP.persistent.* properties are used by the stack implementation only and their format and directory structure is completely implementation-dependent.

G

david_crandall
Offline
Joined: 2010-01-05

I'll file that later this afternoon.

Thanks for the response! More than helpful.

Though, for my education here, I thought xlet applications were supposed to create a directory structure somewhat like:

[code]
mystring.append(System.getProperty("dvb.persistent.root"));
mystring.append(fileseparator);
mystring.append((String) ctx.getXletProperty("dvb.org.id"));
mystring.append(fileseparator);
mystring.append((String) ctx.getXletProperty("dvb.app.id"));
[/code]

I realize that it's more convention than anything, but the chance for inadvertently running into each other is still there, if one isn't paying close attention to permissions files vs. applications/stack storage. I guess, all the more reason for an audit.

greg80303
Offline
Joined: 2008-07-03

Actually, applications do not create those directories. MHP mandates that the implementation create those directories prior to launching the application.

And yes, it is possible for the various persistent storage directories to overlap, but it is up to the porting teams to ensure that the properties are defined so as to ensure that it does not happen.

The audit process will ensure that the various modules use the properties in a consistent fashion. It will also ensure that each property is correctly documented. These two things should give porting teams all the tools they need to make sure that their own directory structure is consistent.

G