Roadmap to 2.0

[endelwar]

Here is a work-in-progress roadmap that should lead to MailWatch 2.0

As always this guideline is open for discussion and improvements!

• [x] Create a separate 1.2 branch where bug-fixing and security patching will happen
• [x] Start refactoring in a different branch: develop
• [x] Implement composer and autoloading
• [ ] Consolidate all functions in separated and organized classes
• [ ] Remove all globals (dependency injection) and create factories classes
• [ ] Write tests!!!
• [ ] Deprecate unused features
• [ ] Make better cli script
• [ ] Replace pear libs with something better
• [ ] Split domain logic from view
• [ ] Move translation to gettext format
• [ ] Implement request/response login
• [ ] Reorganize directory structure (/opt/mailwatch)
• [ ] Implement a router
• [ ] New UI layout
• [ ] Release 2.0

I've already started with this process, as can be see in this master/develop comparison as of 2017-12-07. PR to develop branch are as always welcome, as are tests on development server with different configuration (auth/MTA/php version/etc...)

[stefaweb]

H! @endelwar!

Possible to have develop-1.2 instead of 1.2 only?

This seems more understandable.

[stefaweb]

Sorry, again me.

How do we manage issues for 1.2 or 2.0?

[endelwar]

I've just created 2 new labels to identify version, they have to be assigned to new issues

1.2 is now officially in maintenance mode (as it should been from a long time): it's the stable release (à la Debian) which will become (soon?) the old-stable, only bug fixes and security hole will be fixed, new functionality will appear only in develop branch, paired with the ongoing refactoring.

As soon as 2.0 is released we will decide the supported period of maintenance (maybe 6months/1 year?).

[Skywalker-11]

Can you explain Implement a router?

[endelwar]

Can you explain Implement a router?

I would like to remove direct call to single php files and implement a routing system to map an URI to a controller->method or a closure like in these implementations:

• https://github.com/symfony/routing
• https://github.com/nikic/FastRoute
• https://github.com/dannyvankooten/PHP-Router

[stefaweb]

https://github.com/symfony/routing

I host some symfony dev for clients. Very stable.

Cheers,

[shawniverson]

Is this similar to Ruby on Rails routing in concept? I'm familiar with Ruby on Rails using this approach.

[Skywalker-11]

We should also consider to use ajax to request all of that data for the tables. With that MW can also be used in combination with other tools that can make REST requests and understands json. Eg https://datatables.net/ example: https://adminlte.io/themes/AdminLTE/pages/tables/data.html

[endelwar]

@shawniverson yes, the pattern is the same: a regex (more or sell) maps to a controller->method which execute the job for that route @Skywalker-11 if mvc pattern is well done it will be easy to output a json response instead of html response with no (or very small) code development, and this will make the following thing a lot easier to do:

• move frontend to a javascript framework like react/angular/vue
• creating a native smartphone app
• creating a native desktop app
• interconnection with third party software

But lets move the MailWatch code base to the 20th century before moving it to 21st century, refactoring has to be done in small non destructive steps or it will be a mess.

[philrandal]

1.2 branch needs to support PHP 5.4 as a minimum, as that version of PHP is used by default in CentOS 7 / RHEL 7

[Skywalker-11]

@philrandal the 1.2 branch will stay as it is and will continue to only receive bug fixes and security updates so PHP compatibility should stay as it is. For the 2.0 release it seems like we will require php 5.6 or higher but I guess that it will take at least about a year to get it in release state.

The duration between major releases for CentOS and RHEL were up to 4 years till now so they will probably release new major versions 2018 or 2019 which probably will include newer PHP releases.

[cordeosdev]

We would like to assist wherever we can in moving MW UI to a modern controller framework like Laravel, Symphony2 or Cake if possible. We have been working on quite a few complex DB PHP framework projects and also using and customizing MailWatch (via the EFA project) for over a year. It might be possible to start with a general auth/user/logon and base UI structure in a framework, leaving most of the core lists and calls as-is to render using the current PHP as blocks - then slowly move these one-by-one to new db storage/code.

[asuweb]

@endelwar - with regards to gettext implementation, do you want a vanilla gettext implementation relying on gettext binary being available on the server or would something like https://github.com/oscarotero/Gettext be an idea? This would provide platform transparency as it uses either gettext binary or its own implementation if it's not available.

It also handles sprintf by default.

The project is actively maintained.

[Skywalker-11]

@cordeosdev thanks for the suggestion I looked at the symfony framework and created a basic system where most of the old pages are still working (except the pagers because of require call in the pear package). Authentication and routing is done by symfony Basic commands that help working with the framework and installation with apache are described in file composer_help in the PR #1018

[pztop]

I am not sure if this is the proper place for feature request. But I really like MailWatch can let user define their own timezone and display his/her local time accordingly. It seems to me the v1.2 cannot do this.

[Skywalker-11]

I guess we could move such settings that are currently in the conf.php (time, language, date format, ...) to the db and create overwrites as follows: user settings overwrites domain default overwrites server default

[endelwar]

@endelwar - with regards to gettext implementation, do you want a vanilla gettext implementation relying on gettext binary being available on the server or would something like https://github.com/oscarotero/Gettext be an idea? This would provide platform transparency as it uses either gettext binary or its own implementation if it's not available.

If we take the symfony way, we should follow its standards supporting both xliff and gettext .po, but it seems that xliff is the preferred format

[endelwar]

I am not sure if this is the proper place for feature request

We should add a new issue for 2.0 feature request

I really like MailWatch can let user define their own timezone and display his/her local time accordingly.

Indeed!

[Skywalker-11]

Added a request for such feature https://github.com/mailwatch/MailWatch/issues/1028#issuecomment-357819151

[asuweb]

@endelwar - yes, totally agree, that using xliff make sense with symfony

[stefaweb]

One more. 😃

Switch to SHA512-CRYPT for password and others stuff using MD5.