StreamDefinitions_Discuss

08-12-2015

Right now we have some ambiguity over how StreamDefinitions should really work and what the implications of various permutations are.

See http://dev.fogbeam.org/bugzilla/show_bug.cgi?id=123

Looking back, I think that at one point, the idea was that the "Default" stream (which is auto-created for each user at creation time) would include "everything" or something close to "everything" by default. And then if a user wanted a finer grained steam, they could create a new one, or edit the default. And maybe that's still the right approach. BUT... it's tricky to do this correctly, because it's not straight-forward to include, say, posts to groups which the user was not a member of when the stream was created. If we go down this path, we have to consider doing one of a couple of things:

• Auto add each new group membership to the "groups to include" list for that User's default StreamDefinition.
• change the query so that we simply dereference group memberships for the User so we can include posts to any group they are a member of, regardless of when they joined. This has the disadvantage of requiring that we special-case handling the default stream, since we very explicitly would not want to do that for any other stream. We could add a property on the StreamDefinition class, called "includeEverything" or "isDefaultStream" or something, and toggle the query based on that.

8-13-2015

Thinking about this some more, the "Default" stream definitely should "include everything". The idea is, the system should be maximally useful without the user needing to "do stuff", like re-configuring their stream definition(s). The real question is just "what's the best way to implement this?" We don't want to make too many assumptions for the default stream that interfere with the processing of the more detailed streams, but we also don't want too many special cases.

9-5-2015:

Still more to figure out with this. One big open question is how the ability to select specific event types factors in. Right now, the second panel of the stream edit wizard asks the user to select event types, which can include things like "Status Update", "ActivityStream Item" , "RSS Feed Item", "Business Event", "CalendarFeed Item", etc. BUT... most of those event types are only associated with a subscription anyway. The only way this ever made sense was this: We started out assuming a user always sees his/her own "stuff", so the query includes a section that pulls in items where the owner is the current user. Since items that come in from subscriptions are tagged as belonging to the user who owns this subscription, the default scenario is to see your own RSS Feed Items, Subscription Items, etc... regardless of whether or not you have selected to include any subscriptions in the feed.

This is confusing and redundant. At the very least, the selection on the event type panel should not include any event types that relate specifically to subscriptions. But since that only leaves one or two types, one wonders if it makes sense to have that at all.

One option would be to collapse the "event types" panel and the "subscriptions" panel into one thing and stopping dealing with event types as a separate thing. The question then is, will we have future event types that don't belong to subscriptions? The answer is probably "Yes", but anything related to that is still pretty speculative.