Why do we need some many hashed paths for the AppMeasurement.js | Community
Skip to main content
T
thomas_amsler
Level 6
March 12, 2019
Solved

Why do we need some many hashed paths for the AppMeasurement.js

  • March 12, 2019
  • 16 replies
  • 10919 views

Due to legal reasons we cannot use the CDN to get our launch scripts. So we download the generated files with the archive option in the environment. This was always a bit cumbersome because the top level paths always changed with each build and the inner path with each version of the AnalyticsExtension.

So we had something like this:

/BLe4b698d19ee94cf8b785407ccb4b97b1/hostedLibFiles/EP23d75a37c9fa4adb8bac5e48782e354a/AppMeasurement.js

Today I'v built the library again for dev using the latest extension version and the path exploded to this:

/CO43553243d83145ca9145261e586d2a23/PRc77ae538547743d6a733621fe60bd876/BLd0c019fe63cc434fad86cb9a55e49dc1/hostedLibFiles/EPd2399f7c689a4ae38db44080f8c6e80b/AppMeasurement.js

I assume all these hashed path will change with every build. So we have a, sorry me french, shitload of work each time we update our launch scripts. As we cannot simply extract the zip to an apache, we need to upload it into a CMS (even AEM) and recreate all this folders anew.

And as a side issue, even Windows (maybe the integrated ZIP) complains with too long paths when I try to extract it somewhere deeper then than one level below the disk.

Is this really neccessary or can this please be changed back? I don't care about these folders if I am not using a CDN, so we wouldn't need any hash at all; except for maybe caching reasons, but the top one would be enough for that.

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
    Best answer by thebenrobb

    We did decide to make a product change to shorten the hashes as well.  Instead of using IDs in the folder name, we've generated shorter tokens (still representing the same things of company, property, build, and extension) and using those instead.  This will not reduce the number of folders/hashes, but will greatly reduce their length.  We will also be better documenting the structure of those archive files explaining what is in them and why.

    16 replies

    Show previous replies
    giuseppes412756
    giuseppes412756
    June 25, 2019

    Thanks Rob. Would that ensure that it'll always stay under the 256 character length for any file to publish?

    T
    thomas_amslerAuthor
    Level 6
    June 25, 2019

    Thanks for the update, though I still hope a flat version will be provided in the future. Or an option to generate an AEM content package. Just to save us from manual tasks after each build.

    C
    charlk79482207
    June 25, 2019

    Thanks for the response, when would this be available?

    thebenrobb
    Adobe Employee
    thebenrobbAdobe Employee
    Adobe Employee
    June 27, 2019

    @giuseppes41275613

    Impossible for us to say for two reasons:

    1. We have a known folder structure, but we don't know where on your filesystem you're putting our file(s), so we can't know the overall length
    2. Extension developers can provide their own JavaScript files inside of their Extensions (with arbitrary names), and those will be included as well

    What I can tell you is that the longest possible paths we'll give would be:

    • 13 characters for the company token and a slash
    • 13 characters for the property token and a slash
    • 13 characters for the build token and a slash
    • 15 characters for "/hostedLibFiles"
    • 33 characters for the extension ID that is providing the hostedLibFile and a slash
    • the arbitrary number for the file name the extension developer provided which will obviously vary by which extensions you've installed

    Altogether that's 87 + the unknown length of any library files provided by extensions.  If we say 25 is a reasonable median (no idea if this is true), then you're looking at ~112.

    thebenrobb
    Adobe Employee
    thebenrobbAdobe Employee
    Adobe Employee
    June 27, 2019

    @charlk79482207

    Realistically, probably the 3rd or 4th week of July.  Code is written, but there's a company holiday for 5 days in July, and we're going to do significant testing with this change before release.

    jantzen_b
    Adobe Employee
    jantzen_bAdobe Employee
    Adobe Employee
    March 24, 2020
    Do any of the answers below answer your initial question? If so, can you select one of them as the correct answer? If none of the answers already provided answer your question, can you provide additional information to better help the community solve your question?
    Terms & ConditionsAccessibility statement

    Loading footer...