[Wsf-general] Messaging project concept

[Chamikara Jayalath]

Hi All,

(For a possible Telegon/Java implementation :-) )
Yes, there features are trivial to implement. If needed I'll start 
working on them right after the 1.2 release.

Chamikara



Paul Fremantle wrote:
> My responses inline
>
> Sanjiva Weerawarana wrote:
>> Paul Fremantle wrote:
>>> Our current Sandesha implementation doesn't support this kind of 
>>> solution - yet.
>>
>> Have you made these suggestions on sandesha-dev? If not why not??
>
> Because this hasn't been the target for Sandesha. I'm not saying that 
> this approach shouldn't be a target for Sandesha. On the other hand 
> you could see this as an extension that goes beyond the aims of Sandesha.
>
>>> Firstly, we don't have a separate process that can be run simply to 
>>> deliver and manage the messaging interaction. So - for example - you 
>>> run wsclient to deliver a message. Suppose the endpoint isn't up. 
>>> wsclient doesn't run as a daemon. And if wsclient kept running, I 
>>> don't think you could start a new wsclient and expect everything to 
>>> run sweetly.
>>
>> Of course not Paul. But that's a *trivial* thing to do if that's what 
>> we want to do .. we can run Sandesha as an endpoint manager by having 
>> a transport that drops messages to a queue (database, filesystem, 
>> whatever) and have another process pick it up and delivers them 
>> reliably.
>
> I never said it wasn't trivial.
>
>> Why have we not done it? No one asked for it yet.
>
> Er. Yes. That was the whole point of my note. I'm not clear why you 
> are arguing with me.
>
>>> However, I think if you had a local engine running as an 
>>> intermediary, the wsclient could deliver to that - get the acks, and 
>>> then the engine could keep running to deliver the messages.
>>
>> Piece of cake.
>
> +1. I agree with you we can do this simply and we should.
>
>>> Secondly, I don't think we've really thought about the long-running 
>>> case properly with Sandesha. For example, we don't have a mode where 
>>> we will back off to a once a day attempt if the server is down for 
>>> more than 12 
>>
>> Come on; is that a serious problem for us to implement an exponential 
>> backoff on the sending logic?? Its trivial.
>
> We have exponential backoff. I think we need something a little more 
> configurable to support real-life scenarios. Again I didn't say it 
> wasn't trivial to implement.
>
>> Just because we haven't done a specific thing is not a reason to 
>> dismiss the whole thing. Let's not throw the baby out with the 
>> bathwater.
>
> You are reading something into my note that I didn't write. I never 
> suggested dismissing Sandesha or our code.
>
> Where on earth did you get the idea that I'm suggesting throwing out 
> *any code* at all. My note was simply highlighting areas we need to 
> develop from our current codebase to meet the proposed use-case.
>
> In common English usage if you write:
>
> >> Our current Sandesha implementation doesn't support this kind of
> >> solution - yet.
>
> then the word "yet" that implies that it can be made to do that.
>
> Similarly see this comment I made later in the note:
>
> >> However, that isn't to say that we can't morph it to be that.
>
>>> hours. Similarly we don't have any console or way of seeing what the 
>>> status of messages is. We don't have a simple logger that only logs 
>>> the delivery status of each message.
>>
>> Again, piece of cake. We have an API for checking status of Sandesha- 
>> all we'd need is a command line tool to drive that API. What's hard 
>> about it??
>
> Again I didn't say it was hard, I merely said we hadn't done this so far.
>
>>> Basically, our messaging agent is designed to be run as a handler 
>>> inside a SOAP engine and not as a standalone messaging engine. 
>>> However, that isn't to say that we can't morph it to be that. I 
>>> actually think there is a lot of mileage in the multi-process design 
>>> that James has proposed. I think however, that we could still 
>>> implement the multi-process design while re-using much of the web 
>>> services code we already have.
>>
>> +1. All it takes is a few custom transports to decouple the pieces 
>> into multiple processes.
>>
>>> However, I think that the concept - of selling a lightweight, Unix 
>>> friendly, messaging engine has a lot of potential. 
>>
>> +1.
>>
>>  > In fact, it could fit
>>> the Presto case much better than what we are selling today.
>>
>> How does that reconcile with doing that work with our current partner? 
>
> I think we should implement the first prototype of this in PHP thereby 
> making it available with a web UI to them.
>
> Paul
>