-------- Weitergeleitete Nachricht --------
Dear Workgroup members,
As a result of this morning’s Steering
Committee call, we would like to ask you to take some time to
look into the following.
Nodeprovider
The nodeprovider in OpenMDM5 is still very
basic, it does not even cover all OpenMDM 4 nodeprovider
functionality.
Next to that, it will also need to be
extended in order to be able to copy with multiple data
sources at the same time.
During a workshop earlier this week, we
wrote down the functional requirements for this.
We would now want to ask your
support: Please discuss the attached Excel file
with your OpenMDM user base and complete columns C and D as
indicated.
This is crucial in order to be able to do a
correct scoping and planning of the further development work
for this component.
Deadline: end of next week
Please send your response to me, I will
consolidate all answers.
We would especially appreciate to at least
get this feedback from the OEMs, but all other workgroup
members that have a view on actual and future usage of OpenMDM
are welcome to provide their feedback.
For the German OEMs, we count on the
coordination for this by following SC
representatives:
Audi: C. Krenner
BMW: U. Bleicher
Daimler: M. Ebeling
REST API
extension for file attachments
The initial request was to extend the REST
API to support the download by a client of files stored in ERF
(External Reference File) objects.
The discussion of this topic has led to a
few more insights, mainly the fact that for ASAM ODS 5 servers
and current installations, the files that are referenced by
the ERF link are typically stored on a Corba FileServer, next
to the ASAM database.
The fact that with ODS 6, Corba will
disappear, means that for future installations, this will need
to change. It was pointed out that it would be better to use
the AoFile elements rather than the ERF attribute.
Therefore, the proposal has been extended
as follows:
·
step 1: Read files
stored with ERF via Corba FileServer – this is the short term
need and is also required for staying compatible with all
existing databases where this mechanism is used
·
step 2: Read/Write via
AoFile mechanism - Files to be attached both on
Structurelevel/Test/TestStep as on Context Attributes - needs
to support Roles&Rights
·
step 3: eventually in
the future, if someone would still want to have this
functionality: Write files via ERF mechanism to Corba
FileServer
Remark: it
needs to be investigated in for step 1, it would also be
required to be able to read files stored via the ERF mechanism
but attached to Context objects
For this
topic, we would like to get your answer on the following
questions:
Would it be
OK to NOT implement step 3? In other words, is it correct to
expect that:
-
all new datasources that will be implemented in the future
will rely on “non-Corba” technology, meaning that AoFile
will be the standard mechanism to store file attachements –
YES/NO
-
existing datasources will be migrated to “non-Corba”
technology – YES/NO
-
existing datasources will stay operational as they are (so
with Corba technology), but only for data retrieval, not for
storing new data sets –
YES/NO
Thank you all
very much for your cooperation,
Best regards,
the OpenMDM
EWG Steering Committee