Stephen, Very robust response. You've sold it to me! Cheers, Ag
________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Pascoe, Stephen (STFC,RAL,SSTD) Sent: 16 September 2009 17:44 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 > 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. 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. > 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). Hey, I've been one of the principle sceptics about eXist over the years but I think this is very different to what NDG-Browse was trying to do. Context documents aren't very relational. I'm running out of time so I've got to end it here. S. --- Stephen Pascoe +44 (0)1235 445980 British Atmospheric Data Centre Rutherford Appleton Laboratory ________________________________ 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/ContextService 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
