(web) service revision - add ServiceLinkPattern schema?

[apdavison]

This would support auto-generating service links.

cf ContentTypePattern, FilePathPattern, FileRepositoryStructure

[lzehl]

@apdavison not a bad idea. those would need to be attached to the (web) service version. should be optional (in case services do not have a proper pattern)

[lzehl]

To make this more concrete for a discussion:

Option A: A ServiceLinkPattern schema could have the following properties, if it would be linked from a FileRepository under the property "serviceLinkPattern":

• sourceFileNamePattern (regex for the URL (?) of the file/file bundle that can be opened in the service)
• linkPattern (regex for the URL that shows the connected file/file bundle in the service)
• service (link to the WebServiceVersion)

I'm not sure though if it is smart to link it to the data repository.

Option B: A ServiceLinkPattern schema could have the following properties, if it would be linked from a WebServiceVersion under the property "serviceLinkPattern":

• sourceFileRepository (URL to the source file repo or link to the FileRepository)
• sourceFileNamePattern (regex for the URL (?) of the file/file bundle that can be opened in the service)
• linkPattern (regex for the URL that shows the connected file/file bundle in the service)

Option C: A ServiceLinkPattern schema could have the following properties, if it would be linked to a WebServiceVersion and relevant repos:

• service (URL to the source file repo or link to the WebServiceVersion)
• sourceFileRepository (URL to the source file repo or link to the FileRepository)
• sourceFileNamePattern (regex for the URL (?) of the file/file bundle that can be opened in the service)
• linkPattern (regex for the URL that shows the connected file/file bundle in the service)

Note that a WebServiceVersion could have 1-N ServiceLinkPattern (as many as there are file repos)

[lzehl]

based on the dev meeting discussion: maybe option C for maintenance reasons.

[lzehl]

Making this more concrete:

NEW ServiceLinkPattern schema:

• service (1, required, linked type: Service; instruction: "Add the service for which this service link pattern applies.")
• sourceFileRepository (1, required, linked type: FileRepository; instruction: "Add the file repository on which this service link pattern should be applied.")
• sourceFileNamePattern (1, required, string, regex (format: ECMA 262); instruction: "Enter the regular expression pattern of the source files that should receive a service link.")
• linkPattern (1, required, string, regex (format: ECMA 262); instruction: "Enter the regular expression pattern of the service link for the identified files.")

@apdavison @olinux not sure if the service needs to be linked or rather the deployment of the service. I'm also not sure if the combination of sourceFileNamePattern and linkPattern would really work. I think this would only cover a very specific use case of how to design service links where components of the filenames are used to create the service link. As soon as files would receive an additional identifier (e.g. an UUID) this approach would fail.

[olinux]

This indeed would only work for those cases where the service does not do any indirection unless we add the possibility to extract other information than just the sourceFileName. The latter might easily become rather difficult though tbh.

However, the approach itself is interesting. I would expect a regex group pattern in the sourceFileNamePattern and a replacement pattern with backreferences:

sourceFileNamePattern: "./somepath/([a-zA-Z0-9]).fooBar"
linkPattern: "https://myservice.com/files/$1/show"

[lzehl]

okay. let's keep this and find a robust solution for this in the next release round