Am 21.11.2014 01:21, schrieb Nicolas Évrard: > * Pierre-Louis Bonicoli [2014-11-20 23:26:40]: >> On 20/11/2014 20:53, Nicolas Évrard wrote: >>> In my opinion, Nereid should not be part of Tryton, but flask-tryton >>> should not either, and morepath-tryton neither and pyramid-tryton >>> neither. >>> >>> What should be part of tryton is reusable components that allow people >>> creating web interface on any of the aforementioned projects to start >>> with a good reusable basis and a good design. >>> >>> Just like we don't have all the variation of workflows on sale or >>> purchase, we should not have all the variations people are going to >>> use to access the Tryton server through an HTTP frontend. >> It is a pity that you didn't answer this when Sharoon first asked [1], >> nor when you presented flask-tryton [2]. > In fact at those times I had next to no opinion about Nereid / > flask-tryton / Pyramid / WhatEver :D. > > What made me realize that this is the right way to go (in my opinion) > is this year's discussions with Jan about morepath / pyramid. Having > so much different possibilities made me aware that we should be > web-development library agnostic and focus on the ERP-related stuffs. yes - and I never would except that my tryton-morepath work goes to core ;). Possibly we should first discuss what Tryton is in general. After some discussion in the german community I tend to think tryton like this:
Layer 1: the tryton-core with trytond and gtk-client (and sao) as the *holy grail* it is a *framework* for building up what ever you want - it comes with no business logic inside. it is the most protected part of the project, where quality is hardened by a very restrictive process of development and contribution. The core devs are choosing the workflows and everybody should respect the decisions (what is not excluding discussions and changes). To get a voice in this, you need to build up your reputation by involvement - than possibly you can change everything from inside ;) Layer 2: a bundle of core modules approved by the core dev This is the most solid base to build up your own solutions on top of a set of generic modules. It must be protected by the core devs as well, because a lot of third party modules depending on this. To get a change in here it must be double checked for not breaking third party implementations. The process is similar to the ones in core - expect there are more people involved because of the daily use of this layer. Here we need blueprints and discussions before the development, because this bundle must be most generic as possible. There should be a way to suggest modules from Layer 3 for entering this level. But the only allowed dependency for such modules is layer 1 and layer 2 itself. Layer 3: different additional bundles maintained by other companies/subcommunities dedicated to build up solutions for special industries and localisations One example could be a e-commerce bundle of openlabs. And we already have a very exciting example - GNUHealth. But there could be others like 'german accounting bundle' or whatever you want. Here we can have dependencies to projects outside the first two layers, following each idiot we can follow to say it with Luis ;). This bundles are maintained by companies or subcommunities with the knowledge of a particular part in the real world of economies or society. A community as a whole is not credible to have a overall knowledge of each part of the galaxy - but experts do have for the sun system they are working in. They decide which workflows are choosen, how versions are managed and how much responsibility they have for implementations of third party modules. Possibly something like a rating system would be nice (recommended by tryton core dev, recommend by community, following the core standards) This concept of the layers possibly should be communicated beside the three tiers of software architecture on a community web site. Jan
