Hi Stephen, > > 1. Going down this route appears to lose all the state > management you > > get for free in pylons/plone/joomla/PHP which is a shame. > Am I wrong? > > (And yes, I can see that if the NDG Context Service works then we > > don't care at all). > > The state management only works "for free" within one > application stack. If joomla wants to share state with > Pylons one of the two has to expose an API to the other or > you need a 3rd component. You could point both at the same > relational database but this doesn't work if you want the API > to be visible to JavaScript.
I can see what you're trying to do but as a principle JavaScript based session access should be avoided as much as possible. > > Even within Python-land we may not want to have everything in > a single stack. Remember once upon a time NDG was going to > have multiple Browse servers all over NERC. How would they > have shared a user's "shopping basket"? We never begun to solve that. > > Phil has suggested you can point multiple Beaker middleware > (the session management in Pylons) at a single database. > This gives you the same problem with JavaScript. There might be some mileage in adding in an eXist interface to the Beaker middleware so that at least all our existing Pylons apps could talk to it via their existing session interfaces. The majority of the session management goes on - and should go on - on the server side anyway. > > > 2. My gut reaction is that it could be a case of over-engineering > > fancy solutions to problems that don't require such > > attention. But I don't know the requirement like you do. > I'm just playing devil's advocate here but I want to avoid us > > doing this as a "playing with new technology" exercise if > it is not necessary. > > I'm actually trying to reduce developer work. We could build > something in Pylons but the requirements look very similar to > what eXist does out of the box (I may be wrong, of course :-) > ). We want a web API, we want some nod to OGC Web Map > Context and therefore XML, we want simple > Create/Read/Update/Delete. My main worry is integrating it > with security (as always). If you can reference a session cookie from your AJAX call and route traffic over SSL then it doesn't seem much worse than the existing cookie based security we have in place. User confirmation for cross-domain security interactions could annoy the user though: if the eXist service was in a different domain the user would need to be prompted for signin. The eXist service itself would need to be fronted either by a proxy hosting the Python security middleware or else a Java security interface in a servlet. Cheers, Phil > > From: [email protected] > [mailto:[email protected]] On Behalf Of > Stephens, Ag (STFC,RAL,SSTD) > Sent: 16 September 2009 16:03 > To: NERC DataGrid Technical List; Donegan, Steve > (STFC,RAL,SSTD); Juckes, Martin (STFC,RAL,SSTD); Norton, > Peter (Tessella,RAL,SSTD) > Subject: RE: [ndg-technical] NDG Context Service proposal > > > Hi Stephen, > > Good document, looks interesting. Here are my two concerns: > > 1. Going down this route appears to lose all the state > management you get for free in pylons/plone/joomla/PHP which > is a shame. Am I wrong? (And yes, I can see that if the NDG > Context Service works then we don't care at all). > > 2. My gut reaction is that it could be a case of > over-engineering fancy solutions to problems that don't > require such attention. But I don't know the requirement like > you do. I'm just playing devil's advocate here but I want to > avoid us doing this as a "playing with new technology" > exercise if it is not necessary. > > Now shoot me down with some responses. > > Cheers, > > Ag > > > > > From: [email protected] > [mailto:[email protected]] On Behalf Of > Pascoe, Stephen (STFC,RAL,SSTD) > Sent: 16 September 2009 12:06 > To: Donegan, Steve (STFC,RAL,SSTD); Juckes, Martin > (STFC,RAL,SSTD); Norton, Peter (Tessella,RAL,SSTD) > Cc: NERC DataGrid Technical List > Subject: [ndg-technical] NDG Context Service proposal > > > Hi all, > > Coming out of conversations I've had with Martin, Dom and > Peter about what we need for QESDI and IS-ENES I am > revisiting the "shopping basket" concept in NDG. > > We are now building web applications out of many different > components, only some of which are Python, and we really need > a unified mechanism for storing the user's application state. > I've written a short proposal document at > http://proj.badc.rl.ac.uk/ndg/wiki/Software/Co> ntextService > that tries to put the case formally. Please > take a look. > > The headline is that I think we should do this in eXist. > It's what eXist was designed for. The question is who could > do this development. I can assign Peter to it but he'd have > to learn xquery from scratch. If Steve has some time to > commit he could probably write it quicker. Steve, do you > have any experience with transactional xqueries (ones that > change the state of the db)? > > Also, for development can we use an existing eXist deployment > (pardon the pun) or should we start afresh in a development > sandbox. I'm not sure whether neptune has an eXist server running. > > Cheers, > Stephen. > > --- > Stephen Pascoe +44 (0)1235 445980 > British Atmospheric Data Centre > Rutherford Appleton Laboratory > > > > -- > Scanned by iCritical. > > > > -- > Scanned by iCritical. > > > > -- > Scanned by iCritical. > -- Scanned by iCritical. _______________________________________________ NDG-technical mailing list [email protected] http://lists.ncas.ac.uk/mailman/listinfo/ndg-technical
