restricting pub/sub notifications

[Ben Hockey]

when using a restrictive facet how can I apply logic to filter the notifications received by each client? as an example, if a client subscribed to message/* and I only wanted them to be notified of messages that are part of a conversation this client is part of, what does the code look like to do this? or what if I was to treat the path as a query used by the client to indicate what notifications they want?

Restrictive(adminFacet, {
subscribe: function (path, directives) {
// ??? how do I intercept notifications to apply logic to filter?

// unfiltered would be...
return adminFacet.subscribe.apply(adminFacet, arguments);
},
// ...
});

thanks,

ben...

[Kris Zyp]

My intent with subscriptions was to avoid imperative filtering as much as
possible, and try to stick to hash-based message routing whenever possible.
Therefore, "filtered" subscriptions, wouldn't really be about doing anything
special on the subscription side, but rather publishing extra messages to
the channels/topics corresponding to the filtered topics, when data is
changed.

I suppose this could use better extension mechanisms (and possibly
protocols). I think you would probably need to manually grab the hub
reference if you are extending notifying.js, so that you could publish to
the hub for all the filtered topics of a changed object.

Would this work for you for you, or is programmatic filtering actually
necessary?

Thanks,
Kris

--
You received this message because you are subscribed to the Google Groups
"Persevere" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to persevere-frame...@googlegroups.com.
To post to this group, send email to persevere...@googlegroups.com.
Visit this group at http://groups.google.com/group/persevere-framework.
For more options, visit https://groups.google.com/d/optout.

[Ben Hockey]

i need to think some more about whether or not programmatic filtering is necessary.  my tendency is to lean towards it being necessary but i also think that i'm probably biased by my natural inclination - i bet you'd find a way to avoid it :) although, i suspect it may cause you to expose some better extension mechanisms.

in the most common case i need to restrict a client when they subscribe to object/*.  as an example, if a user belongs to a certain group, they may be able to receive notifications about "draft" objects belonging to that group but users who are not a part of that group should only be notified of changes to things which have a "published" status in that group.  in the more complex case, i might want to explore the idea of letting the client provide a query to indicate which objects they want notifications about.  as a user moves through the UI, the client may subscribe and unsubscribe to relevant queries in order to reduce the number of notifications received.  at this time, that's just a thought to experiment with and i don't know if it's more of a burden on the server just to do the filtering and reduce the amount of HTTP interaction compared to just sending everything to the client to do the filtering.  so, i guess there's 2 general categories of filtering i may want to accommodate - permissions-based filtering and query-based filtering.

i think i may have been led to trying to do permissions-based filtering in the facet because the logic to restrict get, query, put, etc all exists in the facet and so my inclination was to put the subscribe/publish logic in there too.  i can see how the hub code lends itself to the channels/topics architecture you described but as you mention, extension points and protocols (and non-trivial examples) are lacking.

while i think some more about this, am i right to assume that tunguska does not require sticky sessions?  if i'm understanding correctly, the clientId is what allows a client to connect to any server in a cluster.  at this time, i'm only running from 1 CPU but i want to make sure that whatever way i approach this filtering i don't limit myself in other ways.  i can see now that trying to intercept the subscribe method of a facet would require sticky sessions - a connection would need to call subscribe on this server instance in order for filtering to be applied via the subscribe method.  instead, i'm thinking that i could introduce some jsgi middleware that gets the clientConnection before pintura/media/message/json tries to send to it and replace clientConnection.send with a function that applies my filtering.  i know this isn't in line with the architecture you describe but it seems like the path of least resistance right now and i just wanted to get your feedback regarding what i might lose by doing that.

on a side note, i really would like to see life breathed back into persevere and i'd love to do what i can to help.  if there are any plans in the works feel free to send pieces my way.  i feel like if i could get inside your head i could provide some of the effort required.  i would probably do more if i had some clear direction - e.g. i could probably close, merge, or update some of the open PRs if i knew your thoughts on them.  i've had to make a number of changes to parts of persevere and introduce some custom middleware in my app and i'd be glad to contribute these things but i sometimes don't know whether my changes are needed due to my lack of understanding or if there really is a bug.

thanks,

ben...

[Kris Zyp]

I think that offering the flexibility of programmatic filtering is quite reasonable, as your examples highlight, particularly if it is relatively broad filtering (the channels are still the “narrowest” part of the filter). I think your approach to implement filtering seems reasonable. I would have to dig into the code before I could prove otherwise.

 

I know that there is definitely talk about investing more resources in Persevere this year, particularly since dstore is more complete now. Hopefully that happens soon.

 

Thanks,

Kris