Prerelease SDK 1.3.8 is out!

[Ikai Lan (Google)]

Hey everyone,

Prerelease SDK 1.3.8 is out for early evaluation. Note that many features that require server side changes will not be available in production, so for all intents and purposes these new features will only work locally. You can download the SDKs here:

http://code.google.com/p/googleappengine/downloads/list

1.3.8 Release Notes

------------------------

Python

-----------

- The developer who uploaded an app version can download that version's code

  using the appcfg.py download_app command. You can use this to download both

  Python and Java application code.

- Builtin app.yaml handlers are available for common application functions,

  such as appstats.

- The Admin Console now provides tools to delete all entities in the datastore

  or all entities of a given type. This is available only if enabled using the

  datastore_admin builtin. Deleting entities will count against application

  quota.

- You can run task queue tasks immediately from the Admin Console.

- You can now specify the quality of JPEG images via the Image API's

  execute_transforms function. Available in production only.

- Support for login of multiple Google accounts within an app, and longer login

  sessions. For more information see:

    http://www.google.com/support/accounts/bin/answer.py?answer=181599

- In queue.yaml, the maximum allowed bucket size is now 100.

- Precompilation is now enabled by default. To disable, use the

  --no_precompilation flag when updating your app.

- BlobInfo now has an open() method that returns a BlobReader.

- BlobReader now accepts a BlobInfo.

- Removed limits on zigzag merge-join queries. Therefore the error "The built-in

  indices are not efficient enough for this query and your data. Please add a

  composite index for this query." will no longer be thrown in many cases,

  enabling more types of exploratory queries without indexes.

- Fixed an issue with task queue tasks not running on the dev_appserver when

  using Python 2.6.

- Fixed an issue on the dev_appserver where auto task running wasn't working for

  BulkAdd.

- Fixed an issue reserving App Ids by owners of similarly-named mails accounts

  containing periods, multiple cases, and googlemail.com address.

    http://code.google.com/p/googleappengine/issues/detail?id=1196

- Fixed an issue with OpenId over SSL.

    http://code.google.com/p/googleappengine/issues/detail?id=3393

- Fixed an issue on the development server where PNGs were being returned as

  JPEGs.

    http://code.google.com/p/googleappengine/issues/detail?id=3661

Java

--------

- You can run task queue tasks immediately from the admin console.

- Added an OutputSettings class to the Images API to specify the JPEG encoding

  quality when running in production.

- Support for login of multiple Google accounts within an app, and longer login

  sessions. For more information see:

    http://www.google.com/support/accounts/bin/answer.py?answer=181599

- In queue.xml, the maximum allowed bucket size is now 100.

- Removed limits on zigzag merge-join queries. Therefore the error "The built-in

  indices are not efficient enough for this query and your data. Please add a

  composite index for this query." will no longer be thrown in many cases,

  enabling more types of exploratory queries without indexes.

- The whitelist has been updated to include java.net.InetAddress and some

  interfaces and abstract classes in javax.xml.soap, including

  javax.xml.soap.SOAPMessage.

- Fixed an issue reserving App Ids by owners of emails containing periods,

  multiple cases, and googlemail.com address.

    http://code.google.com/p/googleappengine/issues/detail?id=1196

- Fixed an issue where TaskOptions had no public getters, making testing

  impossible.

    http://code.google.com/p/googleappengine/issues/detail?id=3243

- Fixed an issue with OpenId over SSL.

    http://code.google.com/p/googleappengine/issues/detail?id=3393

- Fixed an issue on the development server where PNGs were being returned as

  JPEGs.

    http://code.google.com/p/googleappengine/issues/detail?id=3661

--

Ikai Lan 
Developer Programs Engineer, Google App Engine

Blogger: http://googleappengine.blogspot.com

Reddit: http://www.reddit.com/r/appengine

Twitter: http://twitter.com/app_engine

[Gopal Patel]

Biggest YAY!! is https for openid. YEYE!!

On Oct 5, 8:28 pm, "Ikai Lan (Google)" <ikai.l+gro...@google.com>
wrote:

[Gopal Patel]

one more thing ::

http://code.google.com/p/googleappengine/source/browse/trunk/python/VERSION

why google code still hase 1.3.5 version ? instead of 1.3.8 ?

[Peter Petrov]

On Wed, Oct 6, 2010 at 3:28 AM, Ikai Lan (Google) <ikai.l...@google.com> wrote:

- Fixed an issue with task queue tasks not running on the dev_appserver when

  using Python 2.6.

Does this mean that Python 2.6 is now (more or less) supported for the dev_appserver? Are there any significant issues remaining when not using Python 2.5? I'm asking because it's quite a pain having to setup an old Python version on modern Linux distros.

[Tim Hoffman]

You will need to watch that libraries/modules or code that uses things
like "with" (context managers ...) include the
from __future__ import with_statement otherwise these will blow up
when you run in production.

Also 2.6 has advanced string formatting .format method of str and
unicode which isn't present in 2.5

2.6 has a future feature of using print as a function.

Here is a complete list http://docs.python.org/whatsnew/2.6.html

So the bottom line is you whilst 2.6 will work in dev, you could end
up with code that will not
run in production. Chances are you are unlikely to use these features
in your own code
but a thirdparty library could.

So user beware and test in live appengine (get your self a test
instance) before you unleash
you new code on the masses ;-)

Personally I wouldn't bother using 2.6 until it is officially
supported by google in production.
The little extra pain you might have in dev setting it up will be a
lot less than the production
pain if you miss something and have to go and install 2.5 anyway ;-)

Rgds

Tim

On Oct 6, 11:17 am, Peter Petrov <onest...@gmail.com> wrote:
> On Wed, Oct 6, 2010 at 3:28 AM, Ikai Lan (Google)

> <ikai.l+gro...@google.com<ikai.l%2Bgro...@google.com>

[Greg]

On Oct 6, 1:28 pm, "Ikai Lan (Google)" <ikai.l+gro...@google.com>
wrote:

> - The developer who uploaded an app version can download that version's code
>   using the appcfg.py download_app command.

I'm not at all happy about this. I know how frequent plaintive "I lost
my code how can I get it back?" messages are in this group, but the
write-only nature of appengine gave me a lot of confidence that our
source code is safe. Now a single password is all that stands between
our competitors and our IP.

Why expose ALL users to risk (and open Google to lawsuits) for the
sake of a few inexperienced developers? Star this post if you agree.

I guess one solution would be to make downloading optional. A setting
to disable source downloading in app.yaml would be safe, because
uploading a new version would destroy the existing code.

Greg.

[Stefano Ciccarelli]

+1

[Nikolay Tenev]

+1

+1

--
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-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.

[Tim Hoffman]

+1 for download optional, and it can't be changed without re-reploying
(app.yaml config)

T

[djidjadji]

+1

2010/10/6 Greg <g.fa...@gmail.com>:

[Jeff Schwartz]

+1

Indeed, quite disconcerting.

On Wed, Oct 6, 2010 at 8:01 AM, Tom Wu <servic...@gmail.com> wrote:

+1

2010/10/6 Greg <g.fa...@gmail.com>

--
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-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.

--
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-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.

--
Jeff

[Peter Ondruska]

+1

On Oct 6, 2:05 pm, Jeff Schwartz <jefftschwa...@gmail.com> wrote:
> +1
>
> Indeed, quite disconcerting.
>
>
>
>
>

> On Wed, Oct 6, 2010 at 8:01 AM, Tom Wu <service.g2...@gmail.com> wrote:
> > +1
>
> > 2010/10/6 Greg <g.fawc...@gmail.com>
>
> >> On Oct 6, 1:28 pm, "Ikai Lan (Google)" <ikai.l+gro...@google.com<ikai.l%2Bgro...@google.com>

>
> >> wrote:
> >> > - The developer who uploaded an app version can download that version's
> >> code
> >> >   using the appcfg.py download_app command.
>
> >> I'm not at all happy about this. I know how frequent plaintive "I lost
> >> my code how can I get it back?" messages are in this group, but the
> >> write-only nature of appengine gave me a lot of confidence that our
> >> source code is safe. Now a single password is all that stands between
> >> our competitors and our IP.
>
> >> Why expose ALL users to risk (and open Google to lawsuits) for the
> >> sake of a few inexperienced developers? Star this post if you agree.
>
> >> I guess one solution would be to make downloading optional. A setting
> >> to disable source downloading in app.yaml would be safe, because
> >> uploading a new version would destroy the existing code.
>
> >> Greg.
>
> >> --
> >> 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-a...@googlegroups.com.
> >> To unsubscribe from this group, send email to

> >> google-appengi...@googlegroups.com<google-appengine%2Bunsubscrib e...@googlegroups.com>
> >> .

> >> For more options, visit this group at
> >>http://groups.google.com/group/google-appengine?hl=en.
>
> >  --
> > 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-a...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > google-appengi...@googlegroups.com<google-appengine%2Bunsubscrib e...@googlegroups.com>
> > .

[mscwd01]

+1

[Mike Wesner]

+1

[Felippe Bueno]

+1

> --
> 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-a...@googlegroups.com.

> To unsubscribe from this group, send email to google-appengi...@googlegroups.com.

[Peter Petrov]

+1000

The download feature should be optional, and off by default.

[Rodrigo Moraes]

On Oct 6, 6:48 am, Greg wrote:
> I guess one solution would be to make downloading optional. A setting
> to disable source downloading in app.yaml would be safe, because
> uploading a new version would destroy the existing code.

+1

I always considered not being able to download the code a feature.
Making it optional would probably be ideal.

-- rodrigo

[Barry Hunter]

+1.

Make it optional - default to on is ok. As long as it can be disabled.

[johnP]

+1

On Oct 6, 8:56 am, Barry Hunter <barrybhun...@gmail.com> wrote:
> +1.
>
> Make it optional - default to on is ok. As long as it can be disabled.
>

[tcg]

+1

[Ikai Lan (Google)]

Thanks for the feedback. We'll discuss the code download feature in more detail.

--

Ikai Lan 
Developer Programs Engineer, Google App Engine

Blogger: http://googleappengine.blogspot.com

Reddit: http://www.reddit.com/r/appengine

Twitter: http://twitter.com/app_engine

+1

[Robert Kluin]

+1

No download was a feature. AND it helped people with poor practices
learn the value of version control. :)

[Peter Petrov]

Thanks Tim, of course I'm talking about Python2.5-compatible code only. There are tools which can help you keep compatibility with 2.5 even if actually using a newer version - e.g. Eclipse PyDev has a grammar checker with configurable target version. Common sense also helps.

Having this in mind, dev_appserver compatibility with later Python versions can certainly be useful. 

[Geoffrey Spear]

On Oct 6, 5:48 am, Greg <g.fawc...@gmail.com> wrote:

> I'm not at all happy about this. I know how frequent plaintive "I lost
> my code how can I get it back?" messages are in this group, but the
> write-only nature of appengine gave me a lot of confidence that our
> source code is safe. Now a single password is all that stands between
> our competitors and our IP.

If you have unscrupulous competitors with your Google Account
password, I'd think the fact that they might download your source is
the least of your problems. They could just deploy malicious code to
your site instead.

[alf]

+1 only can download code administrator who pay bill

[nickmilon]

+1

[Zarko]

I would like to say thanks for the App Engine Team for all the hard
work :)

On Oct 6, 2:28 am, "Ikai Lan (Google)" <ikai.l+gro...@google.com>
wrote:

> Hey everyone,
>
> Prerelease SDK 1.3.8 is out for early evaluation. Note that many features
> that require server side changes will not be available in production, so for
> all intents and purposes these new features will only work locally. You can
> download the SDKs here:
>
> http://code.google.com/p/googleappengine/downloads/list
>
> 1.3.8 Release Notes
> ------------------------
>
> Python
> -----------

> - The developer who uploaded an app version can download that version's code

> - Fixed an issue with task queue tasks not running on the dev_appserver when
>   using Python 2.6.

[djidjadji]

Not a good choice because the one that pays the bill is not the one
that writes the source code.
I'm not paying for the storage requirement and bandwidth of my client
who has bought a use right of my software.

I'm an advocate of "NO Download allowed".

But in case it will be allowed make it OFF by default. You MUST turn
it ON in your app.yaml. This way the behavior is compatible with
previous versions. And there is no action needed by the people who
don't want it. There is always a gap between the time you roll it out
and you announce the availability of a new release on the production
servers. During this time it would be possible to download the source
code if you tried regularly.
And I could be away at the moment of the announcement and leave a door
wide open for quite some time.

2010/10/6 alf <alber...@gmail.com>:

[andy stevko]

One issue with the download code option is how it works in the context of an app store.
If I license an application thru a store, can I then download the code, modify it, and redeploy?
Also - if I have sensitive information (like Authorize.net keys) coded into my application, the information was basically inaccessible prior to this feature.

[Ikai Lan (Google)]

Well, there were always workarounds to download the code.

That being said, I'm glad we discussed this during the prerelease SDK stage, especially since many of the voices in this thread are the most active and knowledgeable members of the community speaking up. We're looking at alternatives, but what will likely happen is that we will delay this feature for an upcoming release when we've implemented something that takes everyone's feedback into account.

Stay tuned - I'll update this thread with more details.

--

Ikai Lan 
Developer Programs Engineer, Google App Engine

Blogger: http://googleappengine.blogspot.com

Reddit: http://www.reddit.com/r/appengine

Twitter: http://twitter.com/app_engine

[Jeff Schwartz]

Thank you, Ikai.

Jeff

[Remigius]

what Robert Kluin said.

version control is a must. sources shouldn't even have to be uploaded
in the first place (or is this py only?).

[Ikai Lan (Google)]

This is Python only. If you download a Java app you will download the JAR files.

--

Ikai Lan 
Developer Programs Engineer, Google App Engine

Blogger: http://googleappengine.blogspot.com

Reddit: http://www.reddit.com/r/appengine

Twitter: http://twitter.com/app_engine

[Geoffrey Spear]

On Oct 6, 6:27 pm, andy stevko <andy.ste...@gmail.com> wrote:
> One issue with the download code option is how it works in the context of an
> app store.
> If I license an application thru a store, can I then download the code,
> modify it, and redeploy?
> Also - if I have sensitive information (like Authorize.net keys) coded into
> my application, the information was basically inaccessible prior to this
> feature.

The item in the release notes says that it would be downloadable by
the developer who uploaded the version. If you are that developer,
you already have (or had) the source code. If you're not, you
wouldn't be able to get it, even if you're an administrator of the
app. To me it looks like the App Engine team got the balance right,
and I'm wondering if all of the "+1" people piling on really get
what's being described.

[Tim Hoffman]

Geoffry

Are you certain it's limited to the developer who uploaded or all
developers ?

Rgds

T

[Robert Kluin]

According to the release notes mail:

- The developer who uploaded an app version can download that version's code

using the appcfg.py download_app command. You can use this to download both
Python and Java application code.

I agree with Geoffrey, the balance is right if you have to have this
feature. But, personally I would just prefer either not having this
option OR just make it something that must be enabled. For me this
feature creates questions that do not exist now. And, yes I know that
if Appstats enabled you can sit there and browse through the code.
Not being able to _easily_ download the code is like a door-lock, it
keeps the honest people honest.

Robert

[Tim Hoffman]

Hi Geoff

Just confirmed with Wesley on IRC that the literal interpretation of
the release notes on downloads is correct.
That only the developer who uploaded can download that release.

Rgds

Tim

[Greg]

On Oct 7, 8:19 am, Geoffrey Spear <geoffsp...@gmail.com> wrote:
> If you have unscrupulous competitors with your Google Account
> password, I'd think the fact that they might download your source is
> the least of your problems.  They could just deploy malicious code to
> your site instead.

True, we still need to practise good password habits, so news of two-
factor authentication for Google Apps is welcome.

But it would be trivial to fix your site if someone defaced it; and
impossible to put the genie back in the bottle if your source code was
stolen.

[George Moschovitis]

> I guess one solution would be to make downloading optional. A setting
> to disable source downloading in app.yaml would be safe, because
> uploading a new version would destroy the existing code.

+1, please make this optional!

-g.

[pdknsk]

Thank you for adding the download feature. I develop on two machines, Linux and Windows, and syncing from within the SDK will be very convenient. It makes no difference for me, but I also support the suggestion to make it optional.

I have noticed a slight problem.

./appcfg.py download_app --application id dir/

appcfg.py: error: Cannot download to path "dir/": directory already exists and it isn't empty.

./appcfg.py --force download_app --application id dir/

appcfg.py: error: no such option: --force

[hawkett]

- Fix for the BulkAdd task queue on dev is great! Can finally get rid
of all the code in my app that forced sequential execution on dev.
Thx.
- Download code is not good from my perspective. I disagree strongly
that it is insignificant in comparison to other issues on a
compromised account. Until now this was a great argument for app
engine as a platform in business - 'Is my company's code safe in the
cloud?' Answer used to be a reasonably strong 'yes', now it's
'significantly less secure than your facebook account' (due to
multiple attack vectors of multiple developer accounts). This is a
poor security decision, and one with no apparent gains. I need to go
and advise a bunch of people now to re-assess their use of app engine
and decide if they are prepared to accept this new risk. This really
came out of the blue.
- OpenID/HTTPS cool, but doesn't seem to have helped with this issue -
http://stackoverflow.com/questions/3226880/secure-remote-api-in-app-engine-with-openid
- perhaps this feature is not available until the full release?

Please rethink code download, and notify as soon as possible whether
you have decided to go ahead with it - or, if you plan to allow it to
be turned off, how long you expect the download feature to be
available without the ability to turn it off - cheers,

Colin


On Oct 6, 1:28 am, "Ikai Lan (Google)" <ikai.l+gro...@google.com>
wrote:

> Hey everyone,
>
> Prerelease SDK 1.3.8 is out for early evaluation. Note that many features
> that require server side changes will not be available in production, so for
> all intents and purposes these new features will only work locally. You can
> download the SDKs here:
>
> http://code.google.com/p/googleappengine/downloads/list
>
> 1.3.8 Release Notes
> ------------------------
>
> Python
> -----------

> - The developer who uploaded an app version can download that version's code
>   using the appcfg.py download_app command. You can use this to download
> both
>   Python and Java application code.

[hawkett]

Limiting it to the developer who uploaded the code doesn't really help
in a decent sized team where multiple developers upload the code.
Developer A uploads version 1.3.37, and developer B uploads version
1.3.38, from an business IP perspective that's two developer accounts
that get access to the whole code base. Multiply by N.

And before people say - 'you should only have one guy uploading code'
- that's not a philosophy I subscribe to, based on

1. The hit by a bus problem - teams where only one member is familiar
with a task. This is mitigated by multiple team members being familiar
and active across multiple project tasks, and good policy.
2. Isolation of responsibility problem - this is a security risk,
morale risk, quality risk and stale process risk. Team members are
pretty capable people generally, and sharing responsibility across
multiple project elements is a good thing from all these perspectives.

And no, there shouldn't be one 'appengine super user' account that
every team member uses to achieve the above.

Not trying to be antagonistic, but I really want to put a solid stake
in the ground right opposite the argument that this is a good thing.
This will make a difference to business customers - technical
arguments aside, they like to hear - 'there is no download option'.

Thanks,

Colin

[Nacho Coloma]

> If you have unscrupulous competitors with your Google Account
> password, I'd think the fact that they might download your source is
> the least of your problems.  They could just deploy malicious code to
> your site instead.

That can be fixed, but you can't do anything about the fact that they
have your source code and can develop competing products.

[Jeff Schnitzer]

There is an even worse problem with a password compromise:

1) Malicious user gets your pw
2) Malicious user downloads your existing codebase
3) Malicious user makes subtle change - say, funneling sensitive data
to external site
4) Malicious user uploads this over running version

This would be almost impossible to detect. At least with the source
code separate, a malicious hacker has to either 1) re-implement enough
of the site to make it convincing, or 2) figure out the actual code
repository and credentials separately.

Honestly, I think this code download idea is unwise. Yes, it will
quiet down all the clueless folks that didn't back up their code, but
let's be realistic - these are not people who are serious about
software development and they are unlikely to be the ones building
apps that will ultimately generate revenue for appengine. GAE is not
google sites, you don't need to cater to the idiot 20%.

Jeff

[BenG]

Web hosting and version/source control should be kept separate. I
would rather not see source downloads baked into App Engine. However
I would like to see Google Code offer private projects for App Engine
users and have an interface built into the App Engine SDK. This would
address the previously mentioned issues of being able to only get
python source and not Java as well as keeping the source away from
anyone who may license your application.

I have read the Google Code FAQ and understand that they do not want
to privatize projects, but some solution of this manner would be
beneficial.

[pdknsk]

I don't understand the discussion when Google already indicated this
will be configurable.

[BenG]

I like to think of a web host and version control as 2 completely
separate entities. I am opposed to the idea of baking the two into
one.

It would be neat to see Google Code allow projects that are hosted on
app engine to be private and then add a version control client to the
SDK.

I understand that Google code does not plan on allowing private
projects, but I would have to think there is potential there to use
their infrastructure for a private vcs of App Engine projects. Google
developers put their code into a private vcs somewhere!?!?

[Robert Kluin]

AppEngine is a hosting platform, _not source control_.

You should learn about mercurial, git, or subversion.
http://bitbucket.org/
http://github.com/

Robert

[Ikai Lan (Google)]

You should *not* use this feature to sync versions between your computers. I cannot emphasize this strongly enough. Please use source control.

We value feedback, and this is precisely the point of the prerelease SDK - it's much easier to postpone a release early on rather than try to change directions mid-flight. We're still working on the details of whether this will be postponed or not (signs seem to point to yes, at least until it is user configurable). I'll update the thread when things are finalized.

--

Ikai Lan 
Developer Programs Engineer, Google App Engine

Blogger: http://googleappengine.blogspot.com

Reddit: http://www.reddit.com/r/appengine

Twitter: http://twitter.com/app_engine

[Ikai Lan (Google)]

By "user-configurable" I mean "opt-in", not "opt-out".

--

Ikai Lan 
Developer Programs Engineer, Google App Engine

Blogger: http://googleappengine.blogspot.com

Reddit: http://www.reddit.com/r/appengine

Twitter: http://twitter.com/app_engine

[Jeff Schwartz]

Get github, google code or something similar... Even at $7 a month for closed archives GitHub is a steal. Just the peace of mind makes it a bargain.

Jeff

[Eli Jones]

File my message under "Everyone's Got an Opinion"

I see that everyone went and got their dog.. and came out with their dog to "+1" either disabling code download or making it opt-in..

Sadly.. it seems that the code download option will only be beneficial to clueless people who don't use version control.. and clueless people who don't use version control probably won't know to enable this code download option.. (since.. if they had any sense and knew that having an offsite copy of their code was important, they would probably be using free version control somewhere)

The ultimate benefit of this is probably being able to tell the clueless non-version control using people that the option of code download was there.. and they could have enabled it.. and they have nothing to complain about.  And, they can enable it for their next project.. or just be smart and use Github or Google Code or Bitbucket or something..

Anyway... everyone's got an opinion..

[Remigius]

Does it really help to make it configurable? Once the account is
compromised, an attacker could easily opt-in and steal the code.

[Ikai Lan (Google)]

Well, the thought is that you wouldn't be able to download code from BEFORE the feature launched.

--

Ikai Lan 
Developer Programs Engineer, Google App Engine

Blogger: http://googleappengine.blogspot.com

Reddit: http://www.reddit.com/r/appengine

Twitter: http://twitter.com/app_engine

On Thu, Oct 7, 2010 at 1:06 PM, Remigius <remigius...@gmail.com> wrote:

Does it really help to make it configurable? Once the account is
compromised, an attacker could easily opt-in and steal the code.

--

[Greg]

The Appengine team have earned a lot of respect in my eyes for a)
listening, and b) reacting so quickly. One of the few downsides to
cloud services is that is easy for the provider to steamroller their
agenda through your objections by arguing it is good for other
anonymous customers. I shudder to think how this issue would have
played out with Azure.

So good on you - I know this will have been a huge PITA but your
response confirms again that we made the right decision in choosing
the Appengine platform.

Cheers!
Greg.

On Oct 8, 6:04 am, "Ikai Lan (Google)" <ikai.l+gro...@google.com>
wrote:

> You should *not* use this feature to sync versions between your computers. I
> cannot emphasize this strongly enough. Please use source control.
>
> We value feedback, and this is precisely the point of the prerelease SDK -
> it's much easier to postpone a release early on rather than try to change
> directions mid-flight. We're still working on the details of whether this
> will be postponed or not (signs seem to point to yes, at least until it is
> user configurable). I'll update the thread when things are finalized.
>
> --
> Ikai Lan
> Developer Programs Engineer, Google App Engine
> Blogger:http://googleappengine.blogspot.com
> Reddit:http://www.reddit.com/r/appengine
> Twitter:http://twitter.com/app_engine
>

> On Thu, Oct 7, 2010 at 9:51 AM, Robert Kluin <robert.kl...@gmail.com> wrote:
> > AppEngine is a hosting platform, _not source control_.
>
> > You should learn about mercurial, git, or subversion.
> >http://bitbucket.org/
> >http://github.com/
>
> > Robert
>
> > On Thu, Oct 7, 2010 at 06:25, pdknsk <pdk...@googlemail.com> wrote:
> > > Thank you for adding the download feature. I develop on two machines,
> > Linux
> > > and Windows, and syncing from within the SDK will be very convenient. It
> > > makes no difference for me, but I also support the suggestion to make it
> > > optional.
> > > I have noticed a slight problem.
> > > ./appcfg.py download_app --application id dir/
> > > appcfg.py: error: Cannot download to path "dir/": directory already
> > exists
> > > and it isn't empty.
>
> > > ./appcfg.py --force download_app --application id dir/
> > > appcfg.py: error: no such option: --force
>
> > > --
> > > 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-a...@googlegroups.com.
> > > To unsubscribe from this group, send email to

> > > google-appengi...@googlegroups.com<google-appengine%2Bunsu...@googlegroups.com>
> > .

> > > For more options, visit this group at
> > >http://groups.google.com/group/google-appengine?hl=en.
>
> > --
> > 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-a...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > google-appengi...@googlegroups.com<google-appengine%2Bunsu...@googlegroups.com>
> > .

[Greg]

On Oct 8, 9:06 am, Remigius <remigius.stal...@gmail.com> wrote:
> Does it really help to make it configurable? Once the account is
> compromised, an attacker could easily opt-in and steal the code.

If it is only configurable in app.yaml, then to change it an attacker
would have to do an upload, thereby overwriting the code they want to
download. This need a lot of testing to make sure it works with all
versions, and it precludes Appengine introducing an option to update
app.yaml from the dashboard. But it was the best way I could see to
make downloads configurable.

Another option would be an irrevocable kill-switch in the dashboard -
once downloads were disabled, they can never be re-enabled. But an
app.yaml setting somehow seems more trustworthy. And not having the
option at all is most trustworthy!

[Mikhail Kashkin]

Another point of view is problem when you sold your site to customer,
so you can be sure that
your code is protected. I know this is not good practice but I'm sure
this case exists.

On Oct 6, 12:48 pm, Greg <g.fawc...@gmail.com> wrote:
> On Oct 6, 1:28 pm, "Ikai Lan (Google)" <ikai.l+gro...@google.com>

> wrote:
>
> > - The developer who uploaded an app version can download that version's code
> >   using the appcfg.py download_app command.
>

--
Mikhail Kashkin
http://devcult.ru/
http://app-engine.tumblr.com/ - блог об App Engine

[Mikhail Kashkin]

You can be developer who depoly, but customer pay for instance.

On Oct 6, 10:52 pm, alf <alberto....@gmail.com> wrote:
> +1 only can download code administrator who pay bill

[Edel SM]

+1 for optional download.

On Wed, Oct 6, 2010 at 5:48 PM, Greg <g.fa...@gmail.com> wrote:
> On Oct 6, 1:28 pm, "Ikai Lan (Google)" <ikai.l+gro...@google.com>
> wrote:
>> - The developer who uploaded an app version can download that version's code
>>   using the appcfg.py download_app command.
>

> I'm not at all happy about this. I know how frequent plaintive "I lost
> my code how can I get it back?" messages are in this group, but the
> write-only nature of appengine gave me a lot of confidence that our
> source code is safe. Now a single password is all that stands between
> our competitors and our IP.
>

> Why expose ALL users to risk (and open Google to lawsuits) for the
> sake of a few inexperienced developers? Star this post if you agree.

>
> I guess one solution would be to make downloading optional. A setting
> to disable source downloading in app.yaml would be safe, because
> uploading a new version would destroy the existing code.
>

> Greg.

>
> --
> 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-a...@googlegroups.com.

> To unsubscribe from this group, send email to google-appengi...@googlegroups.com.

> For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
>
>

--
edel

[Kayomarz]

+1

[Jairo Vasquez]

+1

On Oct 6, 7:04 am, tcg <tomgu...@gmail.com> wrote:
> +1

[Alexandre Vivien]

Hello Ikai,

What about this fix that was listed in the prerelease notes?

- Fixed an issue with OpenId over SSL.
http://code.google.com/p/googleappengine/issues/detail?id=3393

Regards,
Alexandre

On Oct 6, 2:28 am, "Ikai Lan (Google)" <ikai.l+gro...@google.com>
wrote:

> Hey everyone,
>
> Prerelease SDK 1.3.8 is out for early evaluation. Note that many features
> that require server side changes will not be available in production, so for
> all intents and purposes these new features will only work locally. You can
> download the SDKs here:
>
> http://code.google.com/p/googleappengine/downloads/list
>
> 1.3.8 Release Notes
> ------------------------
>
> Python
> -----------

> - The developer who uploaded an app version can download that version's code

[Ikai Lan (Google)]

It didn't make it. We'll try to get it out ASAP.

--

Ikai Lan 
Developer Programs Engineer, Google App Engine

Blogger: http://googleappengine.blogspot.com

Reddit: http://www.reddit.com/r/appengine

Twitter: http://twitter.com/app_engine