Introducing putp operator to the Space API

[ghost]

Since the Space API does not describe a non-blocking version of put, namely putp. This creates a small asymmetry in the specification since getp and queryp are defined.

Can we add it or what is the rationale for not adding it?

This is related to one of the questions in issue #12.

[michele-loreti]

I agree with @luhac. From my point of view the answer is yes!

However, we have to clarify the "semantics" of this new operation.

[albertolluch]

on a related note: putp is implemented in goSpace.

[sequenze]

1. Are we renaming put to putp regardless of what we decide should happen with the blocking version?

2. Should the put operation block on the existence of a identical tuple or lack thereof?
   (or something third?)

[albertolluch]

We keep the nameput. This operation blocks until the space inserts the tuple and says "ok". Note that if the space is bounded, the space may take a while (e.g. util some other tuple is removed). Of course, bounded spaces are still not implemented in any of our repos, as far as I know.

putp is a different operation we had in mind: submit put request and move on. There is a subtle difference between

A.putp(t1)
A.putp(t2)

and

go A.put(t1)
A.put(t2)

The first case the put requests to the space are non-blocking but they are serialised. In the second case there is no guarantee in the order of insertion. For now, I don't think putp is justified as one can simulate it by putting the tuples on a list (or a QueueSpace) and sending them in parallel while the process moves on.

Regarding (2): we may consider "sets" as possible class/property of a space. I thought about it in the past. I don't think it is a priority but it may be one of the properties we could include.