Revising the implementation

[estaylorco]

@ifandelse Is there anyway the implementation could be changed to the following:

postal.publish({
    channel: 'some.channel',        
    request: {
        topic: 'some.topic',
        data: {some: data},
        timeout: 2000
    },
    response: {
        onSuccess: function (d, e) { }
        onFail: function (err) { }
        always: function (d, e, err) { }
    }
});

The problem I'm having with the current implementation is that it introduces a whole new approach to publishing by having to work with the channel itself. The approach is different, and yet, fundamentally, there's nothing particularly different about request-response.

Also, I think the then should be internalized (but still conform to the configuration for creating promises, of course). Further, onSuccess, onFail, and always conform to the language of the promises domain.

The approach I take above is crystal clear, and we stay within the confines of how we publish otherwise.

It seems to me that it should be easy enough to ingest the object literal above (request, response), and then wrap the channel in request semantics. The response callbacks could internally be mapped to then. So, in effect, the approach I take above becomes sugar on top of the current implementation.

I do like the subscriber side, though (i.e. envelope.reply({ })).

Just some suggestions...

[ifandelse]

@estaylorco One quick point - not at all trying to be nit-picky (promise!), IIRC the concept of always isn't strict promises A or A+ spec. To my knowledge, jQuery and maybe angular's implementation provide an always call - but in effect I'm guessing it's equivalent to chaining another then and letting the error bubble through.

One of the things I hope to avoid is duplication of ways to do one thing. I broke this rule when I allowed publishing/suscribing from the postal namespace in addition to from a ChannelDefinition instance - mainly b/c nearly every other lib in the space is single-channel, and not everyone will use postal's multi-channel approach (which is a shame, IMO). Anyway - I say that just to point out that I often break my own rules (to my own dismay)......but self-rule-breaking aside, I hope to avoid multiple ways (as far as method signature) to perform a request, so the option I'd lean more towards initially would be to allow the postal.request-reponse add-on to add a top level postal.request method that, as much as possible, follows the flow and API of it's ChannelDefinition counterpart. Possibly along these lines:

postal.request({
    channel: "users", // could default to "/" (default channel) if omitted
    topic: "last.login",
    data: { userId: 8675309 },
    timeout: 2000
}).then(
    function(data) {
        console.log("Last login for userId: " + data.userId + " occurred on " + data.time);
    },
    function(err) {
        console.log("Uh oh! Error: " + err);
    }
);

You should be able to chain multiple then calls to the above statement if you have additional things you need executed (in place of always) - and this ensure (I hope) the greatest level of compatibility with the major promises implementations out there....

[estaylorco]

@ifandelse Oh, I don't see it as nit-picking at all. You raise valid concerns. One thing that probably wasn't clear from my post was that I felt that the onSuccess, onFail, and always callbacks conform to, but don't necessarily comply with, the promises spec(s). They are more aligned in spirit than in definition.

Since the entire postal.js framework aligns in spirit with the messaging domain, I felt it appropriate license. But you're right, of course: you could drop always, chain thens, and remove the murkiness.

I'm not sure I follow on the point of method signature: Are you viewing the properties on the object literal as a signature, per se? My version has a signature of postal.publish({ }), which has the same signature as the current #publish method. Do you mean perhaps that you are averse to introducing additional properties on the literal? If so, then I understand that. It is a shame that JavaScript doesn't support polymorphism.

But isn't that what we're talking about here, a form of polymorphism? I don't think we should fear polymorphism here, or view it as "rule-breaking". But, in any case, there is a certain symmetry to postal.request() and envelope.reply(), I must admit.

I'm still not sure I see the harm in the approach I'm suggesting. The framework could still handle the wrapping of the request literal in a postal.request() call. But as to the reply side, perhaps we do forfeit the chaining of thens. Sounds like a job for Conduit, though, doesn't it? :)

In terms of the rules you have established for yourself in creating the framework, would you not see a brand new top-level method on postal as more destructive in spirit as a polymorphic version of the same method? I'm asking in earnest because I've faced this dilemma before myself.