On 12/12/08 8:10 AM, Kurt Zeilenga wrote:
>
> On Dec 12, 2008, at 7:03 AM, Remko Tronçon wrote:
>
>> Hi Kurt,
>>
>>> Doesn't work for moving to previous stages. The design expects the
>>> server
>>> to remember the previous states, not the client.
>>
>> Hmm, I see, good point.
>>
>> How about ad
On Dec 12, 2008, at 7:03 AM, Remko Tronçon wrote:
Hi Kurt,
Doesn't work for moving to previous stages. The design expects the
server
to remember the previous states, not the client.
Hmm, I see, good point.
How about adding the extra requirement that sending the 'prev' command
also submi
Hi Kurt,
> Doesn't work for moving to previous stages. The design expects the server
> to remember the previous states, not the client.
Hmm, I see, good point.
How about adding the extra requirement that sending the 'prev' command
also submits the hidden parameters from the form? Although it so
On Dec 12, 2008, at 2:06 AM, Remko Tronçon wrote:
I was implementing XEP-50 and was dumbfounded to find the protocol is
stateful.
Can't you make it stateless by passing your state in non-final command
responses through hidden fields?
Doesn't work for moving to previous stages. The design e
Hi,
On 12 Dec 2008, at 10:06, Remko Tronçon wrote:
I was implementing XEP-50 and was dumbfounded to find the protocol is
stateful.
Can't you make it stateless by passing your state in non-final command
responses through hidden fields?
This is exactly what I do in the Tigase server for diffe
> I was implementing XEP-50 and was dumbfounded to find the protocol is
> stateful.
Can't you make it stateless by passing your state in non-final command
responses through hidden fields?
cheers,
Remko
I was implementing XEP-50 and was dumbfounded to find the protocol is
stateful. That is, the protocol requires a server to maintain state,
potentially of significant size, of each in-progress command. I think
a stateless protocol design would be more appropriate, such as one
where the ser
