Agree with @sbesson; I would probably not create a separate view for retrieving externalInfo, but get it with the other object details on an existing call. Any performance hit should be minimal compared to having a whole separate call.

@sbesson This is now deployed on idr-testing. e.g. https://idr-testing.openmicroscopy.org/webclient/?show=image-15160031

As a quick sidenote before I disappear for a week, I'd be more than happy if we hide the acronym "LSID" from users.

👍 Looks good to me. What does LSID actually stand for, and what is the ExternalInfo actually used for generally @joshmoore ?

LSID stands for "Life Science Identifier". https://www.lsid.info/ et al. https://zenodo.org/records/46804 is a pretty good read.

The ExternalInfo object wasn't used a lot previously but was intended to hold info of the objects that felt "too detailed" to expose in the main object. It also helps that if you have an opaque identifier that you don't have to check every table to find the object but you can look in the one external info table.

https://en.wikipedia.org/wiki/LSID.
@joshmoore "Hide LSID from users" - what about CLI users? - in ome/omero-cli-zarr#167 we have --lsid and in general we try to make the UI reflect the data model.

Do we use another term or just e.g.

http://path/to/my/image.zarr
entityType: com.glencoesoftware.ngff.multiscales
entityId: 3

in general we try to make the UI reflect the data model.

"Attribues"? "Attachments"? 😄

what about CLI users?

I certainly worry about CLI users less.

But if we need to keep it, that's fine, just more than the other terms, "LSID" was a mistake.

As discussed in web meeting, we probably don't want ExternalInfo to be so much "in your face" since it's not of interest to most users.
Could look at hiding it under ../../ or elsewhere.

Deployed latest changes to idr-testing and updated screenshot above.

To help testing, you can now set ExternalInfo via the CLI - see ome/omero-py#453

In IDR (and regular OMERO if/when omero-zarr-pixel-buffer becomes adopted) we want it to be nice and easy for a user to get the OME-Zarr URL for an image they are looking at, as they can do for e.g. https://idr.github.io/ome-ngff-samples/.

We probably don't want to show "External Info" or com.glencoesoftware.ngff.multiscales but for Images where the extInfo EntityType is com.glencoesoftware.ngff.multiscales, we should show the OME-Zarr URL with a handy "copy to clipboard" button.
This could be in addition to the ExternalInfo display as above, which would support all Objects (not just images) and other EntityTypes.

As discussed in web meeting today:

• Exposing externalInfo to users is not useful in IDR since this is a path/to/zarr rather than a public s3.
• It is only useful for debugging etc, so let's hide it with a .debug: {display: none} css then we can easily show all such UI elements with:

$(‘.debug’).show()

As discussed with @jburel...

Since we have addressed s3 backend issues in omero-zarr-pixel-buffer, we can expect to use genuine public URLs for external-info, so this should be easier for the user to find.

This also gives us the chance to add "Open with" various zarr viewers.
However, the stored externalInfo lsid doesn't include endpoint info. E.g. s3://uk1s3.embassy.ebi.ac.uk/idr/zarr/v0.4/idr0062A/6001240.zarr/?anonymous=true can't be used in web based viewers. Instead we need e.g. https://uk1s3.embassy.ebi.ac.uk/idr/zarr/v0.4/idr0062A/6001240.zarr. Can we assume that we just replace s3 with https to get this URL (and remove ?anonymous=true)?

Note that everything that is discussed is conditional to the fact the externalInfo:
1- is of the correct entityType and entityId
2- is pointing at a remote resource rather than a local path

However, the stored externalInfo lsid doesn't include endpoint info. E.g. s3://uk1s3.embassy.ebi.ac.uk/idr/zarr/v0.4/idr0062A/6001240.zarr/?anonymous=true can't be used in web based viewers

Not sure I understand. Unlike the s3://<bucket>/<prefix> URI used e.g. by tools like the AWS CLI, to be usable by omero-zarr-pixel-buffer, the externalinfo.lsid must include an endpoint after s3://

Can we assume that we just replace s3 with https to get this URL

At least, this should be correct for Amazon S3. The service supports to types of requests: Path-style requests and Virtual-hosted–style requests. So https://s3.<region-code>.amazonaws.com/<bucket-name>/<zarr_prefix> is a valid path-style request.
Other S3 compatible object stores might behave differently.

and remove ?anonymous=true

If the intent is to create an HTTP URL using by any a third-party application, then such transformation is probably only applicable to public data. No query parameter in a S3 lsid value indicates that credentials are expected to read the data.

@will-moore we cannot change the value to https or remove anonymous as @sbesson indicated.

We only discussed showing external info to help identifying the "registered" one not reformatting it. to use it in the web, the application will need to parse it

I understand that omero-web will need to parse it - I'm just asking if it will always work to replace s3 with https?
That's what I've implemented above and it seems to work for various lsids.

I'm just asking if it will always work to replace s3 with https?

Definitely not in the general case.