[MOBY-dev] {Spam?} Re: The Agent behaviour - discussion and questions to the MOBY community

Paul Gordon gordonp at ucalgary.ca
Tue Aug 8 19:05:04 UTC 2006


I think our string of e-mails this morning proves just how valuable a 
face to face meeting of MOBY developers can be, since we would have 
found out in 20 seconds that we both agreed with each other on both 
issues. :-)  Is it just me, or is the lag time for mailing list getting 
verry looooooong...... up to a hour or more?
>> I definitely agree
>> with you that if you don't provide a signature URL, you shouldn't be
>> deregistered.  But, if you did provide one, you must maintain it.
>>     
>
>
> Clear! So is this done and agreed on with everybody? Could anybidy put it in
> the API documenattion please?
>
>
>
>
> This is where we disagree.  As I said earlier, we have an opportunity to
>   
>> enforce robustness in the protocol, and I think we should take it.
>>     
>
>
> Well, I am not saying not to take it. I am only advocating to have both, the
> simple ping and the testing ping. And I am implementing now the empty ping
> (defined as a request with no mobyData, returning the same back, possibly
> with some service notes added). The testing ping will have to wait when I
> have more time for implementing (or using) the LSID resolution service (or
> at least getting and reading the service RDF document where the input data
> could be).
>
> We (GCP) have may services and we are definitely in favor to have them
> robust. We think that the empty ping can discover maybe 90% of bad cases, so
> it means a vey good ROI. The remainig 10%, we will deal with it using test
> data within the MOBY_Enviroment project. For that (the tetsing ping) we do
> not need any changes in the MOBY API.
>
> So where is the problem? I see the problem is that most people is not saying
> if they agree with the API for the empty ping as suggested by me ad Pieter.
> If people say yes, we are done with the empty ping and can concentrate how
> to persuade people to have also testing ping.
>
> Martin
>
>   




More information about the MOBY-dev mailing list