Developers of Sympa

[David Verdin <address@concealed>]

Hi Marc,

Le 20/03/14 18:54, Marc Chantreux a écrit :

hello, 

On Thu, Mar 20, 2014 at 05:58:19PM +0100, David Verdin wrote:

I become depressed thinking that we must maintain current parser
of Conf and List modules in the future.

I must agree with Soji.   

i wasn't disagreed.

Sorry, I misunderstood. I read too quickly sometimes. ;-)

param1
    subparam1
        sub-subparam1 value   

i know it's weird but 

param1/subparam1/sub-subparam:1 value    
param1/subparam1/sub-subparam:2 value 

is a valid solution. simple to edit and parse even un shell …

Yes, I thought about it, but as you need to repeat param names, it is more error-prone and, if you mistype a parameter, you must change its name as many times as you mistyped it.
I'd like to keep the plain old good principle that works so well in relational databses: an information should be uniquely declared.

on the other hand: as sympa is a web-app, shouldn't we prefer JSON?

Also good as a config format. But please note:
- Sympa is not likely to have to transfer its config to another web app. Only data (groups, subscription and such). The same is valid for incoming data: other apps won't transfer config elements, only data. So the web app aspect in not discriminant for the configuration formalism choice.
- Sympa is not only a web app. It is, at its core, a message broadcasting system which for now mainly use mail.

what about s-exprs? easy to parse, read and edit (and we should have a
line based serializer):  

(param1
    (subparam11
        (sub-subparam1 value))) 

s-expressions have the very good point to be extremely flexible and likely to express anything. So why not?

we can also store them in a sqlite, a key/value store, an XML file, let an 
external django-rest webapp.

And all of those have pro and cons (even xml which can be validated with
a schema).

At the very important difference that XML is not humanly manipulable easily. There is no good free XML editor (one that can do autocompletion while typing, based on the schema, for example).
As you mentionned, it can be validated against a schema, which proves it is a very good language for automatic processing. But is is very painful for human edition. I see it on a daily basis with Shibboleth.

so i propose to not chooose for the administrators. Instead: 

* provide documented specs
* provide YAML  formated examples as spec tests
* let administrators the ability to choose/maintain their modules that
  serialize/deserialize datastructures that could complies the spec and
  use them at their own risks.

so the community would be free ot discuss/implement new things.

Ah...
I will basically disagree with you but don't get me wrong: I like the idea to let administrators have choices. But configuration formalism is not the space where I want to let them choices. I want to give them expressivity and freedom in the core Sympa functionnalities: List configuration, communication with other applications, message broadcasting, list creation industrialisation, functionnality cusomization, etc.
And while doing this, I want them to be able to share their experience with other administrators.

For this, we need a common language: If a user experienced in, say XML, wants to share a receipe or help another debug, it will do it by providineg XML examples. If other users are used to JSON configuration, that forces them to understand another formalism before trying to understand how the receipe works.

Remember that most listmasters have not Sympa as their mùain occupation. This is rather a side task that, most of the time, they have very few time to invest in. Giving them several config formalism will only add to their confusion.

That's the kind of situation that makes me prefer having only one configuration formalism in Sympa. The exaxt formalism, though remain open until we start working on 7.1. Except for XML. We will switch to XML over my dead body. ;)

Cheers,

David

regards,

--
A bug in Sympa? Quick! To the bug tracker!

David Verdin Études et projets applicatifs
Tél : +33 2 23 23 69 71 Fax : +33 2 23 23 71 21   www.renater.fr	RENATER 263 Avenue du Gal Leclerc 35042 Rennes Cedex

Attachment: smime.p7s
Description: Signature cryptographique S/MIME