That sounds great, I’ll keep a lookout!

From: Iñigo Angulo <[email protected]> <[email protected]>
Reply: [email protected] <[email protected]> <[email protected]>
Date: May 25, 2022 at 08:22:01
To: dev <[email protected]> <[email protected]>
Subject:  Re: Nifi record oriented update

Hi Chris, Otto, Turker,

thank you for your answers and opinions, they help us to clarify the
roadmap.

So we agree at the moment it is better to take the second option: avoid
making the address dynamic and add the caching later. This maybe helps to
keep the PR simpler, to have a common starting point, and think about
further improvements later.

We plan to do this during the following weeks, we will keep you updated.

regards,
inigo



----- Mensaje original -----
De: "Turker TUNALI" <[email protected]>
Para: "dev" <[email protected]>
Enviados: Sábado, 14 de Mayo 2022 11:30:42
Asunto: Re: Nifi record oriented update

I believe that NiFi is a great engine for PLC4X projects.

Türker TUNALI


On Fri, May 13, 2022 at 5:22 PM Otto Fowler <[email protected]>
wrote:

> From a high level:
>
> This processor allows setting the address to be read dynamically from the
> incoming connection. It has to produce a schema for every trigger ( by
> mapping PLC4X types to NIFI record types).
> Since the types will then be dynamic, there should be a schema cache such
> that we reduce the likelihood of recalculating the schema each trigger
> -OR- we could just not make the address dynamic and add the caching later
> ( in other words restrict the use to how the processor actually works
best
> currently).
>
> So, maybe if we can agree to remove the dynamic addressing, we can just
> take this until we can improve it with the caching?
>
>
>
> On Wed, May 11, 2022 at 9:21 AM Christofer Dutz <[email protected]
> >
> wrote:
>
> > Hi Inigo,
> >
> > of course do we still think this is a great new feature and I'd be
> > delighted to have it in develop and perhaps even the next release.
> >
> > I also think it's a good idea to merge it back asap, as I think if it's
> > better than the current version, it's worth having it ... it doesn't
have
> > to be completely finished.
> >
> > Chris
> >
> >
> > -----Original Message-----
> > From: Iñigo Angulo <[email protected]>
> > Sent: Mittwoch, 11. Mai 2022 11:54
> > To: dev <[email protected]>
> > Subject: Nifi record oriented update
> >
> > Hi PLC4X Community,
> >
> > I am writing to you regarding the 'Feature/nifi-record' PR. It's been a
> > while since the last updates here, and we noticed the PR was set to
draft
> > due to inactivity.
> > There were some discussions ongoing about few topics that could be
> > enhanced on the code, mainly three things:
> > - cache for schema,
> > - expand connection and datatype tests
> > - review Plc4xCommon and datatype inferece/conversion from
> PLCReadResponse
> >
> > Although these things could indeed be enhanced, the processor was
working
> > fine, so we think these could be improved in the future, by us and
anyone
> > interested on this from the community :)
> >
> > During the last week, we have been doing new tests using OPCUA driver
> with
> > the record oriented processor. We noticed that, as PLC4X versions have
> > continue to go on, this PR code has become pretty much deprecated, and
> some
> > issues appeared due to version changes and code refactoring... We
managed
> > to solve it locally, but we think it is worth to re-do the
contributions
> on
> > a new PR, just to asure we keep things updated to the last version...
> >
> > So, before doing any change, we wanted to ask if you think this could
be
> a
> > good idea, and if you still find interesting this Nifi Record Feature.
If
> > you agree, we could work on a new PR and prepare the code to match the
> new
> > PLC4X versions, and leave the record oriented processor code at the
same
> > (functional) point it is at the moment. However, we would like to know
> your
> > opinion, so we can agree on the expected result. Having a common
starting
> > point and a clear outcome will avoid further technical discussions on
> > additional functionalities after our work has been done.
> >
> > Let us know what you think,
> >
> > regards
> > iñigo
> >
> >
>

Reply via email to