[SM-DEVEL] Fwd: [SM-PLUGINS] [GSoC] Plans for the new configuration and preference system.

[Paul L. <pa...@sq...>]

Keeping conversation on-list.

---------- Forwarded message ----------
From: Antoine Delignat-Lavaud <an...@de...>
Date: Jul 8, 2007 6:14 PM
Subject: Re: [SM-DEVEL] [SM-PLUGINS] [GSoC] Plans for the new
configuration and preference system.
To: Paul Lesniewski <pa...@sq...>


Paul Lesniewski wrote :
> Currently, there is one working example of exactly this: the
> default_advanced skin has a preview pane, and thus some display
> options that determine how it works.  Those options should, of course,
> only be shown when the default_advanced skin is in use.  The way this
> is achieved is that the template enables a plugin -- and that plugin
> is what adds the options to the display prefs page (note no patch
> needed as usual).
>
> I'm not sure we want to add too much more actual functional
> programming to the templates, so to me, this is sufficient, but other
> ideas are always welcome.  I'm curious if the SMConf design intends to
> change this or supplant it in some other way?
>
Maybe dependencies support is an option, or possibly a general support
for any number of meta-informations to rely on.
A possible solution in this case would be to use a template
configuration file, just like any plugin would do.
>> Yes, this is the spirit of the whole system. Each variable can have
>> three meta-informations : a type, a description and any number of sections.
>>
>
> I think we will soon see that there has to be more than just those
> three meta infos.  :-)
>
I have a feeling you're right about that.
> When you say "any number of sections", you mean an option could be
> displayed in more than one place in the interface?  Isn't that
> confusing?
>
It can be useful, e.g to define sections with special behaviors (a
hidden section for hidden variables, a protected section for read-only /
protected variables).
> But you are referring here to the "configurator".  I think Daniel was
> asking about user prefs options in the main interface (and how skin
> authors will control them (or not)).  Are you suggesting that this
> very same system will entirely replace the SM options system that we
> use now?
It's more the option system that will be extended to support script
configuration as well in fact.
> So wait, you are planning to allow the configurator to be templated?
> I don't see that as a bad thing (and why not - the SM template system
> should plug right in to what you need), but let's be really clear that
> the configurator is an entirely different monster than the SM
> interface (and its options/prefs pages) itself.  I'm not sure the
> configurator really *needs* to have multiple skins - it's just a
> configuration tool, not a user-facing tool, and as such, I'm not sure
> it needs to be part of the SM template sets (skins).
>
Since the user preference system is templated, I don't see wht the
script configuration page wouldn't be, both relying on the same base.
> What is this syntax?  This is the first I have seen this.  Is this a
> set of default values?  I think I need a re-summarization of meta
> configuration files.
>
I have in mind the syntax currently used for user preferences (.pref
files), but with sections.
Default values will probably be stored in a default_config file and
overriden by settings in the config file (just like the current
configuration system).
It's always a good thing to be able to restore default values when
things go wrong.
> Are you also implying here that you do in fact intend to use the same
> system for the SM prefs/options pages as for the configurator?  If
> that's the case, are you sure  you are covering all the
> functionalities that are there now?
No, at least not yet, but eventually.

>
> However, the SM config file being PHP has provided a great deal of
> flexibility to unique situations over the years.  Killing that off
> WILL have implications, and the least we can do is make sure there are
> sufficient ways to achieve the same kind of flexibility.  But I have
> not actually seen what the intended format is for configuration and
> prefs value storage...?
>
>
As I said, a syntax similar to the current .pref files, so probably no
PHP inside. Still, I don't see why you're worrying so much because of
that. Using PHP code in a configuration file doesn't sound clean to me,
as it doesn't belong here but to other parts of the script, such as the
init script. If you're thinking arrays will no longer be supported,
you're wrong - they'd just have to be serialized, but it is already the
case in .pref files currently.
> Patching the core has very different implications than changing a line
> in the config file.  I don't think the two should be compared like
> that.
>
You could always make up for that by creating some sort of autostart.php
script included at the configuration stage, but a plugin sounds fine too.
>
> How this API works has not been explained enough to understand yet,
>
Rather how it /will /work, since we're trying to define / refine its
behavior right now.
> but this looks a lot less dynamic than what I had pictured -- where
> SMConf takes a request for some variable and gets it from the right
> backend as needed.  This example makes it sound more like you are
> placing the onus of where config values come from on the caller, which
> seems counter-intuitive to me.
>
The source and backend are not provided by the caller, naturally.
However, it is yet to be decided how they can be configured.

Nightly Regards,
Antoine