Create a new chrome/browser/apps folder and move PlatformAppService there.

Create a new chrome/browser/apps folder and move PlatformAppService there.

This is a small patch to create the folder and move the first files there. More files will move over as dependencies from the general extensions system to the apps code are cut.

OWNERS have been copied from chrome/browser/extensions, and a new namespace apps has been created.

BUG=159366

[benwells, 2012-11-05 03:01:23]

Ideas for discussion:
- platform_apps or apps?
- should we trim down OWNERS?

[Aaron Boodman, 2012-11-05 04:35:11]

LGTM, but I think maybe s/platform_app/app/g ?

Downside: there are lots of things already called 'app'
Upside: this is the best 'app' though!

[benwells, 2012-11-05 04:53:34]

On 2012/11/05 04:35:11, Aaron Boodman wrote:
> LGTM, but I think maybe s/platform_app/app/g ?
> 
> Downside: there are lots of things already called 'app'
> Upside: this is the best 'app' though!

Yes, apps seems too ambiguous. It is nice and short, but there are hosted,
packaged and non-extension-web apps.

[aa, 2012-11-05 04:55:13]

OK, fair enough.

[benwells, 2012-11-05 06:50:14]

With platform_apps instead of apps

[Ben Goodger (Google), 2012-11-05 18:36:50]

So I have been talking with Darin about some of this stuff. I'm glad you're
working on it.

I think we want to end up with the base of the app runtime living outside
of src/chrome. The reason is that you should think of Chrome (long term) as
an app. Even though it is and will for the foreseeable future be
implemented in native code using stuff unavailable to apps it is very
helpful to our architecture if you think of the apps stuff as above Chrome.

For example, for Ash we should be able to build and run apps in the test
Ash shell exe independent of Chrome.

I don't really think "platform apps" is any less vague, given the various
meanings and parts of the word "platform". It certainly is a lot more
characters to type. I think the project is also suffering from too many
names: Platform Apps, Apps V2, Apps, etc. It's hard to keep them all
straight! I had discussed with Darin a toplevel dir: src/apps which has a
very concise ring to it. WDYT?

-Ben


On Sun, Nov 4, 2012 at 10:50 PM, <benwells@chromium.org> wrote:

> With platform_apps instead of apps
>
>
http://codereview.chromium.**org/11293087/<http://codereview.chromium.org/112...
>

[aa, 2012-11-05 20:52:18]

I don't care too much about the name. apps is fine, and your reasons
are reasonable.

As for top-level, the plan was to put apps in its own subdir of
chrome/browser, then move to top-level as a second step. Do you want
to go direct to top-level right from the beginning for some reason?
(TBH, I was starting to think of doing that for extensions, just
because I felt like it might make a cleaner separation between new,
awesome and old, busted, but I'm not sure yet how realistic one big step is).

- a

On Mon, Nov 5, 2012 at 10:36 AM, Ben Goodger (Google) <ben@chromium.org> wrote:
> So I have been talking with Darin about some of this stuff. I'm glad you're
> working on it.
>
> I think we want to end up with the base of the app runtime living outside of
> src/chrome. The reason is that you should think of Chrome (long term) as an
> app. Even though it is and will for the foreseeable future be implemented in
> native code using stuff unavailable to apps it is very helpful to our
> architecture if you think of the apps stuff as above Chrome.
>
> For example, for Ash we should be able to build and run apps in the test Ash
> shell exe independent of Chrome.
>
> I don't really think "platform apps" is any less vague, given the various
> meanings and parts of the word "platform". It certainly is a lot more
> characters to type. I think the project is also suffering from too many
> names: Platform Apps, Apps V2, Apps, etc. It's hard to keep them all
> straight! I had discussed with Darin a toplevel dir: src/apps which has a
> very concise ring to it. WDYT?
>
> -Ben
>
>
> On Sun, Nov 4, 2012 at 10:50 PM, <benwells@chromium.org> wrote:
>>
>> With platform_apps instead of apps
>>
>> http://codereview.chromium.org/11293087/
>
>

[Ben Goodger (Google), 2012-11-05 20:55:55]

Your plan sounds fine, the top level is where I'd like things to end up. If
you want to achieve this in a few steps that sounds ok to me esp if there
are a lot of dependencies that need shaking out.

I remember we discussed a while back that it sounded reasonable for the
bits of code shared by extensions and apps to be at the top level. I'm not
sure if that would be part of src/apps or some other toplevel but that
continues to make a lot of sense to me.

There have been requests from developers to add extension apis to toplevel
components other than chrome - e.g. an extension api for src/ash that
allows for window manager tweaks. To support that case it sounded like the
concept of an extension and the ability to define an extension API were the
bits that sound be extracted, while src/chrome would retain all the code
related to apis for specific browser features.

-Ben


On Mon, Nov 5, 2012 at 12:51 PM, Aaron Boodman <aa@google.com> wrote:

> I don't care too much about the name. apps is fine, and your reasons
> are reasonable.
>
> As for top-level, the plan was to put apps in its own subdir of
> chrome/browser, then move to top-level as a second step. Do you want
> to go direct to top-level right from the beginning for some reason?
> (TBH, I was starting to think of doing that for extensions, just
> because I felt like it might make a cleaner separation between new,
> awesome and old, busted, but I'm not sure yet how realistic one big step
> is).
>
> - a
>
> On Mon, Nov 5, 2012 at 10:36 AM, Ben Goodger (Google) <ben@chromium.org>
> wrote:
> > So I have been talking with Darin about some of this stuff. I'm glad
> you're
> > working on it.
> >
> > I think we want to end up with the base of the app runtime living
> outside of
> > src/chrome. The reason is that you should think of Chrome (long term) as
> an
> > app. Even though it is and will for the foreseeable future be
> implemented in
> > native code using stuff unavailable to apps it is very helpful to our
> > architecture if you think of the apps stuff as above Chrome.
> >
> > For example, for Ash we should be able to build and run apps in the test
> Ash
> > shell exe independent of Chrome.
> >
> > I don't really think "platform apps" is any less vague, given the various
> > meanings and parts of the word "platform". It certainly is a lot more
> > characters to type. I think the project is also suffering from too many
> > names: Platform Apps, Apps V2, Apps, etc. It's hard to keep them all
> > straight! I had discussed with Darin a toplevel dir: src/apps which has a
> > very concise ring to it. WDYT?
> >
> > -Ben
> >
> >
> > On Sun, Nov 4, 2012 at 10:50 PM, <benwells@chromium.org> wrote:
> >>
> >> With platform_apps instead of apps
> >>
> >> http://codereview.chromium.org/11293087/
> >
> >
>

[Ben Goodger (Google), 2012-11-05 20:58:11]

btw if you start inside src/chrome you should set up a very explicit DEPS
file that bans #includes of the world beyond the world of extensions/apps,
and then explicitly allows those deps you currently have. You then have a
convenient worklist of dependencies to sever in order to be a toplevel
component. Having the DEPS file makes it harder to backslide accidentally.

-Ben


On Mon, Nov 5, 2012 at 12:55 PM, Ben Goodger (Google) <ben@chromium.org>wrote:

> Your plan sounds fine, the top level is where I'd like things to end up.
> If you want to achieve this in a few steps that sounds ok to me esp if
> there are a lot of dependencies that need shaking out.
>
> I remember we discussed a while back that it sounded reasonable for the
> bits of code shared by extensions and apps to be at the top level. I'm not
> sure if that would be part of src/apps or some other toplevel but that
> continues to make a lot of sense to me.
>
> There have been requests from developers to add extension apis to toplevel
> components other than chrome - e.g. an extension api for src/ash that
> allows for window manager tweaks. To support that case it sounded like the
> concept of an extension and the ability to define an extension API were the
> bits that sound be extracted, while src/chrome would retain all the code
> related to apis for specific browser features.
>
> -Ben
>
>
> On Mon, Nov 5, 2012 at 12:51 PM, Aaron Boodman <aa@google.com> wrote:
>
>> I don't care too much about the name. apps is fine, and your reasons
>> are reasonable.
>>
>> As for top-level, the plan was to put apps in its own subdir of
>> chrome/browser, then move to top-level as a second step. Do you want
>> to go direct to top-level right from the beginning for some reason?
>> (TBH, I was starting to think of doing that for extensions, just
>> because I felt like it might make a cleaner separation between new,
>> awesome and old, busted, but I'm not sure yet how realistic one big step
>> is).
>>
>> - a
>>
>> On Mon, Nov 5, 2012 at 10:36 AM, Ben Goodger (Google) <ben@chromium.org>
>> wrote:
>> > So I have been talking with Darin about some of this stuff. I'm glad
>> you're
>> > working on it.
>> >
>> > I think we want to end up with the base of the app runtime living
>> outside of
>> > src/chrome. The reason is that you should think of Chrome (long term)
>> as an
>> > app. Even though it is and will for the foreseeable future be
>> implemented in
>> > native code using stuff unavailable to apps it is very helpful to our
>> > architecture if you think of the apps stuff as above Chrome.
>> >
>> > For example, for Ash we should be able to build and run apps in the
>> test Ash
>> > shell exe independent of Chrome.
>> >
>> > I don't really think "platform apps" is any less vague, given the
>> various
>> > meanings and parts of the word "platform". It certainly is a lot more
>> > characters to type. I think the project is also suffering from too many
>> > names: Platform Apps, Apps V2, Apps, etc. It's hard to keep them all
>> > straight! I had discussed with Darin a toplevel dir: src/apps which has
>> a
>> > very concise ring to it. WDYT?
>> >
>> > -Ben
>> >
>> >
>> > On Sun, Nov 4, 2012 at 10:50 PM, <benwells@chromium.org> wrote:
>> >>
>> >> With platform_apps instead of apps
>> >>
>> >> http://codereview.chromium.org/11293087/
>> >
>> >
>>
>
>

[Ben Goodger (Google), 2012-11-05 20:58:40]

Finally, +Darin just in case he has any other thoughts to add.


On Mon, Nov 5, 2012 at 12:58 PM, Ben Goodger (Google) <ben@chromium.org>wrote:

> btw if you start inside src/chrome you should set up a very explicit DEPS
> file that bans #includes of the world beyond the world of extensions/apps,
> and then explicitly allows those deps you currently have. You then have a
> convenient worklist of dependencies to sever in order to be a toplevel
> component. Having the DEPS file makes it harder to backslide accidentally.
>
> -Ben
>
>
> On Mon, Nov 5, 2012 at 12:55 PM, Ben Goodger (Google)
<ben@chromium.org>wrote:
>
>> Your plan sounds fine, the top level is where I'd like things to end up.
>> If you want to achieve this in a few steps that sounds ok to me esp if
>> there are a lot of dependencies that need shaking out.
>>
>> I remember we discussed a while back that it sounded reasonable for the
>> bits of code shared by extensions and apps to be at the top level. I'm not
>> sure if that would be part of src/apps or some other toplevel but that
>> continues to make a lot of sense to me.
>>
>> There have been requests from developers to add extension apis to
>> toplevel components other than chrome - e.g. an extension api for src/ash
>> that allows for window manager tweaks. To support that case it sounded like
>> the concept of an extension and the ability to define an extension API were
>> the bits that sound be extracted, while src/chrome would retain all the
>> code related to apis for specific browser features.
>>
>> -Ben
>>
>>
>> On Mon, Nov 5, 2012 at 12:51 PM, Aaron Boodman <aa@google.com> wrote:
>>
>>> I don't care too much about the name. apps is fine, and your reasons
>>> are reasonable.
>>>
>>> As for top-level, the plan was to put apps in its own subdir of
>>> chrome/browser, then move to top-level as a second step. Do you want
>>> to go direct to top-level right from the beginning for some reason?
>>> (TBH, I was starting to think of doing that for extensions, just
>>> because I felt like it might make a cleaner separation between new,
>>> awesome and old, busted, but I'm not sure yet how realistic one big step
>>> is).
>>>
>>> - a
>>>
>>> On Mon, Nov 5, 2012 at 10:36 AM, Ben Goodger (Google) <ben@chromium.org>
>>> wrote:
>>> > So I have been talking with Darin about some of this stuff. I'm glad
>>> you're
>>> > working on it.
>>> >
>>> > I think we want to end up with the base of the app runtime living
>>> outside of
>>> > src/chrome. The reason is that you should think of Chrome (long term)
>>> as an
>>> > app. Even though it is and will for the foreseeable future be
>>> implemented in
>>> > native code using stuff unavailable to apps it is very helpful to our
>>> > architecture if you think of the apps stuff as above Chrome.
>>> >
>>> > For example, for Ash we should be able to build and run apps in the
>>> test Ash
>>> > shell exe independent of Chrome.
>>> >
>>> > I don't really think "platform apps" is any less vague, given the
>>> various
>>> > meanings and parts of the word "platform". It certainly is a lot more
>>> > characters to type. I think the project is also suffering from too many
>>> > names: Platform Apps, Apps V2, Apps, etc. It's hard to keep them all
>>> > straight! I had discussed with Darin a toplevel dir: src/apps which
>>> has a
>>> > very concise ring to it. WDYT?
>>> >
>>> > -Ben
>>> >
>>> >
>>> > On Sun, Nov 4, 2012 at 10:50 PM, <benwells@chromium.org> wrote:
>>> >>
>>> >> With platform_apps instead of apps
>>> >>
>>> >> http://codereview.chromium.org/11293087/
>>> >
>>> >
>>>
>>
>>
>

[aa, 2012-11-06 05:15:21]

>> On Mon, Nov 5, 2012 at 12:55 PM, Ben Goodger (Google) <ben@chromium.org>
>>> There have been requests from developers to add extension apis to
>>> toplevel components other than chrome - e.g. an extension api for src/ash
>>> that allows for window manager tweaks. To support that case it sounded like
>>> the concept of an extension and the ability to define an extension API were
>>> the bits that sound be extracted, while src/chrome would retain all the
code
>>> related to apis for specific browser features.

Yes, that is our plan.

- a

[tfarina, 2013-01-18 15:45:15]

https://codereview.chromium.org/11293087/diff/4001/chrome/browser/platform_ap...
File chrome/browser/platform_apps/OWNERS (right):

https://codereview.chromium.org/11293087/diff/4001/chrome/browser/platform_ap...
chrome/browser/platform_apps/OWNERS:1: # Core extension team members. Specific
extension APIs may have other authors
looks like you forgot to update this comment?

https://codereview.chromium.org/11293087/diff/4001/chrome/browser/platform_ap...
chrome/browser/platform_apps/OWNERS:10: aa@chromium.org
should all these people be the owner of platform_apps?

[benwells, 2013-01-20 23:03:19]

On 2013/01/18 15:45:15, tfarina wrote:
>
https://codereview.chromium.org/11293087/diff/4001/chrome/browser/platform_ap...
> File chrome/browser/platform_apps/OWNERS (right):
> 
>
https://codereview.chromium.org/11293087/diff/4001/chrome/browser/platform_ap...
> chrome/browser/platform_apps/OWNERS:1: # Core extension team members. Specific
> extension APIs may have other authors
> looks like you forgot to update this comment?
> 
>
https://codereview.chromium.org/11293087/diff/4001/chrome/browser/platform_ap...
> chrome/browser/platform_apps/OWNERS:10: mailto:aa@chromium.org
> should all these people be the owner of platform_apps?

Good question. I've closed this issue as it is out of date, there is another
issue up to create a top level apps folder (i.e. not in chrome/browser)
https://codereview.chromium.org/11829055/. I haven't put an OWNERS in that yet,
I was planning to do that in a CL by itself so we could discuss who should go in
it.