converter implementation

[ankitk-me]

No description provided.

[jfallows]

We need to put validator implementation-specific properties in the validator-specific schema patches so that engine doesn't need global knowledge of the possible properties used by all the validator implementations.

This currently includes

• encoding
• expect

Please refactor them out of the engine schema.

[jfallows]

This is not quite right because it loses information about index and length.

Take a look at MessageConsumer, MessageFunction and MessagePredicate in io.aklivity.zilla.runtime.engine.binding.function package.

I think we might need the following in io.aklivity.zilla.runtime.engine.validator.function package:

• ToIntFragmentFunction

ToIntFragmentFunction
  int applyAsInt(int flags, DirectBuffer buffer, int index, int length)

Validator
  int validate(int flags, DirectBuffer buffer, int index, int length, ToIntFragmentFunction next)

The return value from applyAsInt is the progress towards length, and the implementation would write the validated (converted) value to next.

public class TestValidator implements Validator
{
    public int validate(
        int flags,
        DirectBuffer data,
        int index,
        int length,
        ToIntFragmentFunction next)
    {
        return length != 18 ? -1 : next.applyAsInt(flags, buffer, index, length);
    }
}

So the lambda we pass in for next would actually write the value into the next step in the pipeline.

A better implementation would track the state of progress towards 18 bytes in this case, but that makes it stateful, which is another level of complexity we need to sort out after getting the interfaces to support streaming.

What do you think?

[jfallows]

Alternatively, we can consider using MessageConsumer more directly in validator, if that makes it simpler to propagate valid DATA frames.

public class TestValidator implements Validator
{
    public int validate(
        int msgTypeId, // DataFW.TYPE_ID
        DirectBuffer buffer,  // contains entire DataFW frame
        int index,
        int length,
        MessageConsumer next)
    {
        return length != 18 ? -1 : next.applyAsInt(msgTypeId, buffer, index, length);
    }
}

However, this may be to skewed towards DATA frames, as we also need to validate headers, etc.

[jfallows]

Now that we don't have to return the value, the allocations for value, payloadBytes, byteBuf, valBytes can be eliminated, or reuse shared instances as necessary that are only needed on stack during method invocation, so no chance of concurrent reuse.

[jfallows]

Note the return value here should be how much of length was processed, whereas the return value of next is an indication of how much of what was passed into next was processed.

[jfallows]

This should be static too, right?
Perhaps called NEXT_NOP ?

[jfallows]

This one is all good to return the progress from next because there is no transformation, so the progress in next is equivalent to the progress in this validator.