Since haven't seen a response to my other questions and with Malcolm's rebuff to your idea, do I take it you aren't interested any more?
Graham On Nov 27, 5:19 pm, Brian <[EMAIL PROTECTED]> wrote: > Malcolm: > > Thanks for the reply. > > > Whilst I'm all in favour of attempting to solve problems given arbitrary > > constraints as a thought exercise, I think this one isn't really the > > best practical solution to anything. > > I'm sure that's a fault of my explanation, not the design. ;o) > > > > > You are proposing having a single addressable URL that points to vastly > > different content based on some other, transparent piece of information > > (a cookie). Why not use the URL space as it's been designed and give > > each instance its own URL? We have the domain namespace for that at the > > topmost level, as well as the full URL namespace for subdivisions at a > > different layer: www.example.com/user1/andwww.example.com/user2/, > > for example. You can do the authentication checks as an addendum to > > that, for example at the indivdual lighttpd (or other webserver of > > choice) level. > > > I'll go so far as to claim that your proposed setup up breaks the web. > > Not a single request to that site will be effectively long-term > > cacheable, since they will all have to vary on cookie. And you're using > > the same resource name for an arbitrarily large number of difference > > resources. The web performance and behaviour of people using such a > > setup is actively harmed when it's so easily avoidable. > > You're right in that the clandestine compacting of the url (especially > with disregard to plausible collisions) in lieu of a cookie to make > decisions about what the webserver resource location generally flies > in the face of fundamental principles of web design. However, this > choice has been carefully contemplated, though it may be reconsidered. > > For edification, the project is not a public web-site, but has limited > authenticated-only access, with all transmissions encrypted. There is > a one-to-one mapping between authenticated users' account (and, > notably, a cookie of theirs) and the content they may access on the > site; i.e. user1 may have example.com/link, and user2 have example.com/ > link. They are mutually exclusive, and neither is ever accessible by > the public. Thus the userx/ is superfluous. As well, due to the nature > of the site, it is extraordinarily unlikely that it would be accessed > by the same web browser for different accounts. It's all rather > unconventional, I admit, but certainly not arbitrary. > > As well, while there will be object caching, page caching is not the > right answer; the content is highly dynamic and it is a relatively low- > volume site, so caching is not a major concern. > > All to say, I'm cognizant of the concerns expressed, and while I'd > agree with your concerns for conventional web-sites, I'm quite > confident in the defensibility of the design choices made, poorly > though I may have explained them. I'm rather certain it won't break > the web. In any event URL compaction is not relevant to the crux of > the real problem, and as you suggest below, URL compaction it's just a > mod_rewrite. Please disregard any references to URL mapping or > compaction. > > > If you really, really wanted to go down the one name to rule them all > > path (for example, it wins you a really large bet that you accepted by > > accident), you could use mod_rewrite to do an internal redirect to the > > individually named URLs (maybe combined with some other modules). > > > I'm not going to participate much more in this, since there isn't really > > any Django content here (you mention the word Django a few times, but > > nothing is specific to Django or even uses Django in the solution you've > > proposed). I think re-evaluating your initial design would be > > beneficial, though. > > Quite alright. The question at hand is where to demultiplex a user > request to their respective datesets. It can happen either in Django > or at the web-server. I believe the crux of the problem, if Django is > the demultiplexer, could be expressed (making some presumptions about > plausible solutions) as follows: > > How could one have a Django installation, where (for example) one may, > based on the account of the logged-in User: > > (a) Add a "prefix_" to each database table; or > > (b) Change the database. > > I'd be particularly interested in seeing, for example, middleware that > takes a Request's User and changes the django.conf.SETTINGS > ['DATABASE_NAME'] to the database for this user's account, or > alternatively sets a prefix for all subsequent database access. > > However, this middleware approach raises red flags (and I don't know > Django well enough to overcome them), viz. > * Is changing django.conf.SETTINGS thread-safe? > * Is there just an inherent danger in changing django.conf.SETTINGS -- > would the DB connection be setup already? > * Is changing the DB connection part of the public API? > > I'm also conscious that these could require User authentication to be > stored and accessed in a different mechanism than the accounts' > respective databases. That's easy enough thanks to the delightfully > decoupled user authentication system in Django. > > I hold out hope that there is a brilliant, simple solution to this > problem via Django. However, my searches and inquiries suggest that > it's not a common problem, nor especially obvious. Failing a safe, > sensible way to change the database settings in a running Django > process (or some other intelligent way to demultiplex user requests to > their respective datasets; essentially semantic, mutually exclusive > sharding), I believe you've astutely pointed out that this isn't a > Django issue, and I should meander over to the webserver forums. I'd > prefer a Django solution to a webserver one, though, because it's the > right place to do it. > > I hope that clarifies the explanation some, and makes this vein of > inquiry of some value to the body of Django knowledge. If it's not > something that's a workable Django solution, I'd be happy to have some > certitude about that, too. > > Thank you, and best regards, > > Brian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" 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-users?hl=en -~----------~----~----~----~------~----~------~--~---
