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 django-users@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
