incubator-bloodhound-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Apache Bloodhound" <bloodhound-...@incubator.apache.org>
Subject [Apache Bloodhound] Proposals/BEP-0003 modified
Date Fri, 16 Nov 2012 01:19:05 GMT
Page "Proposals/BEP-0003" was changed by olemis
Diff URL: <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diff&version=8>
Revision 8
Comment: [BEP-0003] Product-specific settings (refs #115) and corollaries mentioned by jure
in [/wiki/Proposals/BEP-0003?version=5 version 5]
Changes:
-------8<------8<------8<------8<------8<------8<------8<------8<--------
Index: Proposals/BEP-0003
=========================================================================
--- Proposals/BEP-0003 (version: 7)
+++ Proposals/BEP-0003 (version: 8)
@@ -36,7 +36,7 @@
 
 The key design mechanism is known as ''product environments'' . Their main goal is to provide
components (both in core and those defined by plugins) with a lightweight virtual representation
of an isolated environment inside the ''global'' environment when dealing with requests addressed
to a resource owned by a product. The following figure illustrates how they work.
 
-[[Image(Product_environments.png)]]
+[[Image(Product_envs_small.png)]]
 
 If you notice similarities with the [attachment:wiki:Proposals/BEP-0003/MultienvParentDir:Multienv_small.png
reference multi-environment setup] it is an intentional design decision.
 
@@ -82,12 +82,12 @@
 None
 }}}
 
-''Product environments'' will implement both `trac.core.ComponentManager` and `trac.core.Component`
APIs by inheriting most of the properties of the global `trac.env.Environment`, so they will
act as wrappers. As a consequence instances will have its own components cache, which means
that every active component class will only have a single instance for every product environment.

+''Product environments'' will implement both `trac.core.ComponentManager` and `trac.core.Component`
APIs. As a consequence instances will have its own components cache, which means that every
active component class will only have a single instance for every product environment. They
will inherit most of the properties of the global `trac.env.Environment` by acting as wrappers
often forwarding method calls to be handled by the parent global environment. 
 
 The following list explains how product environments will adapt existing environment API
while still being compatible with it.
 
-  - '''[=#product-env-conf] conf''' will contain an
-    instance of `trac.conf.Configuration` (or equivalent) setup in
+  - '''[=#product-env-config] config''' will contain an
+    instance of `trac.config.Configuration` (or equivalent) setup in
     such a way that it reads product-specific 
     settings from a file located at path
     `./conf/product_<product prefix>.ini` relative
@@ -108,17 +108,94 @@
 
 The following is a list of proposed features for multi product support in ''Bloodhound''.
Goals related to compatibility are considered in [#backwards-compatibility Backwards compatibility]
below. In each case you'll find notes explaining how candidate implementation will solve related
issues. 
 
-=== Per product ticket workflow #workflow
+=== Product components ecosystem #components
+
+All the functionalities installed in the global environment (e.g. blogs, pastebins) should
be available for products as well. Nonetheless they should be enabled/disabled on a per product
basis.
+
+{{{
+#!div class="well"
+{{{
+#!span class="label label-info"
+
+Implementation notes
+}}}
+Product environments are meant to implement `trac.core.ComponentManager` API and inherit
global plugins installations by design. Hence every component class will have a singleton
instance for each product (besides the one for the global environment). Components are enabled/disabled
via `[components]` section in configuration file. The fact that each product will have a [#config
separate configuration file] also means that there will be one such section to enable/disable
each one on a per product basis.
+
+This situation is quite similar to what happens nowadays in multi-environment installations.
+
+}}}
+
+=== Product-specific settings #config
+
+Component settings should be configurable per product. For practical reasons if there is
no explicit option assignment set for a particular product then it should inherit option value
set for the global environment.
+
+{{{
+#!div class="well"
+
+{{{
+#!span class="label label-info"
+
+  Implementation notes
+}}} 
+Product-specific settings will be implemented in #115 .
+
+`trac.conf.Configuration` instance in [#product-env-config config attribute] of product environments
will read settings from `product-<product prefix>.ini` file and will be configured to
inherit settings in environments' `trac.ini` file.
+
+Even if the proposal only suggests ''ini files'' to store product-specific configuration
it is also possible to think of using other configuration repositories (e.g. database, [http://hadoop.apache.org/hdfs/
HDFS], remote data repositories). It is a feasible enhancement though details have been omitted.
+}}}
+
+The following requirements are a corollary , considering that such customizations are performed
in  the configuration file.
+
+==== Per product ticket workflow #workflow
 
 Depending on the product, different ticket workflows should be supported.
 
-=== Per product notifications
+{{{
+#!div class="well"
+
+{{{
+#!span class="label label-info"
+
+  Implementation notes
+}}} 
+Edit `[ticket-workflow]` section in `product-<product prefix>.ini` file.
+
+[TracWorkflow#AdvancedTicketWorkflowCustomization Advanced ticket workflow customization]
will be possible for individual products since [#components components may be enabled/disabled
on a per product basis].
+
+}}}
+
+==== Per product notifications #notification
 
 Notifications should be configurable per product.
 
-=== Per product ticket field configuration
+{{{
+#!div class="well"
+
+{{{
+#!span class="label label-info"
+
+  Implementation notes
+}}} 
+Edit `[notification]` section in `product-<product prefix>.ini` file.
+
+}}}
+
+==== Per product ticket field configuration
 
 Components, milestone, version, priority, defaults, custom fields should be configurable
per product.
+
+
+{{{
+#!div class="well"
+
+{{{
+#!span class="label label-info"
+
+  Implementation notes
+}}} 
+Edit `[ticket-custom]` section in `product-<product prefix>.ini` file.
+
+}}}
 
 === Per product permission scheme #permissions
 
@@ -165,6 +242,8 @@
 == Rejected ideas #rejected
 
 Many interesting ideas have been proposed but not all could make their way into final specification
because of conceptual, practical or other reasons. Below you'll find the most relevant instances
together with brief comments explaining the decision , and maybe links to relevant messages
in [http://mail-archives.apache.org/mod_mbox/incubator-bloodhound-dev/ bloodhound-dev mailing
list archive] .
+
+  '''TODO''' : nothing rejected so far.
 
 == Backwards Compatibility #backwards-compatibility
 
-------8<------8<------8<------8<------8<------8<------8<------8<--------

--
Page URL: <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker

This is an automated message. Someone added your email address to be
notified of changes on 'Proposals/BEP-0003' page.
If it was not you, please report to .

Mime
View raw message