point to point vs broadcast channels

[DakotaNelson]

I ran into an interesting question the other day:

Most of the channels we have so far can be used either point-to-point, or to broadcast.

Twitter: DMs from account to account vs. tweets Tumblr: Private messages (require auth) vs. public messages Soundcloud: Public songs vs. private songs

Which do we support? Both? How? It seems feasible to have two classes of channels - broadcast, and point to point - but I'm not sure that's a complexity we want to invite.

[ManickYoj]

Potentially, for some of these, we could have a parameter in the existing channel to change the behavior to private. Say, a 'private' boolean. That way, we don't end up with duplicate channels.

[DakotaNelson]

Definitely. We would have to have different parameters based on that boolean, though, and I'm not sure what the best way is go about that.

[ManickYoj]

I hate to suggest this, but nested dicts would make sense for this, eg {private: true, args: {...}}. I don't think that's a very intuitive interface though, so I'd rather hear other ideas.

[DakotaNelson]

Hmmm, so every channel has a few "global" flags like public/private, and then some args? I don't see why we wouldn't just leave the args at the top level.

The problem I'm seeing is that we could continue as normal and just add a public/private flag in the args, but then error handling for args has to be moved to the module code instead of the framework. (i.e. the args would be listed as optional, but not actually be optional depending on the choice of public/private, and only the module knows what combinations are valid)

Perhaps instead of two lists of parameters (required and optional), modules are required to have one list and a function that checks the validity of any set of parameters passed to it?

[ManickYoj]

That's a fair concern, and as previously mentioned, I'm not a huge fan of making matryoshka dolls out of our arguments.

A function isn't a bad solution, though I am loathe to make module writing even a smidge more involved.

Also, rocking new GitHub photo @DakotaNelson :dancer:

[DakotaNelson]

What if:

We have classes for channels/encoders (this is in progress right now with the library rewrite).

Those classes have a function that just checks to make sure all the required args are there, and returns T/F if they are/aren't. If the module writer wants to overload that function, awesome - if not, that's fine too and it'll just check to make sure everything's there.

It still doesn't solve the usage problem, though - it'll be up to the writers of more complicated modules to make sure it's clear how to use their module (and its presumably complex argument combinations), which is less than awesome.

[davinerd]

Agree with you @DakotaNelson . I'd say: let's implement the mandatory/optional parameters and then let's decide inside send|() based on params. What do you think?

[DakotaNelson]

Sounds good to me.

This will require:

• [ ] Function in each channel to determine valid parameter combinations. Simply required and optional parameter lists wont' be enough (as discussed above).
• [ ] At least one module written using this method so that there's an example to follow. The send function will stay the same, but the receive function will need some sort of determination in order to use an authenticated or unauthenticated call. Perhaps a parameter isn't even required - if there's no credential_x parameter set, it can default to unauthenticated?

[davinerd]

are we going to use the method explained in #7 ? I think i'd be a better idea to implement it, merge into master and then start working on modules that use the optional parameters.

Is that ok for you?