Question about sandboxing

[Ruslan Zasukhin]

On 10/4/12 9:11 AM, "Frank Lemke" <frank at knowledgeminer.com> wrote:

>>> This is of course a problem for sandboxed apps since this direct creation of
>>> files outside the container is not allowed. That's why console reports the
>>> error message.
>>> 
>> Outside or inside?
> 
> outside the associated app container. The app container is the only place
> where a developer has unrestricted read/write access. Note that the app
> container is NOT equal to the app bundle, which normally is located in
> /Applications.

Aha, this is not the same as app.  package
 
Okay.

So you vote for ability to create journal file in this
    app container

Right?


>>> - (void)open:(NSString*)inPath
>>> pathInSandboxedAppContainer:(NSString*)containerPath;
>> 
>> This should be in our V4CC class VDatabase?
> 
> Yes, but I think there is, maybe, a better solution, see below.


>>> Using containerPath you can create and use the .journal file without
>>> problems.
>> 
>> Why you think so?
>> 
>> This path will come from where?  From YOUR objC code?
 
> In a sandboxed environment, YOU as the developer of the database engine ADK
> need to know where you can create your .journal file. Again, there is always
> one place, where this can be done, the app container or the sandbox. WE as the
> app developers (your customers) know where this app container is located,
> therefore, it could be provided with the open: pathInSandboxedAppContainer:
> message.

> Why should this not work, you get the path to the db file to open and the path
> where the .journal file can be created WITHOUT user interaction. Unless the db
> file and the .journal file MUST be in the same  directory this should work.

I SEE NOW, Frank, what you mean.

Ability to specify any other location for journal file of some DB...
And then its your deal provide here path to that special place.

Okay, this can work...


>  think you make a big mistake here. This is NOT a one-time issue. EVERY time a
> db file is opened and the db engine wants to create the .journal file a Save
> file dialog would have to be shown to ask the user where the .journal file
> should be saved. EVERY time. There is no mechanism that would let the user
> give general read/write permission to a certain folder or so for an app. Every
> time a file is going be read or saved outside the app container an Open/Save
> dialog appears... (or access is denied)

Actually there is such mechanism. Segrey have already implement it in our
Vstudio.  Exists something as BOOKMARK on place where user have point us, we
save this to disk, and next times we can use that without ask of user again
and again.


But this is really different story.

In Valentina Studio we do not want drop all possible db journals into single
sandbox folder, because we can easy get few dbs with same name and then
problem. For YOUR application, you will use most probably single db with
same name, so no problems here, and yes you can easy use sandbox folder.



========================
> Now the alternative idea:
> The location where an app's sandbox (container) will go is determined by OS X:
> 
> ~Library/Containers/<app identifier>  (see screenshot)
> 
> If you can call  [[NSBundle mainBundle] bundleIdentifier] in your engine you
> know the path where all .journal files can be created and used without
> explicitly asking for that path in a open:: message.
> For KnowledgeMiner, for example, the .journal file can go here:
> 
> ~Library/Containers/eu.knowledgeminer.KnowledgeMiner/

I see Frank.

So no need change API of V4CC.

I think first of all we can add this into V4CC.
Question yet is if we can define/differ mode of sandboxed app ?
Sergey?


May be later we will need similar step for REALbasic and Revolution, if they
allow do sandboxed apps also ... But lets at first resolve V4CC for Frank.


Frank, I think Sergey willl be busy yet 2-3 days on other tasks,
Then he can play with this idea ... Manwhile lets think more

========
So question is: if and how and if needed at all recognise mode that app runs
as sandboxed to use this trick. And NOT use it if ap is not sandboxed.

Another question. Still can be that somebody will want to use OUR way, when
user give permissions for some folders ONCE ... Then such developer will not
want do that

May be really better change API as was in first case ...
Then we have choices


-- 
Best regards,

Ruslan Zasukhin
VP Engineering and New Technology
Paradigma Software, Inc

Valentina - Joining Worlds of Information
http://www.paradigmasoft.com

[I feel the need: the need for speed]