File handling approach is not "open"

[bigdoods]

Hi,

We are currently reviewing the openCDE-API spec to implement a client that interacts with multiple CDEs. Our client has no support for a UI which means that interacting with OpenCDE compliant APIs is not possible due to the current spec dependency on clients to support a UI e.g for selecting a document.

We think a pure HTTP request/response approach should be considered for development of the API. It would be great to hear thoughts on this.

[pasi-paasiala]

This is a conscious decision. We first implement this low hanging fruit. We have plans to think about the unmanned case also. The reason why we took this approach was that this way we can leave handling of meta data to the user.

[bigdoods]

To my mind, continuing with this approach would have the following outcomes for users:

1. Time intensive - Manual data entry is slow...
2. Error prone - Data entry is done manually by the user which creates an environment with a risk of data omissions, bad entry and inconsistencies.
3. Wasteful - Valuable metadata created upstream requires re-entry by user and has a high risk of being lost.
4. Poor automation capacity - Automation around a user case that requires user interface interaction is difficult.

I appreciate that this is just one aspect of the project and I am really looking forward to beginning with the server - server approach to this project. Hopefully this will be started at the Hackathon in Munich next week - I look forward to meeting you then! :)

[Moult]

I would agree with @bigdoods - the API should be designed in a manner that does not require a browser, nor a UI of any kind. The API should also be decoupled from the file transfer protocol.

Can we have an update on this issue?

[ykulbak]

@Moult the group is considering several different use cases for document exchange.

Currently there's an early draft for an interactive use case where a human, while using a tool such as model authoring software, wishes to upload or download documents from a cloud service. For this use case an approach that involves redirecting the user to the UI of the cloud service is valid and has the advantages of being simple and quick to implement while avoiding hard to solve problems such as document metadata standardisation.

Non-interactive use cases that allow periodic syncing between two systems are also considered. We are currently aware of two non-interactive use-cases:

1. Within a cross-vendor team: Connecting a WIP system with a SHARED/PUBLISHED/ARCHIVE system
2. Across the project lifecycle: Transferring documents from a DESIGN system to a BUILD system or from a BUILD system to an OPERATE system.
   I believe that yourself and @bigdoods would like to see progress on the non-interactive use cases. Correct?