watches (either via /watch or via /find and /search) returns undocumented and questionably useful "subscribe" field

# luna-send -i -f luna://com.webos.service.db/watch '{"query":{"from":"my-db-kind:1"}}'

returns

{
    "subscribe": false,
    "returnValue": true,
    "fired": true
}

# luna-send -i -f luna://com.webos.service.db/watch '{"query":{"from":"my-db-kind:1"},"subscribe":true}'

returns

{
    "subscribe": true,
    "returnValue": true,
    "fired": true
}

Note that none of these operations support full subscription, they only support watch (a watch expects there to be an initial response, and a single future response).

Also, according to convention, the value "subscribed" should be used when responding to a subscription request.

Since both web applications and node services both use the subscription interface to watch, as they do not have a direct interface to the luna-service bus's Watch function, I would propose the following:

/watch, or /find or /search with watch: true (or subscribe: true) should return { "subscribed": true } as part of their initial response, and should return { "subscribed": false } along with their last return.

Also, in the case of /watch: if /watch is called with a query that already matches, then it only fires the initial response, along with "fired": true. If you were using this from the native ls2 Watch call, then you'd be generating some memory leakage, as the ls2 Watch is expecting a second message reply. I believe that sending the subscribed: false along with the initial reply, whenever you're not going to send any further replies (because the initial one has all the info), would prevent both the native and the web and node service modules from leaking memory while waiting for a future reply that is never coming.

I suspect that this "subscribe" was added here specifically for that reason, but it should be "subscribed" not "subscribe" and it should always be false when the sender will never be sending any further data.

webosose / db8

watches (either via /watch or via /find and /search) returns undocumented and questionably useful "subscribe" field #5