RFC: Access Control over JavaScript Properties Globally and Per-Domain

Dawit A. adawit at kde.org
Mon Oct 14 15:41:31 BST 2002


On Monday 14 October 2002 06:35, David Faure wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sunday 13 October 2002 20:15, Leo Savernik wrote:
> > [...]
> > For example, an old KDE 3.0 setting like:
> > foo.bar.com::accept
> > will implicitely be treated as
> > foo.bar.com::accept:::::
> > and written back as such when the configuration is saved.
>
> Excellent thinking.

Hmm...  IMHO it would it be much easier and scalable, interms of adding 
properties in the future, to take the same approach as was done with the 
io-slave config files. We used to have a very similar config file structure 
for cookies and user agent configuration, but it became a PITA to update the 
existing config files to a new format.

For those the benefit of Leo and those that might not be aware (I know David 
knows this ;)), an example of the current format would be something like:

[foo.bar.com]
javascript.policy=smart
javascript.WindowOpenPolicy=false
javascript.WindowMovePolicy=true
javascript.WindowResizePolicy=true
javascript.WindowFocusPolicy=false
javascript.WindowStatusPolicy=true

I appended the "javascript." for namespace sake because I do not know where 
this configuration is going to be stored.  You can write the default settings 
in another group of the <default> group (i.e. without one).  The advantages 
of doing this are:

1.) No special parsing code needed.  Use KConfig to obtain the settings.  Your 
code will only have to check if a specific host name entry exists and use the 
settings there.  If there is no entry for a specific property under the group 
or there is no domain specific entry at all, use the global/default setting.

2.) No position dependency.  One does not have to worry about where a speicifc 
entry belongs which makes it much easier to read and hence administer 
manually.

3.) Can easily be converted/manipulated into a new format without loosing the 
user's settings in the future using kconf_update tool.

4.) Easier to extend than the other format because properties can be added 
without having to worry about positions etc...

Just my $0.02 worth.

Regards,
Dawit A.




More information about the kfm-devel mailing list