Issue already added to the tracker list. http://code.google.com/p/googleappengine/issues/detail?id=208
On Nov 4, 9:48 am, Kannaiyan <[EMAIL PROTECTED]> wrote: > Dan Sanderson: > > Thanks for the nice feedback and understanding. > > We need to have a smart way of maintaining versions. > What if Google Upgrades the version of Python Intrepreter to a higher > version when the code is written for lower version? > > We see Deprecated modules changing between higher versions. > You think we need to store our own Python binaries of that version to > keep it running? > > I have a very basic question, > > What happens if there is a bug (BETA) in GData module and the website > is not updated with that gdata update. > > 1. Do they have to shut the website down? > 2. What if someone exploits of a known bug and misuse the poor website > infrastructure, why you make the user as a victim of such happenings. > > If someone want to use higher version of the API, we need to come up > with a solution of Managing different versions. > > like, > > import gdata2 > > to use the extra facilities offered by gdata higher versions. > > I'm not discussing about integrating a third party module. > It is their own services and accessing their own products, mounting > extra work to it in the user side in maintaining the version of the > code. What a service :) > > /Kannaiyan > > On Nov 4, 9:23 am, Dan Sanderson <[EMAIL PROTECTED]> wrote: > > > > > On Mon, Nov 3, 2008 at 11:42 PM, Kannaiyan <[EMAIL PROTECTED]> wrote: > > > As a software developer I would allow users to reuse the same code. I > > > won't make million copies of the same code. (If used by millions of > > > people). If Python does not allow such sharing model, then the > > > language is a total CRAP. > > > Bundling a bunch of libraries with the runtime environment could be a bad > > idea in the long run. For example, consider the case where version 1 of the > > runtime environment includes version 1.0 of module A and version 1.0 of > > module B, and you write an app that uses these modules. Then later, App > > Engine releases version 2 of the runtime environment, which includes version > > 2.0 of module A and version 2.0 of module B. Perhaps your app is > > incompatible with module A v2.0 and would take several weeks to port, but > > there's nothing in A v2.0 that you need so you'd prefer to just stay with A > > v1.0. But you desperately need a feature in module B v2.0. > > > Thankfully, in Python it's easy to stay with version 1 of the runtime > > environment then add your own copy of B v2.0 to your app. But you can > > imagine that with many modules and many versions, this could get extremely > > difficult to manage very quickly, and you'll soon be including all of your > > dependencies with your app. > > > Bundled libraries make it easy to get started, and it's a good suggestion > > for App Engine to include the gdata library with the runtime as a starting > > point. Feel free to create an issue in the issue tracker for this. But > > beyond getting started, you probably won't want to use bundled libraries. > > > -- Dan- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
