putting some constants in a .piqi file?

[bart van deenen]

Hi Anton

I have a piqi file with multiple record definitions, and one variant that contains all those record types, like:

.record [.name a ]
.record [.name b ]
.record [.name c ]
.variant [.name resource
    .option [.type a]
    .option [.type b]
    .option [.type c]]

Now I have another part of the application that receives two of these variant records, and I can only allow 'a' to refer to 'b', and c to refer to 'b', which means I want code that uses piqi_rpc to verify that if a rpc command refers to one record 'a', the other parameter must be a 'b'. If the caller of the rpc function actually provides a 'c', my code should return an error.

Now of course I can put these relations in a separate code module like:

is_ok(a,b)-> true;
is_ok(c,b) -> true;
is_ok(_,_) -> false.

but the best place would be right in the .piqi file that defines the variant. Is there any way to do this?

Greetings

Bart

[Anton Lavrik]

Hi Bart,

The short answer is that, today, there's no support for anything like
that in Piqi.

However, once piqic-erlang is rewritten in Erlang, adding support for
custom Erlang validators would be just a couple of lines of code.
(Yes, I know, I've been promising it as a response to almost any
question posted here, but now that piqi-0.6.0 is released, I'm this
close to making it a reality).

Speaking of syntax, I would probably approach it like this:

.record [
.name your-input

.field [
.name r1
.type resource
]

.field [
.name r2
.type resource
]

...

.erlang-check
#
# fun (#your_input{r1 = R1, r2 = R2}) ->
# case {R1, R2} of
# {a,b} -> ok;
# {c,b} -> ok;
# _ -> ... % insert your error handling code here
# end
# end
]

Would that be something close to what you need?

Anton

> --
> You received this message because you are subscribed to the Google Groups
> "piqi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to piqi+uns...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[bart van deenen]

Hi Anton

I'd say that approach would fulfil the need I have, I'm still thinking about whether it's the best solution, because somehow putting Erlang inside .piqi files feels not nice to me, after all we're using piqi also very much as a language agnostic protocol. But I don't have a better suggestion right now, perhaps after I've slept on it :-)

Thanks anyway, and we at Spilgames will keep pushing piqi boldly where no one has gone before !

Bart

[Anton Lavrik]

Hi Bart,

You are totally right that Piqi is a language agnostic tool at its core.

Bringing some language-independent execution model to Piqi is my
long-term goal and a dream. Doing this would be an equivalent of
designing a small programming language with a standard library of
functions. Thinking of it is absolutely fascinating and scary. What
scares me is how much effort it may take to get it right. Doing this
fast is not very realistic. Besides, I would prefer for the project to
settle a little bit and build up some weight before I'll be ready to
jump on new challenges like that.

That said, I don't see anything wrong with the erlang-check approach.
It would be a custom piqi-erlang feature that doesn't require
modifying the language core. If your application is written in Erlang
and the feature addresses your needs while being easy to implement and
potentially useful to others, then why not?

I truly appreciate Spillgames contribution to the project. All
questions and ideas you guys post here really help to make the project
better! Not to mention receiving users' feedback is very motivating.

Anton


On Fri, Feb 8, 2013 at 2:14 AM, bart van deenen