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 Mon, 19 Nov 2012 06:39:33 GMT
Page "Proposals/BEP-0003" was changed by olemis
Diff URL: <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diff&version=14>
Revision 14
Comment: [BEP-003] Sample product URL mappings TODO: Detailed request dispatching
Changes:
-------8<------8<------8<------8<------8<------8<------8<------8<--------
Index: Proposals/BEP-0003
=========================================================================
--- Proposals/BEP-0003 (version: 13)
+++ Proposals/BEP-0003 (version: 14)
@@ -211,15 +211,116 @@
 
 === Product resources namespaces #url-mapping
 
-Product and resource ID should form a two dimensional namespace. The mapping should be flexible
enough to support the following scenarios .
-
-  - '''Product path namespace''' : '''TODO'''
-  - '''Product sub domain''' : '''TODO'''
-  - '''Product sub domain + path namespace''' : '''TODO'''
+Product and resource ID should form a two dimensional namespace. The mapping should be flexible
enough to support the scenarios mentioned below. Other deployments may still be possible but
are beyond the scope of this specification. However , in all cases every requests sent to
any path under product base URL will be handled by the request handlers and filters activated
in the target product environment.
+
+  - [=#deploy-domain] '''Product sub domain''' : The base URL of products
+    will be at sibling sub-domains. A well-known
+    example is edgewall.org (i.e. bitten.edgewall.org ,
+    genshi.edgewall.org , trac.edgewall.org ). 
+    The global environment may be accessible at one 
+    such sub-domain, at top level domain, or
+    somewhere else.
+
+{{{
+#!div class="well"
+
+{{{
+#!span class="label label-info"
+
+  Implementation notes
+}}}
+
+'''TODO'''
+
+}}}
+
+  - [=#deploy-sibling-paths] '''Product path namespace''' : Each product is 
+    accessible at sibling paths on the same domain.
+    The global environment will be available either at 
+    one such path or somewhere else.
+
+{{{
+#!div class="well"
+
+{{{
+#!span class="label label-info"
+
+  Implementation notes
+}}} 
+
+This case is very similar to the [./MultienvParentDir reference multi-environment setup]
.
+
+'''TODO'''
+
+}}}
+
+  - [=#deploy-global-env-embed] '''Embedded product path namespace''' : Each 
+    product is accessible at sibling paths inside 
+    the URL space of the global environment. 
+
+{{{
+#!div class="well"
+
+{{{
+#!span class="label label-info"
+
+  Implementation notes
+}}} 
+Even if this case is very similar to the [./MultienvParentDir reference multi-environment
setup] a better match will be another setup based on [trac:wiki:TracWsgiPlugin]. The main
difference with respect to [#deploy-sibling-paths sibling paths] deployment is that the global
environment plays an active role dispatching the requests addressed to an specific product
by forwarding them to the corresponding product environment.
+
+'''TODO'''
+
+}}}
+
+  - [=#deploy-domain-path] '''Product sub domain + path namespace''' : 
+    In this case product prefix will be 
+    matched against URL sub domain whereas 
+    ''Bloodhound'' will be accessed at a given path
+    inside of it. This case is frequently offered by
+    hosting providers like forges deploying multiple
+    web applications for projects . In general 
+    product base URL will look like 
+    `http://<product prefix>.domain.tld/path/to/bloodhound` .
+
+{{{
+#!div class="well"
+
+{{{
+#!span class="label label-info"
+
+  Implementation notes
+}}} 
+
+'''TODO'''
+
+}}}
+
+  - [=#deploy-domain-path] '''Arbitrary product path namespace''' : 
+    Sometimes hosting providers like forges do not 
+    support sub-domains for products. Hence 
+    product prefix is included in URL. 
+    In general, product base URLs will look like this
+    `http://domain.tld/path/to/<product prefix>/path/to/bloodhound` . 
+    One such hypothetical example would be 
+    `http://sourceforge.net/p/<product prefix>/bloodhound` .
+
+
+{{{
+#!div class="well"
+
+{{{
+#!span class="label label-info"
+
+  Implementation notes
+}}} 
+
+'''TODO'''
+
+}}}
 
 '''FIXME''' also be addressable through the product URL namespace, namely /ticket/<product
prefix>/<local ticket id>. 
 
-In a multi-product configuration product resources should not be accessed using current global
URL scheme (i.e. /path/to/bloodhound/<environment>/<realm>/<id>). '''TODO'''
why ?
+In a multi-product configuration product resources should not be accessed using current global
URL scheme (i.e. /path/to/bloodhound/<environment>/<realm>/<id>). Since
[#permissions products will have their own permissions schema] then requests handled by components
in the context of the top-level environment will perform neither the right permissions checks
nor even use appropriate settings , and so on ... The same will happen for resources moved
between products . In general such requests should be redirected to a URL under the namespace
of resource's product.
 
 ==== Tickets #tickets-namespace
 
-------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