You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Olemis Lang <ol...@gmail.com> on 2012/11/19 08:04:59 UTC
[BEP-0003] Request to reject /ticket//
routes WAS: [Apache Bloodhound] Proposals/BEP-0003 modified
I've been working on BEP-0003 recently , adding some routes we should
support and why . Some details still missing on the subject ,
especially how all this will work in the context of product
environments .
... read below ...
On 11/19/12, Apache Bloodhound <bl...@incubator.apache.org> wrote:
> 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
>
[...]
>
> '''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>). 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.
>
Since proposed solution consists in replicating multi-environment
setup inside a single environment formerly proposed URL template (i.e.
/ticket/<product prefix>/<sequence ID>) seems not to be appropriate
for request dispatching, filtering and other processes taking place in
the context of product environments.
Therefore I'm proposing to move it to «Rejected ideas» section . I
look forward to your comments for feedback .
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [BEP-0003] Request to reject /ticket// routes WAS: [Apache Bloodhound] Proposals/BEP-0003 modified
Posted by Jure Zitnik <ju...@digiverse.si>.
On 11/20/12 11:26 AM, Gary Martin wrote:
> On 20/11/12 09:24, Peter Koželj wrote:
>> On 19 November 2012 16:45, Olemis Lang <ol...@gmail.com> wrote:
>>
>>> On 11/19/12, Gary Martin <ga...@wandisco.com> wrote:
>>>> On 19/11/12 07:04, Olemis Lang wrote:
>>> [...]
>>>
>> I am against domins as products. All hell breaks lose when you web page
>> access different domains, which means any interproduct features
>> (relations,
>> search results...) will be hard to implement or unavailable to the
>> user in
>> which case we are back to Trac's multi-environments which are the cause
>> that we are having this discussion in the first place.
>
> I would expect that effectively this feature would already be
> available by providing appropriate configuration of a webserver. Of
> course, I could be wrong but I thought that it would be possible to
> use mod_rewrite to match the subdomain to redirect to the appropriate
> path. This leaves the problem of making sure that inter-product links
> work properly.
>
I think it should be enough to support one URL resource schema. If
someone has a wish to map this schema to something else I think that
should be, as Gary pointed out, possible by using URL rewrite approach.
>>
>>> [...]
>> Which resources do we have, that actually makes sense having outside the
>> project in multiproject setup?
If users are considered resources that would be one. Other than that,
maybe in the future we'd want to implement global permission schemes,
notification schemes, etc.
>> And I would also not distinguish between mutli-product and
>> single-product
>> setup while we are at it. A simple default product could be created
>> during
>> installation for users that do not have a need for multiple products.
>
+1
> Yes, I remember someone suggesting something like that to me before.
> Are you suggesting that tickets should always be associated with a
> product? I don't have a particular problem with allowing for a no
> product setup as well - or at least the appearance of no product as we
> should make sure that tickets within the null product are also
> continuous.
>
+1 for tickets to always be associated with a product. During the
Bloodhound setup at least 'default' product should be configured.
> Of course, if we always require a product path then we might be able
> to lose the requirement to mark a path as being for a product.
>
>> I suspect there is no way that we can introduce multiproduct without
>> making
>> plugins aware of it. Even if we manage to keep API compatibility,
>> multiproduct unaware plugins behavior will very likely be undesired the
>> moment the users creates the second product. So we will need a list
>> of BH
>> compatible/optimized plugins, at which point we can almost beak Trac API
>> compatibility in exchange for more streamlined implementation and user
>> experience. It is a tough problem to crack :(
+1
Cheers,
Jure
Re: [BEP-0003] Request to reject /ticket// routes WAS: [Apache Bloodhound] Proposals/BEP-0003 modified
Posted by Olemis Lang <ol...@gmail.com>.
On 11/21/12, Branko Čibej <br...@wandisco.com> wrote:
> On 21.11.2012 07:07, Olemis Lang wrote:
>> On 11/20/12, Branko Čibej <br...@wandisco.com> wrote:
>>> On 21.11.2012 05:08, Olemis Lang wrote:
>>>> On 11/20/12, Gary Martin <ga...@wandisco.com> wrote:
>>>>> On 20/11/12 09:24, Peter Koželj wrote:
>>>>>> On 19 November 2012 16:45, Olemis Lang <ol...@gmail.com> wrote:
>>>>>>> On 11/19/12, Gary Martin <ga...@wandisco.com> wrote:
>>>>>>>> On 19/11/12 07:04, Olemis Lang wrote:
>>>>>>> [...]
>>>>>>>>> On 11/19/12, Apache Bloodhound
>>>>>>>>> <bl...@incubator.apache.org>
>>>> [...]
>>>>>>>> Up until now I have been considering using 'products' as <namespace
>>>>>>>> path> but we might want to choose something else or even consider
>>>>>>>> whether this should be configurable. Configurability leads to some
>>>>>>>> problems when a user chooses a path that is already taken of
>>>>>>>> course.
>>>>>>>>
>>>>>>> I have a idea for this ... I'll write something on the subject later
>>>>>>> today
>>>>>>> .
>>>>>>>
>>>>>> I do not see a point for having namespace configurable. It
>>>>>> complicates
>>>>>> things for us and gives user a chance to shoot itself in the foot.
>>>>>>
>>>> By default they won't , since installer will only provide default well
>>>> known routes and they may be similar to multi-environment deployments.
>>>> I see that statement somehow different . I'd rather say «I do not see
>>>> a point for not having namespace configurable if that's what users
>>>> want» .
>>> Eh, making things configurable just for the hell of it ("because users
>>> want that" or for whatever other foggy reason) is bad design because it
>>> complicates your (data) model for no obvious benefit. Of course user
>>> will want it if you tell them it's possible.
>>>
>> Ok , let's see this from a practical perspective .
>>
>> 1. Imagine edgewall.org migrating towards multi-product deployments
>> (they have expressed their intentions to do so) , there you have
>> sub-domains use case .
>> 2. sf.net or somebody else trying to integrate Bloodhound with Allura .
>> In that case Routes will be already acting at a lower level
>> (via Pylons AFAIK) , then you'll have Turbogears ... and in the end
>> ...
>> Bloodhound would be embedded in Allura URL space .
>>
>> ... and I'm talking of external routes to reach the product
>> environment . Fact is that current solution implemented in
>> `trac.web.main.dispatch_request` is very limited and cannot be adapted
>> to such use cases .
>
> Both cases can be solved without touching the Bloodhound code.
AFAICS , not quite , even if Routes is not used . As I was trying to
explain in BEP 3 [1]_ request dispatching goes straight to the product
environment's instance of `trac.web.main.RequestDispatcher` , and
`trac.web.main.dispatch_request` is not aware of products existence .
;)
So , in any case we must improve `trac.web.main.dispatch_request`
either with Routes or without it . Routes would be a well-known and
tested way to match this data , but not the only one for sure .
> Looking
> just at plain vanilla httpd, you have mod_rewrite and mod_proxy; and
> there are any number of application-specific ways to achieve the same
> result if, e.g., Allura wanted to do the embedding as an add-on feature.
>
understood
> Making the URL space configurable within Bloodhound will only be wasting
> time writing partial solutions for a problem which is only relevant for
> these kinds of integrations, and /they/ already have much more powerful
> tools available to do the same thing than would ever make sense for
> Bloodhound proper to provide.
>
ok .
.. [1] Environment lookup
(https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003#env-dispatch)
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [BEP-0003] Request to reject /ticket// routes WAS: [Apache Bloodhound] Proposals/BEP-0003 modified
Posted by Branko Čibej <br...@wandisco.com>.
On 21.11.2012 07:07, Olemis Lang wrote:
> On 11/20/12, Branko Čibej <br...@wandisco.com> wrote:
>> On 21.11.2012 05:08, Olemis Lang wrote:
>>> On 11/20/12, Gary Martin <ga...@wandisco.com> wrote:
>>>> On 20/11/12 09:24, Peter Koželj wrote:
>>>>> On 19 November 2012 16:45, Olemis Lang <ol...@gmail.com> wrote:
>>>>>> On 11/19/12, Gary Martin <ga...@wandisco.com> wrote:
>>>>>>> On 19/11/12 07:04, Olemis Lang wrote:
>>>>>> [...]
>>>>>>>> On 11/19/12, Apache Bloodhound <bl...@incubator.apache.org>
>>> [...]
>>>>>>> Up until now I have been considering using 'products' as <namespace
>>>>>>> path> but we might want to choose something else or even consider
>>>>>>> whether this should be configurable. Configurability leads to some
>>>>>>> problems when a user chooses a path that is already taken of course.
>>>>>>>
>>>>>> I have a idea for this ... I'll write something on the subject later
>>>>>> today
>>>>>> .
>>>>>>
>>>>> I do not see a point for having namespace configurable. It complicates
>>>>> things for us and gives user a chance to shoot itself in the foot.
>>>>>
>>> By default they won't , since installer will only provide default well
>>> known routes and they may be similar to multi-environment deployments.
>>> I see that statement somehow different . I'd rather say «I do not see
>>> a point for not having namespace configurable if that's what users
>>> want» .
>> Eh, making things configurable just for the hell of it ("because users
>> want that" or for whatever other foggy reason) is bad design because it
>> complicates your (data) model for no obvious benefit. Of course user
>> will want it if you tell them it's possible.
>>
> Ok , let's see this from a practical perspective .
>
> 1. Imagine edgewall.org migrating towards multi-product deployments
> (they have expressed their intentions to do so) , there you have
> sub-domains use case .
> 2. sf.net or somebody else trying to integrate Bloodhound with Allura .
> In that case Routes will be already acting at a lower level
> (via Pylons AFAIK) , then you'll have Turbogears ... and in the end ...
> Bloodhound would be embedded in Allura URL space .
>
> ... and I'm talking of external routes to reach the product
> environment . Fact is that current solution implemented in
> `trac.web.main.dispatch_request` is very limited and cannot be adapted
> to such use cases .
Both cases can be solved without touching the Bloodhound code. Looking
just at plain vanilla httpd, you have mod_rewrite and mod_proxy; and
there are any number of application-specific ways to achieve the same
result if, e.g., Allura wanted to do the embedding as an add-on feature.
Making the URL space configurable within Bloodhound will only be wasting
time writing partial solutions for a problem which is only relevant for
these kinds of integrations, and /they/ already have much more powerful
tools available to do the same thing than would ever make sense for
Bloodhound proper to provide.
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: [BEP-0003] Request to reject /ticket// routes WAS: [Apache Bloodhound] Proposals/BEP-0003 modified
Posted by Olemis Lang <ol...@gmail.com>.
On 11/20/12, Branko Čibej <br...@wandisco.com> wrote:
> On 21.11.2012 05:08, Olemis Lang wrote:
>> On 11/20/12, Gary Martin <ga...@wandisco.com> wrote:
>>> On 20/11/12 09:24, Peter Koželj wrote:
>>>> On 19 November 2012 16:45, Olemis Lang <ol...@gmail.com> wrote:
>>>>> On 11/19/12, Gary Martin <ga...@wandisco.com> wrote:
>>>>>> On 19/11/12 07:04, Olemis Lang wrote:
>>>>> [...]
>>>>>>> On 11/19/12, Apache Bloodhound <bl...@incubator.apache.org>
>> [...]
>>>>>> Up until now I have been considering using 'products' as <namespace
>>>>>> path> but we might want to choose something else or even consider
>>>>>> whether this should be configurable. Configurability leads to some
>>>>>> problems when a user chooses a path that is already taken of course.
>>>>>>
>>>>> I have a idea for this ... I'll write something on the subject later
>>>>> today
>>>>> .
>>>>>
>>>> I do not see a point for having namespace configurable. It complicates
>>>> things for us and gives user a chance to shoot itself in the foot.
>>>>
>> By default they won't , since installer will only provide default well
>> known routes and they may be similar to multi-environment deployments.
>> I see that statement somehow different . I'd rather say «I do not see
>> a point for not having namespace configurable if that's what users
>> want» .
>
> Eh, making things configurable just for the hell of it ("because users
> want that" or for whatever other foggy reason) is bad design because it
> complicates your (data) model for no obvious benefit. Of course user
> will want it if you tell them it's possible.
>
Ok , let's see this from a practical perspective .
1. Imagine edgewall.org migrating towards multi-product deployments
(they have expressed their intentions to do so) , there you have
sub-domains use case .
2. sf.net or somebody else trying to integrate Bloodhound with Allura .
In that case Routes will be already acting at a lower level
(via Pylons AFAIK) , then you'll have Turbogears ... and in the end ...
Bloodhound would be embedded in Allura URL space .
... and I'm talking of external routes to reach the product
environment . Fact is that current solution implemented in
`trac.web.main.dispatch_request` is very limited and cannot be adapted
to such use cases .
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [BEP-0003] Request to reject /ticket// routes WAS: [Apache Bloodhound] Proposals/BEP-0003 modified
Posted by Branko Čibej <br...@wandisco.com>.
On 21.11.2012 05:08, Olemis Lang wrote:
> On 11/20/12, Gary Martin <ga...@wandisco.com> wrote:
>> On 20/11/12 09:24, Peter Koželj wrote:
>>> On 19 November 2012 16:45, Olemis Lang <ol...@gmail.com> wrote:
>>>> On 11/19/12, Gary Martin <ga...@wandisco.com> wrote:
>>>>> On 19/11/12 07:04, Olemis Lang wrote:
>>>> [...]
>>>>>> On 11/19/12, Apache Bloodhound <bl...@incubator.apache.org>
> [...]
>>>>> Up until now I have been considering using 'products' as <namespace
>>>>> path> but we might want to choose something else or even consider
>>>>> whether this should be configurable. Configurability leads to some
>>>>> problems when a user chooses a path that is already taken of course.
>>>>>
>>>> I have a idea for this ... I'll write something on the subject later
>>>> today
>>>> .
>>>>
>>> I do not see a point for having namespace configurable. It complicates
>>> things for us and gives user a chance to shoot itself in the foot.
>>>
> By default they won't , since installer will only provide default well
> known routes and they may be similar to multi-environment deployments.
> I see that statement somehow different . I'd rather say «I do not see
> a point for not having namespace configurable if that's what users
> want» .
Eh, making things configurable just for the hell of it ("because users
want that" or for whatever other foggy reason) is bad design because it
complicates your (data) model for no obvious benefit. Of course user
will want it if you tell them it's possible.
A case in point, Subversions "svn:externals" property can refer to
external entities at any depth in the working copy tree, not just in the
directory where the property is set. This sounded like a sexy idea back
in 2003 when they were designed, but in practice the number of weird
edge cases and exceptions that it generates and consequently the number
and intractability of the working-copy bugs related to that one, single
unnecessary quirk of this feature has by far outweighed the benefit that
any Subversion user may conceivably have got from it.
Another case in point, Subversion's original HTTP/DAV remote access
protocol allows the server administrator to configure just one component
of the of the DAV versioned resource URL that gives clients access to a
particular historical version of a file or directory. The result is that
clients have to discover that URL prefix from the server *for each
resource*, then cache the versioned-resource URI of each file in the
working copy (and that thing can conceivably change between two
consequent updates), making the protocol slower because it required more
trips to the server, and the working copy management more complex. Not
surprisingly, HTTPv2 does not allow that "flexibility" any longer, and
as a result it can actually make use of asynchronous pipelined HTTP
requests.
Keep it simple. Never make things configurable just because you can.
Think of the consequences. Consider how you'll design a RESTful API for
Bloodhound in the face of indeterminate URIs. Etc. ad nauseam.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: [BEP-0003] Request to reject /ticket// routes WAS: [Apache Bloodhound] Proposals/BEP-0003 modified
Posted by Olemis Lang <ol...@gmail.com>.
On 11/20/12, Gary Martin <ga...@wandisco.com> wrote:
> On 20/11/12 09:24, Peter Koželj wrote:
>> On 19 November 2012 16:45, Olemis Lang <ol...@gmail.com> wrote:
>>> On 11/19/12, Gary Martin <ga...@wandisco.com> wrote:
>>>> On 19/11/12 07:04, Olemis Lang wrote:
>>> [...]
>>>>> On 11/19/12, Apache Bloodhound <bl...@incubator.apache.org>
[...]
>>>
>>>> Up until now I have been considering using 'products' as <namespace
>>>> path> but we might want to choose something else or even consider
>>>> whether this should be configurable. Configurability leads to some
>>>> problems when a user chooses a path that is already taken of course.
>>>>
>>> I have a idea for this ... I'll write something on the subject later
>>> today
>>> .
>>>
>> I do not see a point for having namespace configurable. It complicates
>> things for us and gives user a chance to shoot itself in the foot.
>>
By default they won't , since installer will only provide default well
known routes and they may be similar to multi-environment deployments.
I see that statement somehow different . I'd rather say «I do not see
a point for not having namespace configurable if that's what users
want» .
>>
>>>> Presumably, running under an appropriate apache configuration, we would
>>>> be able to effectively access the a product without the user having to
>>>> specify the <namespace path> and we could even get the <product prefix>
>>>> specified as a subdomain instead.
>>>>
>>> like in edgewall.org , yes
>>>
>> I am against domins as products. All hell breaks lose when you web page
>> access different domains, which means any interproduct features
>> (relations,
>> search results...) will be hard to implement
All references are relative to environment's base URL . If the
solution pays attention to that then inter-product references will
just work just as InterTrac refrences just work for totally unrelated
Trac environments.
>> or unavailable to the user
>> in
>> which case we are back to Trac's multi-environments which are the cause
>> that we are having this discussion in the first place.
>
Multi-products vs multi-environment is mainly about many envs DBs vs
single products DB . I have deployed multiple web apps at different
sub-domains each interacting with the same DB ... so maybe I am not
seen something obvious ?
> I would expect that effectively this feature would already be available
> by providing appropriate configuration of a webserver.
Some people will need it , yes ;) . That's why it's the first option .
The most evident migration example would be edgewall.org .
Even if I don't think we should suggest sub-domains configuration as
the default option , IMO should make things work in a way that it will
be possible to get it done .
> Of course, I
> could be wrong but I thought that it would be possible to use
> mod_rewrite to match the subdomain to redirect to the appropriate path.
Indeed I was thinking of using VirtualHost(s). Routes supports
matching sub-domains via Host and X-Forwarded-Host headers .
> This leaves the problem of making sure that inter-product links work
> properly.
>
Added to my TODO list .
>>>> Effectively, this should probably apply to every resource that you can
>>>> have outside of a product (versions, milestones, wiki, etc) but it is
>>>> likely that this is where things begin to get a bit messy when
>>>> considering plugins that are not product-aware.
>>>>
>>> yes , eventually we need to come up with something regarding shared
>>> resources ... to be discussed in a separate thread , please
>>> ;)
>>>
>> Which resources do we have, that actually makes sense having outside the
>> project in multiproject setup?
In open source communities resource sharing is maybe not a big deal .
Let's focus on a software development enterprise . Everybody in there
will have checkpoints every (three | four ...) months . Major stable
releases will be scheduled to happen at that specific moment too . So
all products will share global milestones e.g. Q1 , Q2 , Q3 , Q4 , and
might have their own local milestones as well (e.g. urgent bug fix
releases , ...) . Q# milestones might be important for other business
experts e.g. management , marketing , strategic planning , ...
Other instances of global resources are users (if considered like so)
and also repositories .
>> And I would also not distinguish between mutli-product and single-product
>> setup while we are at it.
JFTR , the distinction mentioned in BEP 3 is not about multi-product
vs single-product . It's about multiples environments each one
containing multiple products vs a single environment containing
multiple products . Under some circumstances it is desired to have
explicit boundaries between data (e.g. security levels , data
confidentiality , ... but not limited to those) and environments are
better than products for that separation of concerns .
>> A simple default product could be created
>> during
>> installation for users that do not have a need for multiple products.
>
Also recall that there is another important case , which is
multi-product product support components disabled . Under such
circumstances the global environment will handle it all .
> Yes, I remember someone suggesting something like that to me before. Are
> you suggesting that tickets should always be associated with a product?
> I don't have a particular problem with allowing for a no product setup
> as well - or at least the appearance of no product as we should make
> sure that tickets within the null product are also continuous.
>
That null product is what I call the global environment , which turns
out to be the actual environment (i.e. managed by an instance of
`trac.env.Environment` ).
> Of course, if we always require a product path then we might be able to
> lose the requirement to mark a path as being for a product.
>
Enhanced routing mechanism adds support for this.
>> I suspect there is no way that we can introduce multiproduct without
>> making
>> plugins aware of it.
Playing with existing extension points , well , hopefully something
can be done .
>> Even if we manage to keep API compatibility,
>> multiproduct unaware plugins behavior will very likely be undesired the
>> moment the users creates the second product. So we will need a list of BH
>> compatible/optimized plugins, at which point we can almost beak Trac API
>> compatibility in exchange for more streamlined implementation and user
>> experience. It is a tough problem to crack :(
>
> Well, it is something to look into. API compatibility doesn't seem too
> difficult if we are able to detect the difference between the
> environments and others are willing to play along with the idea.
>
API compatibility on its own is not the main issue , considering the
fact that for components product-specific world will look exactly the
same as before . Semantically products are also exactly the same thing
. The main obstacle to succeed is database access. The fact that Trac
code base makes use of explicit SQL queries all the time is creating
such a problem due to the fact that current DB schema is not designed
for this particular purpose . If we only had a way to hide database
base access behind DAO [1]_ [2]_ [3[_ it would be much more easy to
override legacy environment-aware DAO and inject equivalent
product-aware DAO so as to make everything work in a magic , beautiful
way . Then we all would be happy, but no . The fact is that Trac-dev
has decided not to do so for a long time (do not ask me about the
reasons).
<joke>
Oh , mighty Java Beans !
I miss you so much . If you only were more ... Pythonic
</joke>
Maybe an option is to refactor Trac code base to introduce DAO (call
them models or not , using ORMs or not ...) before moving forward with
all this. Once that will be done then implement equivalent
product-aware DAO . Of course , in order to make all this work in a
way we can manage it'd be better if Trac-dev accepts the idea and
incorporates such changes into core.
.. [1] DAO = Data Access Object pattern
(http://en.wikipedia.org/wiki/Data_access_object)
.. [2] Core J2EE Patterns - Data Access Object
(http://www.oracle.com/technetwork/java/dataaccessobject-138824.html)
.. [3] DAO = Data Access Object pattern
(http://www.roseindia.net/tutorial/java/jdbc/dataaccessobjectdesignpattern.html)
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [BEP-0003] Request to reject /ticket// routes WAS: [Apache Bloodhound] Proposals/BEP-0003 modified
Posted by Gary Martin <ga...@wandisco.com>.
On 20/11/12 09:24, Peter Koželj wrote:
> On 19 November 2012 16:45, Olemis Lang <ol...@gmail.com> wrote:
>
>> On 11/19/12, Gary Martin <ga...@wandisco.com> wrote:
>>> On 19/11/12 07:04, Olemis Lang wrote:
>> [...]
>>>> On 11/19/12, Apache Bloodhound <bl...@incubator.apache.org>
>>>> wrote:
>>>>> 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
>>>>>
>>>> [...]
>>>>> '''FIXME''' also be addressable through the product URL namespace,
>>>>> namely
>>>>> /ticket/<product prefix>/<local ticket id>.
>>>>>
>> [...]
>>>> Since proposed solution consists in replicating multi-environment
>>>> setup inside a single environment formerly proposed URL template (i.e.
>>>> /ticket/<product prefix>/<sequence ID>) seems not to be appropriate
>>>> for request dispatching, filtering and other processes taking place in
>>>> the context of product environments.
>>>>
>>>> Therefore I'm proposing to move it to «Rejected ideas» section . I
>>>> look forward to your comments for feedback .
>>>>
>>> I am not sure that there is enough justification to allow for allowing a
>>> path/to/ticket/<product prefix>/<ticketid> - when only considering this
>>> form for tickets it is certainly possible but we should be making our
>>> lives easy for the determination of all resources that belong to a
>>> product so we are probably looking at (in a fairly generalised form):
>>>
>>> pathto/<namespace path>/<product prefix>/pathtoresource
>>>
>> +1
>>
>>> Up until now I have been considering using 'products' as <namespace
>>> path> but we might want to choose something else or even consider
>>> whether this should be configurable. Configurability leads to some
>>> problems when a user chooses a path that is already taken of course.
>>>
>> I have a idea for this ... I'll write something on the subject later today
>> .
>>
> I do not see a point for having namespace configurable. It complicates
> things for us and gives user a chance to shoot itself in the foot.
>
>
>>> Presumably, running under an appropriate apache configuration, we would
>>> be able to effectively access the a product without the user having to
>>> specify the <namespace path> and we could even get the <product prefix>
>>> specified as a subdomain instead.
>>>
>> like in edgewall.org , yes
>>
> I am against domins as products. All hell breaks lose when you web page
> access different domains, which means any interproduct features (relations,
> search results...) will be hard to implement or unavailable to the user in
> which case we are back to Trac's multi-environments which are the cause
> that we are having this discussion in the first place.
I would expect that effectively this feature would already be available
by providing appropriate configuration of a webserver. Of course, I
could be wrong but I thought that it would be possible to use
mod_rewrite to match the subdomain to redirect to the appropriate path.
This leaves the problem of making sure that inter-product links work
properly.
>
>>
>>> Anyway, with this scheme, the pathtoresource would represent anything
>>> that could be considered as belonging to the product using the same
>>> subsequent path as it would if it did not belong to a product.
>> +1
>> Nonetheless I'll wait for a while to move that paragraph to «rejected
>> ideas» section in spite of giving ourselves the chance to consider
>> more opinions .
>>
>>> Effectively, this should probably apply to every resource that you can
>>> have outside of a product (versions, milestones, wiki, etc) but it is
>>> likely that this is where things begin to get a bit messy when
>>> considering plugins that are not product-aware.
>>>
>> yes , eventually we need to come up with something regarding shared
>> resources ... to be discussed in a separate thread , please
>> ;)
>>
> Which resources do we have, that actually makes sense having outside the
> project in multiproject setup?
> And I would also not distinguish between mutli-product and single-product
> setup while we are at it. A simple default product could be created during
> installation for users that do not have a need for multiple products.
Yes, I remember someone suggesting something like that to me before. Are
you suggesting that tickets should always be associated with a product?
I don't have a particular problem with allowing for a no product setup
as well - or at least the appearance of no product as we should make
sure that tickets within the null product are also continuous.
Of course, if we always require a product path then we might be able to
lose the requirement to mark a path as being for a product.
> I suspect there is no way that we can introduce multiproduct without making
> plugins aware of it. Even if we manage to keep API compatibility,
> multiproduct unaware plugins behavior will very likely be undesired the
> moment the users creates the second product. So we will need a list of BH
> compatible/optimized plugins, at which point we can almost beak Trac API
> compatibility in exchange for more streamlined implementation and user
> experience. It is a tough problem to crack :(
Well, it is something to look into. API compatibility doesn't seem too
difficult if we are able to detect the difference between the
environments and others are willing to play along with the idea.
Cheers,
Gary
Re: [BEP-0003] Request to reject /ticket// routes WAS: [Apache Bloodhound] Proposals/BEP-0003 modified
Posted by Peter Koželj <pe...@digiverse.si>.
On 19 November 2012 16:45, Olemis Lang <ol...@gmail.com> wrote:
> On 11/19/12, Gary Martin <ga...@wandisco.com> wrote:
> > On 19/11/12 07:04, Olemis Lang wrote:
> [...]
> >>
> >> On 11/19/12, Apache Bloodhound <bl...@incubator.apache.org>
> >> wrote:
> >>> 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
> >>>
> >> [...]
> >>> '''FIXME''' also be addressable through the product URL namespace,
> >>> namely
> >>> /ticket/<product prefix>/<local ticket id>.
> >>>
> [...]
> >>>
> >> Since proposed solution consists in replicating multi-environment
> >> setup inside a single environment formerly proposed URL template (i.e.
> >> /ticket/<product prefix>/<sequence ID>) seems not to be appropriate
> >> for request dispatching, filtering and other processes taking place in
> >> the context of product environments.
> >>
> >> Therefore I'm proposing to move it to «Rejected ideas» section . I
> >> look forward to your comments for feedback .
> >>
> >
> > I am not sure that there is enough justification to allow for allowing a
> > path/to/ticket/<product prefix>/<ticketid> - when only considering this
> > form for tickets it is certainly possible but we should be making our
> > lives easy for the determination of all resources that belong to a
> > product so we are probably looking at (in a fairly generalised form):
> >
> > pathto/<namespace path>/<product prefix>/pathtoresource
> >
>
> +1
>
> > Up until now I have been considering using 'products' as <namespace
> > path> but we might want to choose something else or even consider
> > whether this should be configurable. Configurability leads to some
> > problems when a user chooses a path that is already taken of course.
> >
>
> I have a idea for this ... I'll write something on the subject later today
> .
>
I do not see a point for having namespace configurable. It complicates
things for us and gives user a chance to shoot itself in the foot.
>
> > Presumably, running under an appropriate apache configuration, we would
> > be able to effectively access the a product without the user having to
> > specify the <namespace path> and we could even get the <product prefix>
> > specified as a subdomain instead.
> >
>
> like in edgewall.org , yes
>
I am against domins as products. All hell breaks lose when you web page
access different domains, which means any interproduct features (relations,
search results...) will be hard to implement or unavailable to the user in
which case we are back to Trac's multi-environments which are the cause
that we are having this discussion in the first place.
>
> > Anyway, with this scheme, the pathtoresource would represent anything
> > that could be considered as belonging to the product using the same
> > subsequent path as it would if it did not belong to a product.
>
> +1
> Nonetheless I'll wait for a while to move that paragraph to «rejected
> ideas» section in spite of giving ourselves the chance to consider
> more opinions .
>
> > Effectively, this should probably apply to every resource that you can
> > have outside of a product (versions, milestones, wiki, etc) but it is
> > likely that this is where things begin to get a bit messy when
> > considering plugins that are not product-aware.
> >
>
> yes , eventually we need to come up with something regarding shared
> resources ... to be discussed in a separate thread , please
> ;)
>
Which resources do we have, that actually makes sense having outside the
project in multiproject setup?
And I would also not distinguish between mutli-product and single-product
setup while we are at it. A simple default product could be created during
installation for users that do not have a need for multiple products.
I suspect there is no way that we can introduce multiproduct without making
plugins aware of it. Even if we manage to keep API compatibility,
multiproduct unaware plugins behavior will very likely be undesired the
moment the users creates the second product. So we will need a list of BH
compatible/optimized plugins, at which point we can almost beak Trac API
compatibility in exchange for more streamlined implementation and user
experience. It is a tough problem to crack :(
>
> --
> Regards,
>
> Olemis.
>
> Blog ES: http://simelo-es.blogspot.com/
> Blog EN: http://simelo-en.blogspot.com/
>
> Featured article:
>
Re: [BEP-0003] Request to reject /ticket// routes WAS: [Apache Bloodhound] Proposals/BEP-0003 modified
Posted by Olemis Lang <ol...@gmail.com>.
On 11/19/12, Gary Martin <ga...@wandisco.com> wrote:
> On 19/11/12 07:04, Olemis Lang wrote:
[...]
>>
>> On 11/19/12, Apache Bloodhound <bl...@incubator.apache.org>
>> wrote:
>>> 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
>>>
>> [...]
>>> '''FIXME''' also be addressable through the product URL namespace,
>>> namely
>>> /ticket/<product prefix>/<local ticket id>.
>>>
[...]
>>>
>> Since proposed solution consists in replicating multi-environment
>> setup inside a single environment formerly proposed URL template (i.e.
>> /ticket/<product prefix>/<sequence ID>) seems not to be appropriate
>> for request dispatching, filtering and other processes taking place in
>> the context of product environments.
>>
>> Therefore I'm proposing to move it to «Rejected ideas» section . I
>> look forward to your comments for feedback .
>>
>
> I am not sure that there is enough justification to allow for allowing a
> path/to/ticket/<product prefix>/<ticketid> - when only considering this
> form for tickets it is certainly possible but we should be making our
> lives easy for the determination of all resources that belong to a
> product so we are probably looking at (in a fairly generalised form):
>
> pathto/<namespace path>/<product prefix>/pathtoresource
>
+1
> Up until now I have been considering using 'products' as <namespace
> path> but we might want to choose something else or even consider
> whether this should be configurable. Configurability leads to some
> problems when a user chooses a path that is already taken of course.
>
I have a idea for this ... I'll write something on the subject later today .
> Presumably, running under an appropriate apache configuration, we would
> be able to effectively access the a product without the user having to
> specify the <namespace path> and we could even get the <product prefix>
> specified as a subdomain instead.
>
like in edgewall.org , yes
> Anyway, with this scheme, the pathtoresource would represent anything
> that could be considered as belonging to the product using the same
> subsequent path as it would if it did not belong to a product.
+1
Nonetheless I'll wait for a while to move that paragraph to «rejected
ideas» section in spite of giving ourselves the chance to consider
more opinions .
> Effectively, this should probably apply to every resource that you can
> have outside of a product (versions, milestones, wiki, etc) but it is
> likely that this is where things begin to get a bit messy when
> considering plugins that are not product-aware.
>
yes , eventually we need to come up with something regarding shared
resources ... to be discussed in a separate thread , please
;)
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [BEP-0003] Request to reject /ticket// routes WAS: [Apache Bloodhound] Proposals/BEP-0003 modified
Posted by Gary Martin <ga...@wandisco.com>.
On 19/11/12 07:04, Olemis Lang wrote:
> I've been working on BEP-0003 recently , adding some routes we should
> support and why . Some details still missing on the subject ,
> especially how all this will work in the context of product
> environments .
>
> ... read below ...
>
> On 11/19/12, Apache Bloodhound <bl...@incubator.apache.org> wrote:
>> 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
>>
> [...]
>> '''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>). 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.
>>
> Since proposed solution consists in replicating multi-environment
> setup inside a single environment formerly proposed URL template (i.e.
> /ticket/<product prefix>/<sequence ID>) seems not to be appropriate
> for request dispatching, filtering and other processes taking place in
> the context of product environments.
>
> Therefore I'm proposing to move it to «Rejected ideas» section . I
> look forward to your comments for feedback .
>
I am not sure that there is enough justification to allow for allowing a
path/to/ticket/<product prefix>/<ticketid> - when only considering this
form for tickets it is certainly possible but we should be making our
lives easy for the determination of all resources that belong to a
product so we are probably looking at (in a fairly generalised form):
pathto/<namespace path>/<product prefix>/pathtoresource
Up until now I have been considering using 'products' as <namespace
path> but we might want to choose something else or even consider
whether this should be configurable. Configurability leads to some
problems when a user chooses a path that is already taken of course.
Presumably, running under an appropriate apache configuration, we would
be able to effectively access the a product without the user having to
specify the <namespace path> and we could even get the <product prefix>
specified as a subdomain instead.
Anyway, with this scheme, the pathtoresource would represent anything
that could be considered as belonging to the product using the same
subsequent path as it would if it did not belong to a product.
Effectively, this should probably apply to every resource that you can
have outside of a product (versions, milestones, wiki, etc) but it is
likely that this is where things begin to get a bit messy when
considering plugins that are not product-aware.
Cheers,
Gary