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