Skip to Content.
Sympa Menu

devel - Re: [sympa-developpers] Where i'm going (Jun '18 - Jan '19)

Subject: Developers of Sympa

List archive

Chronological Thread  
  • From: David Verdin <address@concealed>
  • To: address@concealed
  • Subject: Re: [sympa-developpers] Where i'm going (Jun '18 - Jan '19)
  • Date: Thu, 31 Jan 2019 11:00:36 +0100

Hey Soji!

On 31/01/2019 10:48, IKEDA Soji wrote:

Something that, in my opinion, is still missing, is the keeping of the
original request context. the only example I have about it the following:

When a subscription is moderated, once the subscription is validated,
the action translates from "subscribe" to "add" and is therefore based
on the "add" scenario. As it is not an addition, but the acceptance of a
subscription, it shold not use "add" scenario.
I feel you look a bit confused.

It happens only in the case that "subscribe" scenario returns the
result "owner". It means that owner must validate addition, and when
owner validates request, "add" scenario checks owner's privileges.

No, I understood that. But I don't see why the "add" scenario is evaluated.

"add" is used to allow people to add new subscribers without a subscription request.

Therefore the scenaroi can allow anybody to do it, not necessarily the owners.

In some weird situation, you could prevent owners from adding addresses and let only another group do it. Will subscription moderation still work in this case?



I strongly agree with Soji's approach of making the different interfaces
some request containers. We want to do this for a long time, so it's
great we are closing to this goal! This is the only problem I met with
this. And it was in 6.2.32. And it might be fixed in the meantime.

There are some issues:

- Implementation on delayed requests.

With web interface, bulk approval of requests (such as
DISTRIBUTE, SUBSCRIBE) can take long time and might cause
browser timeout.

One solution is to add a new spool to keep requests already
approved (not requests to be approved -- it is there), and
maybe another daemon process simultaneously flushes them.
I'm not sure this solution is the best.
I think it's probably the best solution. If I recall correctly, we
already use it for validated messages which are stored in a specific
spool. So the problem remains only for subscription.

The only problem I  could see with that is the delay: on the web
interface, when we display a message stating that an action has been
executed, people expect it to be finished.

Maybe a simple warning telling "if you requested to add a lot of users,
it can take a fw minutes to complete. Please be patient.é
As I wrote above, the case of subscription does not matter:
It is appropriately authorized by "subscribe" scenario.

Then, at last the owner validates requests (being authorized by "add"
scenario), additions are actually performed --- and they will cause delay.
Yes, delay does matter.

Furthermore, validated requests have to know context of validation
(by whom and how validated) to report result to owners. That is,
new spool (if applicable) should keep that contexts along with
requests. I worry if it's a bit complex.

I think you misunderstood me; I was not talking about scenarios anymore. I was elaborating about your idea for asynchronous requests.



- On web interface (described in below).

- Refactoring datasources. I want to start it in the end of this
year and probably may be done in the first half of next year.
The goal is to define simple interface between datasource and
GUI (vue and so on).
I started working on this point (with delay of a year).
A PR is submitted (See PR #516 https://git.io/fhOfR ), and I wish it
being closed before the next stable in March.

In the next step, I hope we will be able to start thinking about new
GUI.
I have't looked it it yet. I'll comment later.

- Refactoring task manager and task spool. It will be done in the
next year.
The purpose is to rewrite fossilized code.
It has basically been done. See PR #394 https://git.io/fNbVH .
Not looked at it either, but it certainly needed.
- OO-based robots and configuration mechanism.
It would be better to be done on separate branch and be merged
into Sympa 7.
It has not been done.
And it's very big work, which probably implies to change the
configuration language.


### The other refactorings

I think code for these things should be refactored:

- Scenarios

- Families

Progress about these will be reported after more half year, around
June.
Please note that Marc is currently working on a refactored code for
scenarios, which has the added value of making the scenarios easily
extensible.

He does this on a private repository of his, as you asked. He will
present it when he feels it is good.
I've already started work on scenarios. As I'm planning to merge
it in the next stable, I'll submit PR in Feb.

Cool. We'll see how Marc's work can fit in it.


regards !


David



### About web interface

Web interface has several problems, such as:

- Configuration editor.

Functions to edit configuration (templates, scenarios, ...)
looks not suit for requiest framework described above. However,
they are generally poor. It would be better to be reconstructed.

- Web interface itself.

It is a chunk of older codes, and on the whole a reinventing of
the web application framework.
As an excuse: it was written a long time ago, before the frameworks exist.
Moreover it obviously has several problems giving raise to
security risk (Note that all of CVE reports on Sympa in the past
were related to web interface).

IMO we were happy if we could throw older codes away and start
implementing the new thing just now. At least latter can be done.

I personally don't want to improve current web interface, but
only will close flaws and bugs (Of course I won't disturb the
others adding new features to it).
I think Racke woud be great at this task!

However, it is rather large, so it must be hndled carefully.

*

That's all on my last half year. Comments and suggestions are
very appreciated.
You did a great work, setting aside my disagreement with the
owners/editors removal from configuration files.

I think we have a way safer Sympa now than half a year ago.

I'll use the latest version in the future Sympa training, so we will
have a lot of feedback from the latest features.

Best regards,

David
Regards,
-- Soji

Regards,
-- Soji

On Fri, 1 Jun 2018 13:44:25 +0900
IKEDA Soji <address@concealed> wrote:

Hi folks,

Half a year passed. I want to follow up the last post in December.

On Fri, 1 Dec 2017 11:43:33 +0900
IKEDA Soji <address@concealed> wrote:

Hi folks,

I want to describe what I have done in this half year, and what I
want to do in the future.

* Periodical releases of Sympa 6.2 have been done. Recently they
were done by quarters[1] (if it is hard, releases may be done by
half a year).

I can do it at least for more one year.
Ongoing. Made 2 stable releases as planned (another 1 withdrawn),
1 patch release and 1 security fix.

The next stable release is planned at 21st June.

* Refactoring:

- Many functions were refactored to be moved to "request" modules.
This sort of refactoring will continue in the next year.
The goal of this is making wwsympa, sympasoap and sympa.pl be
thin wrappers of "request" modules.
I hardly could put it forward for this half year. I spent time
moving documentation from older site, fixing some bugs (especially
things related to issue #11) and coping with security flaw.

Thus, my planned works described in below will evenly delay for
half a year.

- Refactoring datasources. I want to start it in the end of this
year and probably may be done in the first half of next year.
The goal is to define simple interface between datasource and
GUI (vue and so on).

- Refactoring task manager and task spool. It will be done in the
next year.
The purpose is to rewrite fossilized code.

- OO-based robots and configuration mechanism.
It would be better to be done on separate branch and be merged
into Sympa 7.

Regards,

-- Soji

[1] https://fr.wikipedia.org/wiki/Mod%C3%A8le:Solstice-%C3%A9quinoxe
Regards,
-- Soji

--
株式会社 コンバージョン
ITソリューション部 システムソリューション1グループ 池田荘児
〒140-0014 東京都品川区大井1-49-15 アクセス大井町ビル4F
e-mail address@concealed TEL 03-6429-2880
https://www.conversion.co.jp/
--
"Mieux vaut viser la perfection et la rater que viser la médiocrité et
l'atteindre."
- Francis Blanche



--
"Mieux vaut viser la perfection et la rater que viser la médiocrité et
l'atteindre."
- Francis Blanche


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




Archive powered by MHonArc 2.6.19+.

Top of Page