Service manifest file structure changes

[Oksana Zhuravlova]

Hello all,

Today the first part of the changes related to 'magic capabilities' of service manager (https://crbug.com/866967) was merged:

https://crrev.com/c/1195892

Now when adding a new service, if it needs the functionality that was earlier provided by "service_manager:singleton" or "service_manager:all_users" capabilities, the new "options" field should be used instead:

"options" : {

  "instance_sharing" : "singleton"

}

or

"options" : {

  "instance_sharing" : "shared_instance_across_users"

}

More info at https://docs.google.com/document/d/1oJlia1IEakAjH-NGh51gK2bXVAwS2SDxmNE6hjJ_BVc/

More code updates to follow.

Thanks!

[Scott Violet]

Interesting.

On a some what related topic, I'm wondering if we've considered moving manifests to a format that is generated from actual code? That the current manifests are not code has the typical non-code problems: tooling support is weak (for example, code search), easy to get out of date, syntax is mildly tricky, and the most important, easy to break without realizing until you run actual tests.

No doubt moving to actual code would entail it's own set of woes, but my instinct tells me it would be for the better.

  -Scott

--
You received this message because you are subscribed to the Google Groups "services-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to services-dev...@chromium.org.
To post to this group, send email to servic...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/services-dev/CAMjqXc5Q%2BPLGEmqyLRvyC0ZL_iFdapQgQbOxeTR96kV20FvR2A%40mail.gmail.com.

[Ken Rockot]

On Fri, Aug 31, 2018 at 6:04 PM Scott Violet <s...@chromium.org> wrote:

Interesting.

On a some what related topic, I'm wondering if we've considered moving manifests to a format that is generated from actual code? That the current manifests are not code has the typical non-code problems: tooling support is weak (for example, code search), easy to get out of date, syntax is mildly tricky, and the most important, easy to break without realizing until you run actual tests.

No doubt moving to actual code would entail it's own set of woes, but my instinct tells me it would be for the better.

Yeah this is something we've considered. The reason it hasn't happened is that there is still some accounting for a future where services  will be distributed independently from the browser/service-manage runtimeI In that case, it's useful to have the manifest expressed in a way that the service manager can authoritatively discover and process on its own, e.g. by reading the filesystem.

We could say, well, we don't do that now, so let's convert manifests to code and add dynamic service support only once we need it.   That's a big change though, and I don't believe the improvement for developers would be that significant after all.

  -Scott

On Thu, Aug 30, 2018 at 7:54 PM Oksana Zhuravlova <oks...@chromium.org> wrote:

Hello all,

Today the first part of the changes related to 'magic capabilities' of service manager (https://crbug.com/866967) was merged:

https://crrev.com/c/1195892

Now when adding a new service, if it needs the functionality that was earlier provided by "service_manager:singleton" or "service_manager:all_users" capabilities, the new "options" field should be used instead:

"options" : {

  "instance_sharing" : "singleton"

}

or

"options" : {

  "instance_sharing" : "shared_instance_across_users"

}

More info at https://docs.google.com/document/d/1oJlia1IEakAjH-NGh51gK2bXVAwS2SDxmNE6hjJ_BVc/

More code updates to follow.

Thanks!

--
You received this message because you are subscribed to the Google Groups "services-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to services-dev...@chromium.org.
To post to this group, send email to servic...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/services-dev/CAMjqXc5Q%2BPLGEmqyLRvyC0ZL_iFdapQgQbOxeTR96kV20FvR2A%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "services-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to services-dev...@chromium.org.
To post to this group, send email to servic...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/services-dev/CAKARY_m4R8FokpdZtEKHyVzRHrcKSsK3RgednY%3D7bp5S10KWZw%40mail.gmail.com.

[Robert Sesek]

To raise a counterpoint: it is far easier to write tooling over JSON (like the Mojo visualizer I've been working on for the Security Team) rather than code. If we switched to fully declaring services and capabilities in code, then we'd basically need a Clang plugin to produce the same results.

Also, is it possible to make the doc linked in the OP open to the public?

rsesek / @chromium.org

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/services-dev/CAKARY_m4R8FokpdZtEKHyVzRHrcKSsK3RgednY%3D7bp5S10KWZw%40mail.gmail.com.

[Scott Violet]

On Fri, Aug 31, 2018 at 9:39 AM Ken Rockot <roc...@chromium.org> wrote:

On Fri, Aug 31, 2018 at 6:04 PM Scott Violet <s...@chromium.org> wrote:

Interesting.

On a some what related topic, I'm wondering if we've considered moving manifests to a format that is generated from actual code? That the current manifests are not code has the typical non-code problems: tooling support is weak (for example, code search), easy to get out of date, syntax is mildly tricky, and the most important, easy to break without realizing until you run actual tests.

No doubt moving to actual code would entail it's own set of woes, but my instinct tells me it would be for the better.

Yeah this is something we've considered. The reason it hasn't happened is that there is still some accounting for a future where services  will be distributed independently from the browser/service-manage runtimeI In that case, it's useful to have the manifest expressed in a way that the service manager can authoritatively discover and process on its own, e.g. by reading the filesystem.

We could always support two. Chrome code would use actual code. For dynamically updated services we could support the existing file format.

  -Scott

[Scott Violet]

I think there are other ways to address the tooling side of things that wouldn't require a plugin.

  -Scott

[Oksana Zhuravlova]

Hello Robert,

I'm not sure if any information in the document (and the template) is confidential/sensitive. Also, I haven't found a way to publicly share a document.

Thanks!

On Fri, Aug 31, 2018 at 9:46 AM Robert Sesek <rse...@chromium.org> wrote:

[Oksana Zhuravlova]

Hello all,

The documentation page for service options is now available at

https://chromium.googlesource.com/chromium/src/+/master/services/service_manager/service_manifests.md

While it has short descriptions of all manifest fields, the main focus was on the options.

Thanks!

[Colin Blundell]

This is great, Oksana! Thank you!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/services-dev/CAMjqXc5px_%2BdUwukxhv%3DGymnpr4kvy52KS69aJX-xBQ2FVbG2A%40mail.gmail.com.