Worklet: Move WorkletScriptLoader from MainThreadWorklet to MainThreadWorkletGlobalScope

Worklet: Move WorkletScriptLoader from MainThreadWorklet to MainThreadWorkletGlobalScope

This is a preparation CL for introducing module loading for MainThreadWorklet
(i.e., PaintWorklet). ThreadedWorklet is out of the scope for now.

According to the "fetch and invoke a worklet script" algorithm defined in the
Worklet spec[1], worklet script fetch is supposed to be conducted in the worklet
global scope execution environment (i.e., WorkletGlobalScope). However, in the
current implementation, the algorithm is partially implemented on Worklet class
that exists in document execution environment. This doesn't match the spec.

To fix it, this CL moves WorkletScriptLoader from MainThreadWorklet to
MainThreadWorkletGlobalScope. This should not change the behavior.

[1] https://drafts.css-houdini.org/worklets/#fetch-and-invoke-a-worklet-script

BUG=627945
Review-Url: https://codereview.chromium.org/2830603003
Cr-Commit-Position: refs/heads/master@{#466543}
Committed: https://chromium.googlesource.com/chromium/src/+/bd57430f53d31aa3ca7c4c28f7189667feb04908

[nhiroki, 2017-04-19 07:25:18]

Description was changed from

==========
Worklet: Move loader code from MainThreadWorklet to MainThreadWorkletGlobalScope

According to the Worklet spec, "fetch and invole a worklet script" algorithm[1]
is to be run within the worklet global scope execution environment. However, the
current implementation of the algorithm is partially tied with the Worklet
object (e.g., WorkletScriptLoader is owned by the Worklet obejct).

[1] https://drafts.css-houdini.org/worklets/#fetch-and-invoke-a-worklet-script

To improve spec conformance and prepare for introducing module loading for main
thread worklets, this CL moves the parts to MainThreadWorkletGlobalScope from
MainThreadWorklet.

[Class relation]

                   ---<WorkletGlobalScopeProxy>-->
MainThreadWorklet                                  MainThreadWorkletGlobalScope
                   <----<WorkletObjectProxy>------

BUG=627945
==========

to

==========
Worklet: Move loader code from MainThreadWorklet to MainThreadWorkletGlobalScope

According to the Worklet spec, "fetch and invoke a worklet script" algorithm[1]
is to be run within the worklet global scope execution environment. However, the
current implementation of the algorithm is partially tied with the Worklet
object (e.g., WorkletScriptLoader is owned by the Worklet obejct).

[1] https://drafts.css-houdini.org/worklets/#fetch-and-invoke-a-worklet-script

To improve spec conformance and prepare for introducing module loading for main
thread worklets, this CL moves the parts to MainThreadWorkletGlobalScope from
MainThreadWorklet.

[Class relation]

                   ---<WorkletGlobalScopeProxy>-->
MainThreadWorklet                                  MainThreadWorkletGlobalScope
                   <----<WorkletObjectProxy>------

BUG=627945
==========

[nhiroki, 2017-04-19 07:37:20]

Description was changed from

==========
Worklet: Move loader code from MainThreadWorklet to MainThreadWorkletGlobalScope

According to the Worklet spec, "fetch and invoke a worklet script" algorithm[1]
is to be run within the worklet global scope execution environment. However, the
current implementation of the algorithm is partially tied with the Worklet
object (e.g., WorkletScriptLoader is owned by the Worklet obejct).

[1] https://drafts.css-houdini.org/worklets/#fetch-and-invoke-a-worklet-script

To improve spec conformance and prepare for introducing module loading for main
thread worklets, this CL moves the parts to MainThreadWorkletGlobalScope from
MainThreadWorklet.

[Class relation]

                   ---<WorkletGlobalScopeProxy>-->
MainThreadWorklet                                  MainThreadWorkletGlobalScope
                   <----<WorkletObjectProxy>------

BUG=627945
==========

to

==========
Worklet: Move loader code from MainThreadWorklet to MainThreadWorkletGlobalScope

According to the Worklet spec, "fetch and invoke a worklet script" algorithm[1]
is to be run within the worklet global scope execution environment. However,
currently the algorithm is partially implemented in Worklet class in owner
document's execution environment.

To fix it, this CL moves WorkletScriptLoader from MainThreadWorklet to
MainThreadWorkletGlobalScope, and introduces WorkletObjectProxy to communicate
from MainThreadWorkletGlobalScope to MainThreadWorklet as follows:

                  ---<WorkletGlobalScopeProxy>-->
MainThreadWorklet                                 MainThreadWorkletGlobalScope
                  <----<WorkletObjectProxy>------

[1] https://drafts.css-houdini.org/worklets/#fetch-and-invoke-a-worklet-script

BUG=627945
==========

[nhiroki, 2017-04-19 07:40:48]

Description was changed from

==========
Worklet: Move loader code from MainThreadWorklet to MainThreadWorkletGlobalScope

According to the Worklet spec, "fetch and invoke a worklet script" algorithm[1]
is to be run within the worklet global scope execution environment. However,
currently the algorithm is partially implemented in Worklet class in owner
document's execution environment.

To fix it, this CL moves WorkletScriptLoader from MainThreadWorklet to
MainThreadWorkletGlobalScope, and introduces WorkletObjectProxy to communicate
from MainThreadWorkletGlobalScope to MainThreadWorklet as follows:

                  ---<WorkletGlobalScopeProxy>-->
MainThreadWorklet                                 MainThreadWorkletGlobalScope
                  <----<WorkletObjectProxy>------

[1] https://drafts.css-houdini.org/worklets/#fetch-and-invoke-a-worklet-script

BUG=627945
==========

to

==========
Worklet: Move loader code from MainThreadWorklet to MainThreadWorkletGlobalScope

According to the Worklet spec ("fetch and invoke a worklet script"
algorithm[1]),
script fetch is initiated in the worklet global scope execution environment
(ie.,
WorkletGlobalScope). However, in the current implementation, it's implemented in
Worklet class in owner document execution environment.

To fix it, this CL moves WorkletScriptLoader from MainThreadWorklet to
MainThreadWorkletGlobalScope, and introduces WorkletObjectProxy to communicate
from MainThreadWorkletGlobalScope to MainThreadWorklet as follows:

                  ---<WorkletGlobalScopeProxy>-->
MainThreadWorklet                                 MainThreadWorkletGlobalScope
                  <----<WorkletObjectProxy>------

[1] https://drafts.css-houdini.org/worklets/#fetch-and-invoke-a-worklet-script

BUG=627945
==========

[nhiroki, 2017-04-19 07:46:08]

Description was changed from

==========
Worklet: Move loader code from MainThreadWorklet to MainThreadWorkletGlobalScope

According to the Worklet spec ("fetch and invoke a worklet script"
algorithm[1]),
script fetch is initiated in the worklet global scope execution environment
(ie.,
WorkletGlobalScope). However, in the current implementation, it's implemented in
Worklet class in owner document execution environment.

To fix it, this CL moves WorkletScriptLoader from MainThreadWorklet to
MainThreadWorkletGlobalScope, and introduces WorkletObjectProxy to communicate
from MainThreadWorkletGlobalScope to MainThreadWorklet as follows:

                  ---<WorkletGlobalScopeProxy>-->
MainThreadWorklet                                 MainThreadWorkletGlobalScope
                  <----<WorkletObjectProxy>------

[1] https://drafts.css-houdini.org/worklets/#fetch-and-invoke-a-worklet-script

BUG=627945
==========

to

==========
Worklet: Move loader code from MainThreadWorklet to MainThreadWorkletGlobalScope

According to the "fetch and invoke a worklet script" algorithm defined in the
Worklet spec[1], worklet script fetch is supposed to be conducted in the worklet
global scope execution environment (i.e., WorkletGlobalScope). However, in the
current implementation, the algorithm is implemented on Worklet class in owner
document execution environment. This doesn't match with the spec.

To fix it, this CL moves WorkletScriptLoader from MainThreadWorklet to
MainThreadWorkletGlobalScope.

[1] https://drafts.css-houdini.org/worklets/#fetch-and-invoke-a-worklet-script

BUG=627945
==========

[nhiroki, 2017-04-19 09:34:32]

The CQ bit was checked by nhiroki@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-19 09:35:03]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[nhiroki, 2017-04-19 09:45:17]

The CQ bit was checked by nhiroki@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-19 09:45:59]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[nhiroki, 2017-04-19 09:49:26]

The CQ bit was checked by nhiroki@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-19 09:49:47]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[nhiroki, 2017-04-19 10:19:23]

Patchset #1 (id:1) has been deleted

[nhiroki, 2017-04-19 10:19:50]

Patchset #1 (id:20001) has been deleted

[nhiroki, 2017-04-19 10:23:09]

Description was changed from

==========
Worklet: Move loader code from MainThreadWorklet to MainThreadWorkletGlobalScope

According to the "fetch and invoke a worklet script" algorithm defined in the
Worklet spec[1], worklet script fetch is supposed to be conducted in the worklet
global scope execution environment (i.e., WorkletGlobalScope). However, in the
current implementation, the algorithm is implemented on Worklet class in owner
document execution environment. This doesn't match with the spec.

To fix it, this CL moves WorkletScriptLoader from MainThreadWorklet to
MainThreadWorkletGlobalScope.

[1] https://drafts.css-houdini.org/worklets/#fetch-and-invoke-a-worklet-script

BUG=627945
==========

to

==========
Worklet: Move WorkletScriptLoader from MainThreadWorklet to
MainThreadWorkletGlobalScope

According to the "fetch and invoke a worklet script" algorithm defined in the
Worklet spec[1], worklet script fetch is supposed to be conducted in the worklet
global scope execution environment (i.e., WorkletGlobalScope). However, in the
current implementation, the algorithm is partially implemented on Worklet class
that exists in document execution environment. This doesn't match the spec.

To fix it, this CL moves WorkletScriptLoader from MainThreadWorklet to
MainThreadWorkletGlobalScope.

[1] https://drafts.css-houdini.org/worklets/#fetch-and-invoke-a-worklet-script

BUG=627945
==========

[nhiroki, 2017-04-19 10:23:32]

Description was changed from

==========
Worklet: Move WorkletScriptLoader from MainThreadWorklet to
MainThreadWorkletGlobalScope

According to the "fetch and invoke a worklet script" algorithm defined in the
Worklet spec[1], worklet script fetch is supposed to be conducted in the worklet
global scope execution environment (i.e., WorkletGlobalScope). However, in the
current implementation, the algorithm is partially implemented on Worklet class
that exists in document execution environment. This doesn't match the spec.

To fix it, this CL moves WorkletScriptLoader from MainThreadWorklet to
MainThreadWorkletGlobalScope.

[1] https://drafts.css-houdini.org/worklets/#fetch-and-invoke-a-worklet-script

BUG=627945
==========

to

==========
Worklet: Move WorkletScriptLoader from MainThreadWorklet to
MainThreadWorkletGlobalScope

According to the "fetch and invoke a worklet script" algorithm defined in the
Worklet spec[1], worklet script fetch is supposed to be conducted in the worklet
global scope execution environment (i.e., WorkletGlobalScope). However, in the
current implementation, the algorithm is partially implemented on Worklet class
that exists in document execution environment. This doesn't match the spec.

To fix it, this CL moves WorkletScriptLoader from MainThreadWorklet to
MainThreadWorkletGlobalScope.

[1] https://drafts.css-houdini.org/worklets/#fetch-and-invoke-a-worklet-script

BUG=627945
==========

[nhiroki, 2017-04-19 10:23:39]

Patchset #1 (id:40001) has been deleted

[nhiroki, 2017-04-19 10:28:01]

Description was changed from

==========
Worklet: Move WorkletScriptLoader from MainThreadWorklet to
MainThreadWorkletGlobalScope

According to the "fetch and invoke a worklet script" algorithm defined in the
Worklet spec[1], worklet script fetch is supposed to be conducted in the worklet
global scope execution environment (i.e., WorkletGlobalScope). However, in the
current implementation, the algorithm is partially implemented on Worklet class
that exists in document execution environment. This doesn't match the spec.

To fix it, this CL moves WorkletScriptLoader from MainThreadWorklet to
MainThreadWorkletGlobalScope.

[1] https://drafts.css-houdini.org/worklets/#fetch-and-invoke-a-worklet-script

BUG=627945
==========

to

==========
Worklet: Move WorkletScriptLoader from MainThreadWorklet to
MainThreadWorkletGlobalScope

This is a preparation CL for introducing module loading for MainThreadWorklet
(i.e., PaintWorklet). ThreadedWorklet is out of the scope for now.

According to the "fetch and invoke a worklet script" algorithm defined in the
Worklet spec[1], worklet script fetch is supposed to be conducted in the worklet
global scope execution environment (i.e., WorkletGlobalScope). However, in the
current implementation, the algorithm is partially implemented on Worklet class
that exists in document execution environment. This doesn't match the spec.

To fix it, this CL moves WorkletScriptLoader from MainThreadWorklet to
MainThreadWorkletGlobalScope.

[1] https://drafts.css-houdini.org/worklets/#fetch-and-invoke-a-worklet-script

BUG=627945
==========

[nhiroki, 2017-04-19 10:28:17]

nhiroki@chromium.org changed reviewers:
+ kouhei@chromium.org, yhirano@chromium.org

[nhiroki, 2017-04-19 10:28:18]

PTAL, thanks!

[commit-bot: I haz the power, 2017-04-19 11:12:09]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-04-19 11:12:10]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[nhiroki, 2017-04-21 04:23:53]

Description was changed from

==========
Worklet: Move WorkletScriptLoader from MainThreadWorklet to
MainThreadWorkletGlobalScope

This is a preparation CL for introducing module loading for MainThreadWorklet
(i.e., PaintWorklet). ThreadedWorklet is out of the scope for now.

According to the "fetch and invoke a worklet script" algorithm defined in the
Worklet spec[1], worklet script fetch is supposed to be conducted in the worklet
global scope execution environment (i.e., WorkletGlobalScope). However, in the
current implementation, the algorithm is partially implemented on Worklet class
that exists in document execution environment. This doesn't match the spec.

To fix it, this CL moves WorkletScriptLoader from MainThreadWorklet to
MainThreadWorkletGlobalScope.

[1] https://drafts.css-houdini.org/worklets/#fetch-and-invoke-a-worklet-script

BUG=627945
==========

to

==========
Worklet: Move WorkletScriptLoader from MainThreadWorklet to
MainThreadWorkletGlobalScope

This is a preparation CL for introducing module loading for MainThreadWorklet
(i.e., PaintWorklet). ThreadedWorklet is out of the scope for now.

According to the "fetch and invoke a worklet script" algorithm defined in the
Worklet spec[1], worklet script fetch is supposed to be conducted in the worklet
global scope execution environment (i.e., WorkletGlobalScope). However, in the
current implementation, the algorithm is partially implemented on Worklet class
that exists in document execution environment. This doesn't match the spec.

To fix it, this CL moves WorkletScriptLoader from MainThreadWorklet to
MainThreadWorkletGlobalScope. This should not change the behavior.

[1] https://drafts.css-houdini.org/worklets/#fetch-and-invoke-a-worklet-script

BUG=627945
==========

[nhiroki, 2017-04-21 04:26:39]

nhiroki@chromium.org changed reviewers:
+ haraken@chromium.org

[nhiroki, 2017-04-21 04:26:39]

(kouhei is ooo and yhirano looks super busy)

+haraken, do you think you can review this?

[yhirano, 2017-04-21 04:43:27]

Sorry for the late response.
I'm less busy than haraken :)

https://codereview.chromium.org/2830603003/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/workers/WorkletObjectProxy.h (right):

https://codereview.chromium.org/2830603003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/workers/WorkletObjectProxy.h:17: class
CORE_EXPORT WorkletObjectProxy : public GarbageCollectedMixin {
It looks you don't handle evalucation failures. Can you tell me why we need two
separate functions (DidFetchModule and DidEvaluateModule) rather than one?

https://codereview.chromium.org/2830603003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/workers/WorkletObjectProxy.h:21: virtual void
DidFetchModule(int request_id, bool success) = 0;
int32_t?

Can we have a typedef name instead?

https://codereview.chromium.org/2830603003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/workers/WorkletObjectProxy.h:24: virtual void
DidEvaluateModule(int request_id) = 0;
ditto

[nhiroki, 2017-04-21 07:43:15]

The CQ bit was checked by nhiroki@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-21 07:43:27]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[nhiroki, 2017-04-21 07:58:50]

Thank you! Updated.

https://codereview.chromium.org/2830603003/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/workers/WorkletObjectProxy.h (right):

https://codereview.chromium.org/2830603003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/workers/WorkletObjectProxy.h:17: class
CORE_EXPORT WorkletObjectProxy : public GarbageCollectedMixin {
On 2017/04/21 04:43:27, yhirano wrote:
> It looks you don't handle evalucation failures. Can you tell me why we need
two
> separate functions (DidFetchModule and DidEvaluateModule) rather than one?

Yeah, only one notification interface would be simpler. Merged them.

https://codereview.chromium.org/2830603003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/workers/WorkletObjectProxy.h:21: virtual void
DidFetchModule(int request_id, bool success) = 0;
On 2017/04/21 04:43:27, yhirano wrote:
> int32_t?

Done.

> Can we have a typedef name instead?

I'd prefer to keep int32_t for now because we may need to propagate it to
core/loader/modulescript in following CLs, and I'm not really sure where we
should put the typedef at this point.

https://codereview.chromium.org/2830603003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/workers/WorkletObjectProxy.h:24: virtual void
DidEvaluateModule(int request_id) = 0;
On 2017/04/21 04:43:27, yhirano wrote:
> ditto

Removed this function.

[nhiroki, 2017-04-21 08:00:17]

On 2017/04/21 04:43:27, yhirano wrote:
> Sorry for the late response.
> I'm less busy than haraken :)

Np! I noticed I need haraken@'s review for modules/ anyway :)

[yhirano, 2017-04-21 08:55:51]

lgtm

https://codereview.chromium.org/2830603003/diff/90001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/workers/MainThreadWorkletGlobalScope.cpp
(right):

https://codereview.chromium.org/2830603003/diff/90001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/workers/MainThreadWorkletGlobalScope.cpp:71: for
(auto script_loader : loader_set_)
const auto&

[commit-bot: I haz the power, 2017-04-21 09:51:53]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-04-21 09:51:54]

Dry run: This issue passed the CQ dry run.

[haraken, 2017-04-21 10:00:36]

LGTM

(Sorry I'm in a EMEA timezone.)

[nhiroki, 2017-04-22 02:37:14]

Thank you!

https://codereview.chromium.org/2830603003/diff/90001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/workers/MainThreadWorkletGlobalScope.cpp
(right):

https://codereview.chromium.org/2830603003/diff/90001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/workers/MainThreadWorkletGlobalScope.cpp:71: for
(auto script_loader : loader_set_)
On 2017/04/21 08:55:51, yhirano wrote:
> const auto&

Done.

[nhiroki, 2017-04-22 02:37:20]

The CQ bit was checked by nhiroki@chromium.org

[nhiroki, 2017-04-22 02:37:21]

The patchset sent to the CQ was uploaded after l-g-t-m from
haraken@chromium.org, yhirano@chromium.org
Link to the patchset: https://codereview.chromium.org/2830603003/#ps130001
(title: "const auto&")

[commit-bot: I haz the power, 2017-04-22 02:37:35]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-22 04:45:33]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-04-22 04:45:34]

Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[nhiroki, 2017-04-22 06:57:21]

The CQ bit was checked by nhiroki@chromium.org

[commit-bot: I haz the power, 2017-04-22 06:57:27]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-22 19:15:59]

CQ is committing da patch.

Bot data: {"patchset_id": 130001, "attempt_start_ts": 1492844241700000,
"parent_rev": "892edbbf57698e574b6b2b15481239af1c5c4ede", "commit_rev":
"bd57430f53d31aa3ca7c4c28f7189667feb04908"}

[commit-bot: I haz the power, 2017-04-22 19:16:13]

Description was changed from

==========
Worklet: Move WorkletScriptLoader from MainThreadWorklet to
MainThreadWorkletGlobalScope

This is a preparation CL for introducing module loading for MainThreadWorklet
(i.e., PaintWorklet). ThreadedWorklet is out of the scope for now.

According to the "fetch and invoke a worklet script" algorithm defined in the
Worklet spec[1], worklet script fetch is supposed to be conducted in the worklet
global scope execution environment (i.e., WorkletGlobalScope). However, in the
current implementation, the algorithm is partially implemented on Worklet class
that exists in document execution environment. This doesn't match the spec.

To fix it, this CL moves WorkletScriptLoader from MainThreadWorklet to
MainThreadWorkletGlobalScope. This should not change the behavior.

[1] https://drafts.css-houdini.org/worklets/#fetch-and-invoke-a-worklet-script

BUG=627945
==========

to

==========
Worklet: Move WorkletScriptLoader from MainThreadWorklet to
MainThreadWorkletGlobalScope

This is a preparation CL for introducing module loading for MainThreadWorklet
(i.e., PaintWorklet). ThreadedWorklet is out of the scope for now.

According to the "fetch and invoke a worklet script" algorithm defined in the
Worklet spec[1], worklet script fetch is supposed to be conducted in the worklet
global scope execution environment (i.e., WorkletGlobalScope). However, in the
current implementation, the algorithm is partially implemented on Worklet class
that exists in document execution environment. This doesn't match the spec.

To fix it, this CL moves WorkletScriptLoader from MainThreadWorklet to
MainThreadWorkletGlobalScope. This should not change the behavior.

[1] https://drafts.css-houdini.org/worklets/#fetch-and-invoke-a-worklet-script

BUG=627945

Review-Url: https://codereview.chromium.org/2830603003
Cr-Commit-Position: refs/heads/master@{#466543}
Committed:
https://chromium.googlesource.com/chromium/src/+/bd57430f53d31aa3ca7c4c28f718...
==========

[commit-bot: I haz the power, 2017-04-22 19:16:14]

Committed patchset #5 (id:130001) as
https://chromium.googlesource.com/chromium/src/+/bd57430f53d31aa3ca7c4c28f718...