Receive object strings with SETCHAN

[rafalimaz]

Hi,

After some research I didn't find a way to receive the object strings lastly set on the producer. There is a way to receive the strings from the points calculated by Tile38 by using ROAM with SCAN:* but this doesn't solve my problem. Following issues can help to understand the problem better: #93 #96 #315

So, suppose I have a consumer and start it with following commands:

SETCHAN nearby NEARBY people MATCH match FENCE ROAM people * 5000 SCAN :*
SUBSCRIBE nearby

And then I run the following commands on a producer:

SET people alice:lastname STRING "Denton"
SET people alice POINT 33.02 -115.02
SET people bob:lastname STRING "Marley"
SET people bob POINT 33.01 -115.01

Let me explain why I put the STRINGs first. I need that after each SET the consumer has the ability to receive the STRING related to the point that were lastly set and not the nearby points previously set as explained here

So, we would have like this as a result of the last SET command (set point bob):

{"command":"set","detect":"roam","hook":"",
"time":"2016-12-08T09:27:54.306035387-07:00",
"key":"people","id":"bob",
"object":{"type":"Point","coordinates":[-115.01,33.01]},
"nearby":{
  "key":"people","id":"alice","meters":1451.13,
  "objects":[
      {"id":"alice","object":{"type":"Point","coordinates":[-115.02,33.02]}},
      {"id":"alice:lastname","object":"Denton"}
   ]
}}

But it lacks the string information related to bob point. I need something like this:

{"command":"set","detect":"roam","hook":"",
"time":"2016-12-08T09:27:54.306035387-07:00",
"key":"people","id":"bob",
"objects":[
    {"id":"bob","object":{"type":"Point","coordinates":[-115.01,33.01]},
    {"id":"bob:lastname","object":"Marley"}   // I need this information
],
"nearby":{
  "key":"people","id":"alice","meters":1451.13,
  "objects":[
      {"id":"alice","object":{"type":"Point","coordinates":[-115.02,33.02]}},
      {"id":"alice:lastname","object":"Denton"}
   ]
}}

Besides the ROAM solution, I tried to use SCAN :* with static geofence and it didn't work. It would be another solution to our problem, because static geofence always returns the points that were set lastly, not the ones previously saved.

There is also a possible third solution that could be to add another channel that would work like a common pubsub but with strings in such a way that for each STRING set on producer, the consumer would read that string with the point on same operation.

In summary, is there a way to receive the object STRINGs that were SET lastly on producer by using a pubsub channel?

[tidwall]

Hi Rafael,

is there a way to receive the object STRINGs that were SET lastly on producer by using a pubsub channel?

It makes sense what you want, but I think that this would probably require a change to Tile38.

A workaround could be to use a GeoJSON Feature with properties, such as:

SET people alice OBJECT {"type":"Feature","geometry":{"type":"Point","coordinates":[-115.02,33.02]}},"properties":{"lastname":"Denton"}}
SET people bob OBJECT {"type":"Feature","geometry":{"type":"Point","coordinates":[-115.01,33.01]}},"properties":{"lastname":"Marley"}}

If GeoJSON is allowable for your application then you may find it a more extensive format.

[rafalimaz]

Hi tidwall,

First of all thank you for the answer. But we tried a slight different solution:

SET people alice OBJECT {"type":"Point","coordinates":[-115.02,33.02], "lastname":"Denton"}
SET people bob OBJECT {"type":"Point","coordinates":[-115.01,33.01],"lastname":"Marley"}

And it worked fine! But we checked the specification and it only mentions about the type and coordinates attributes inside of a Point object. Why did it work with another "strange" attribute "lastname"?

So we checked there is a "Extending GeoJSON" section that explains about how we can add some different attributes to a GeoJSON object and that it can still be handled for some applications. Do you think it is the case?

Do you think it will affect somehow the performance or consistency of Tile38 SETCHAN feature? Do you think we can continue using this approach or it can be somehow a risk to our application and we should use type Feature?

[tidwall]

You should be fine with that approach, and won't see any performance or consistency issues.

Tile38 supports "foreign members" and I have no intention of removing that ability in the future.

Though I generally recommend sticking to the GeoJSON spec and using the Feature type, because doing so provides additional guarantees that your objects can interoperate with software other than Tile38.

[rafalimaz]

Thank you, we are going to follow the spec. I think this solution is fine for now.