SOC Proposal: Feedback needed.
P.C Shyamshankar
I'm planning to apply to SoC this year under Django, and although I
could write up a proposal for one of the ideas mentioned on the wiki
(especially the enhancements for auth.user, which I know a good deal
about), I thought I'd float my own ideas first for scrutiny.
Idea 1: Fixing get_absolute_url
Here I'm mainly referring to the difference between a complete URL
(with protocol, domain, etc.) and a URL relative the domain itself.
The former would be useful for external communications such as emails,
syndication, etc. while the latter is more suited for internal
references. The current approach as far as I know is to use
get_absolute_url to get a URL relative to the domain, and use the
sites framework to get the domain itself, and tack it on. This has a
number of drawbacks, including those that occur when the sites
framework is not used, or if subdomains come into play.
The solution would be to have two methods, one to get a URL for
external use, and one for internal use. This is the approach described
in http://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl
(somewhat old, but still applicable), my work would be to flesh that
out and integrate it into core.
Idea 2: Subdomain handling
This is somewhat tangled with the previous idea, I'm still considering
the implications of one on the other.
There are two main scenarios where subdomains may be used in a website:
1. Static subdomains denoting different parts of a site, such as blog,
gallery, wiki, code, etc. The landing page of the site may be one of
these subdomains, or may be something else altogether.
2. Dynamic subdomains created on the fly, either on a per-user basis,
per-project basis or on some other criteria.
Django needs to have some kind of mechanism to handle the case where a
single site may have multiple subdomains. The current URL routing
system does not allow for this.
I've thought of two approaches, one for each of the above scenarios:
1. For static subdomains, a separate rooted urlconf hierarchy for each
subdomain appears to be a logical option.
2. For dynamic subdomains, where each subdomain comprises a similar
hierarchy of URLs, a simple inclusion of the subdomain in the request
would seem to be sufficient.
The first approach is more thorough in my opinion, the second is far
simpler but less flexible.
My idea for integrating the two approaches is to give each subdomain
its own urlconf hierarchy. Static subdomains would have their own
urlconf explicitly written by the developer, while automatically
generated subdomains would have a "virtual urlconf", generated by
Django, based on a given template. This urlconf (either explicitly
written or implicitly generated) would then be given to the
resolution/reversal mechanism as usual.
I'd greatly appreciate feedback from the community on these ideas,
especially those concerning feasibility, and the relationship between
the two ideas I've proposed.
Russell Keith-Magee
<syk...@lucentbeing.com> wrote:
> Hello, everyone.
>
> I'm planning to apply to SoC this year under Django, and although I
> could write up a proposal for one of the ideas mentioned on the wiki
> (especially the enhancements for auth.user, which I know a good deal
> about), I thought I'd float my own ideas first for scrutiny.
>
> Idea 1: Fixing get_absolute_url
>
> Here I'm mainly referring to the difference between a complete URL
> (with protocol, domain, etc.) and a URL relative the domain itself.
> The former would be useful for external communications such as emails,
> syndication, etc. while the latter is more suited for internal
> references. The current approach as far as I know is to use
> get_absolute_url to get a URL relative to the domain, and use the
> sites framework to get the domain itself, and tack it on. This has a
> number of drawbacks, including those that occur when the sites
> framework is not used, or if subdomains come into play.
>
> The solution would be to have two methods, one to get a URL for
> external use, and one for internal use. This is the approach described
> in http://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl
> (somewhat old, but still applicable), my work would be to flesh that
> out and integrate it into core.
Firstly, the wiki page your reference doesn't cover all the most
recent discussion on this topic - in particular, the discussion that
occurred just prior to the 1.2 feature freeze [1]
[1] http://groups.google.com/group/django-developers/browse_thread/thread/52d699303daa9ba2
Secondly, while I'm in favor of addressing this general topic, I'm not
sure that this topic by itself is a good pick for the SoC. It's not
especially ambitious - the biggest impediments are design issues, not
coding issues. I suspect the final implementation of this bug will
only be a hundred lines of code or so, including tests. It might take
12 weeks to get a design consensus, but it certainly won't take 12
weeks to write the code -- and the GSoC is supposed to be about
writing code.
However, that said, there is a lot of crossover between this proposal
and your second...
> Idea 2: Subdomain handling
>
> This is somewhat tangled with the previous idea, I'm still considering
> the implications of one on the other.
>
> There are two main scenarios where subdomains may be used in a website:
>
> 1. Static subdomains denoting different parts of a site, such as blog,
> gallery, wiki, code, etc. The landing page of the site may be one of
> these subdomains, or may be something else altogether.
>
> 2. Dynamic subdomains created on the fly, either on a per-user basis,
> per-project basis or on some other criteria.
>
> Django needs to have some kind of mechanism to handle the case where a
> single site may have multiple subdomains. The current URL routing
> system does not allow for this.
Agreed. This is logged as ticket #8896, and the idea was accepted as a
low priority item for Django 1.2.
> I've thought of two approaches, one for each of the above scenarios:
>
> 1. For static subdomains, a separate rooted urlconf hierarchy for each
> subdomain appears to be a logical option.
>
> 2. For dynamic subdomains, where each subdomain comprises a similar
> hierarchy of URLs, a simple inclusion of the subdomain in the request
> would seem to be sufficient.
>
> The first approach is more thorough in my opinion, the second is far
> simpler but less flexible.
>
> My idea for integrating the two approaches is to give each subdomain
> its own urlconf hierarchy. Static subdomains would have their own
> urlconf explicitly written by the developer, while automatically
> generated subdomains would have a "virtual urlconf", generated by
> Django, based on a given template. This urlconf (either explicitly
> written or implicitly generated) would then be given to the
> resolution/reversal mechanism as usual.
I'm not entirely sure why you're making a special case of the 'static
subdomain' case - to me, the two cases are:
* The current situation, with no subdomain
* The multiple subdomain situation.
The idea of "static subdomains" is really just a dynamic subdomain
where the domain - in URLpatterns terms, it's like trying to claim
that
urlpatterns = patterns('',
(r'^test_view/', 'myapp.views.test_view),
)
is a static view, but
urlpatterns = patterns('',
(r'^test_view/(?P<id>)/', 'myapp.views.test_view),
)
is a dynamic view. There's really no difference between the two in
terms of handling; one pattern just has a dynamic component.
Similarly, a static subdomain is just a dynamic subdomain that doesn't
have a changing value. Matching 'newyork.example.com' and matching
'(?P<city_name>).example.com' isn't two use cases, it's one.
Beyond that, this proposal needs three things:
* Specific examples of how I would use this as an end user. What code
changes would I need to make in order to capture and route subdomains?
* Examples of how this subdomain information would manifest to an
end-user (your comment about including the information in the request
seems reasonable, but specific details are required)
* Explanations of how this manifests elsewhere in Django (e.g., Any
changes to reverse() and resolve()? To the test client?)
> I'd greatly appreciate feedback from the community on these ideas,
> especially those concerning feasibility, and the relationship between
> the two ideas I've proposed.
Personally, I think you've really described one project, not two. I'm
not sure how you could address subdomains in any meaningful way
without also addressing the get_absolute_url() issue.
On their own, I'd also be concerned about project duration; neither
project individually strikes me as 12 weeks work, but in combination,
it's probably getting close.
Both issues still require some substantial design work, and that
design needs to be approved by the dev community. This design doesn't
need to be completed before the project will be accepted, but you do
need to demonstrate that you have given the topic a lot of thought,
and are aware of the design issues that need to be resolved. If you
can't present a pre-approved design in your GSoC proposal, you will at
least need to provide a list of design issues that you know need to be
resolved, and more importantly convinces us that you have a complete
understanding of the scope of the problem.
However, despite all those caveats, I like the sound of the project.
It would be a valuable contribution to Django; the problems you're
proposing to fix have been discussed as desirable, but have been
waiting for a suitably motivated individual to implement them.
If the GSoC gives you that motivation, then your next step is to spend
some quality time with the existing code and our mailing list archive,
work out all the design issues that exist, and make a concrete
proposal. If you post that proposal to django-developers (and flag
that it is a GSoC proposal, so we don't complain about design
decisions in the final stages of a development cycle), we can start
kicking around specifics.
Yours
Russ Magee %-)
P.C Shyamshankar
look into other ideas for GSoC with Django.
Got it.
> Beyond that, this proposal needs three things:
>
> * Specific examples of how I would use this as an end user. What code
> changes would I need to make in order to capture and route subdomains?
If Django allows URL routing by domain, protocol and/or port, then those
parameters would have to be captured and passed on to the view function.
This of course means that the view function would have to be altered to
accept the new parameters, and that would have to be done for _every_
view function, which is unacceptable.
It then remains that there must be some way for switching between routing
by domain and routing as it is currently done. Then only those view functions
which need the domain/subdomain information would be written to receive it.
I suppose this is the kind of design decision that needs to be
discussed in detail
first.
> * Examples of how this subdomain information would manifest to an
> end-user (your comment about including the information in the request
> seems reasonable, but specific details are required)
If we can use some sort of specialized delimiter for different components of the
URL, then those components (after capturing) can be attached to the request
object rather than passed to the view function like other captured parameters.
The issue here is how to make the information available everywhere, but still be
able to pattern-match against it. I need to give this some more thought.
> * Explanations of how this manifests elsewhere in Django (e.g., Any
> changes to reverse() and resolve()? To the test client?)
The problem I anticipate here is that reversed URLs will be inconsistent. Those
that route with domain etc. will return absolute URLs, while those
that don't will
return URLs relative to the site root.
>> I'd greatly appreciate feedback from the community on these ideas,
>> especially those concerning feasibility, and the relationship between
>> the two ideas I've proposed.
>
> Personally, I think you've really described one project, not two. I'm
> not sure how you could address subdomains in any meaningful way
> without also addressing the get_absolute_url() issue.
>
> On their own, I'd also be concerned about project duration; neither
> project individually strikes me as 12 weeks work, but in combination,
> it's probably getting close.
And I thought I was being ambitious :|. I guess I included the design work
in with the code work.
> Both issues still require some substantial design work, and that
> design needs to be approved by the dev community. This design doesn't
> need to be completed before the project will be accepted, but you do
> need to demonstrate that you have given the topic a lot of thought,
> and are aware of the design issues that need to be resolved. If you
> can't present a pre-approved design in your GSoC proposal, you will at
> least need to provide a list of design issues that you know need to be
> resolved, and more importantly convinces us that you have a complete
> understanding of the scope of the problem.
>
> However, despite all those caveats, I like the sound of the project.
> It would be a valuable contribution to Django; the problems you're
> proposing to fix have been discussed as desirable, but have been
> waiting for a suitably motivated individual to implement them.
>
> If the GSoC gives you that motivation, then your next step is to spend
> some quality time with the existing code and our mailing list archive,
> work out all the design issues that exist, and make a concrete
> proposal. If you post that proposal to django-developers (and flag
> that it is a GSoC proposal, so we don't complain about design
> decisions in the final stages of a development cycle), we can start
> kicking around specifics.
I'll do some more digging then. Should I start posting this to django-developers
now, or continue here?
> Yours
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups "django-gsoc" group.
> To post to this group, send email to djang...@googlegroups.com.
> To unsubscribe from this group, send email to django-gsoc...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-gsoc?hl=en.
>
>
Russell Keith-Magee
I'm not convinced this is true at all. However...
> It then remains that there must be some way for switching between routing
> by domain and routing as it is currently done. Then only those view functions
> which need the domain/subdomain information would be written to receive it.
>
> I suppose this is the kind of design decision that needs to be
> discussed in detail
> first.
When I said you needed to give a specific example, I meant you need to
give a code sample. It doesn't need to work, but I should be able to
understand what it means by reading it. If you can think of multiple
ways of representing the
Think of it as a case study. I want to set up a restaurant review
site, and use subdomains to qualify regions for the reviews. Show me
what my URL patterns looks like in your proposal.
The reason we ask for this is that your ability to propose attractive
API speaks to your design taste. If you propose an elegant API,
there's a stronger chance you'll grok the way Django's internals work,
too. If you propose a bad API,
>> * Examples of how this subdomain information would manifest to an
>> end-user (your comment about including the information in the request
>> seems reasonable, but specific details are required)
>
> If we can use some sort of specialized delimiter for different components of the
> URL, then those components (after capturing) can be attached to the request
> object rather than passed to the view function like other captured parameters.
>
> The issue here is how to make the information available everywhere, but still be
> able to pattern-match against it. I need to give this some more thought.
>
>> * Explanations of how this manifests elsewhere in Django (e.g., Any
>> changes to reverse() and resolve()? To the test client?)
>
> The problem I anticipate here is that reversed URLs will be inconsistent. Those
> that route with domain etc. will return absolute URLs, while those
> that don't will
> return URLs relative to the site root.
That covers reverse and resolve, but what about the test client? Are
there any other areas of the code where these changes will manifest?
>>> I'd greatly appreciate feedback from the community on these ideas,
>>> especially those concerning feasibility, and the relationship between
>>> the two ideas I've proposed.
>>
>> Personally, I think you've really described one project, not two. I'm
>> not sure how you could address subdomains in any meaningful way
>> without also addressing the get_absolute_url() issue.
>>
>> On their own, I'd also be concerned about project duration; neither
>> project individually strikes me as 12 weeks work, but in combination,
>> it's probably getting close.
>
> And I thought I was being ambitious :|. I guess I included the design work
> in with the code work.
Well, I don't doubt that there will be *some* design work during the
project lifecycle, but in order for your proposal to be accepted,
you'll need to have most of the major design issues sorted out
beforehand (or at least be able to convince us that you're going to be
able to solve these issues).
As for how much effort is involved, consider multidb for comparison.
multidb was a SoC project. When it was finally delivered, it was a
21,000 line patch.
Code length isn't necessarily a measure of how much work was done --
it's certainly possible to have a big impact on the code without
making lots of changes -- but it is an indication of the fact that we
want applicants to be ambitious.
That said - if you can see complexity that leads you to believe that
this is much more complex than I think it is, that's what your
proposal is for!
>> Both issues still require some substantial design work, and that
>> design needs to be approved by the dev community. This design doesn't
>> need to be completed before the project will be accepted, but you do
>> need to demonstrate that you have given the topic a lot of thought,
>> and are aware of the design issues that need to be resolved. If you
>> can't present a pre-approved design in your GSoC proposal, you will at
>> least need to provide a list of design issues that you know need to be
>> resolved, and more importantly convinces us that you have a complete
>> understanding of the scope of the problem.
>>
>> However, despite all those caveats, I like the sound of the project.
>> It would be a valuable contribution to Django; the problems you're
>> proposing to fix have been discussed as desirable, but have been
>> waiting for a suitably motivated individual to implement them.
>>
>> If the GSoC gives you that motivation, then your next step is to spend
>> some quality time with the existing code and our mailing list archive,
>> work out all the design issues that exist, and make a concrete
>> proposal. If you post that proposal to django-developers (and flag
>> that it is a GSoC proposal, so we don't complain about design
>> decisions in the final stages of a development cycle), we can start
>> kicking around specifics.
>
> I'll do some more digging then. Should I start posting this to django-developers
> now, or continue here?
You've probably got enough to start posting to django-developers, as
long as you start getting into specifics.
Yours,
Russ Magee %-)