On Oct 24, 9:16 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Wed, 2007-10-24 at 18:34 +0000, Joe wrote:
> > If I understand this correctly, if you implemented this, could I use
> > the same python interpreter between multiple virtual hosts and not
> > worry about overlap?
>
> That's the rough goal, yes. Complete sandboxing might not be possible,
> because it would be nice to share memory usage (as Graham mentioned in
> his reply), however that would mean that any poking into the common
> modules' namespaces that one site did would affect all the other sites
> using that module: for example, if you added something to contrib.auth
> (just to pull a name out of the hat) by replacing
> contrib.auth.models.Auth.get_absolute_url, say, *all* sites would see
> that change. That's a little less contained than I would really like,
> but it's the trade-off for sharing memory. I haven't thought about this
> enough to feel confident going either way, yet.
The primary obstacle to overcome is the settings file (as stated
earlier in this thread). If the setting can be managed on a per
request bases, most other things will follow.
The example you provide here is an example of how not to develop a
django application. In 90% of the cases there is a preferred 'clean'
way of implementing the functionality without the monkey patch (in
this case the settings ABSOLUTE_URL_OVERRIDES). Also these types of
hacks have a habit of colliding or breaking other apps. A monkey patch
like this has problems NOW irrespective of multiple sites in the same
interpreter, when two apps try to muck with the same 'global' state.
Try using the original django-registration from the old code wiki and
django-conference on the same site. You can't as they both muck with
the user. (thankfully this is no longer the case, but you get the
point).
The sites framework is a perfect example of 'doing it right', and will
pay big dividends if we can get to multiple sites on a single
interpreter. Many apps out there are not site aware, but that is not
that big a deal. I see hosting multiple sites in a single instance as
an 'advanced' mode of hosting, where speed and memory are crucial. If
that is the case, then you really need to know what you are doing.
Ground rules will need to be documented along the same lines as
'developing portable apps', which I see as a good starting point.
>
> Realise that this is all still in the planning phase because I have to
> get queryset-refactor finished along with other regular maintainer work
> done, too. But I've got at least two long plane flights coming up in the
> next month, so that should give me some time to think about things and
> work on an implementation.
>
> Regards,
> Malcolm
>
> --
> Always try to be modest and be proud of it!http://www.pointy-stick.com/blog/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
