On Fri, 2008-12-12 at 15:31 -0800, Kurt Zeilenga wrote:
> On Dec 12, 2008, at 11:09 AM, Jonathan Schleifer wrote:
>
> > Well, I recently saw that Wippien has VPN support and uses XMPP for
> > the messaging part. I thought that it maybe might be a good idea to
> > have a XEP for VPN via XMPP. I
On Dec 12, 2008, at 3:17 PM, Peter Saint-Andre wrote:
Andreas Monitzer wrote:
On Dec 12, 2008, at 20:09, Jonathan Schleifer wrote:
Well, I recently saw that Wippien has VPN support and uses XMPP for
the messaging part. I thought that it maybe might be a good idea to
have a XEP for VPN via XM
On Dec 12, 2008, at 11:09 AM, Jonathan Schleifer wrote:
Well, I recently saw that Wippien has VPN support and uses XMPP for
the messaging part. I thought that it maybe might be a good idea to
have a XEP for VPN via XMPP. I think this could be achieved quite
well with Jingle. We would just
Andreas Monitzer wrote:
> On Dec 12, 2008, at 20:09, Jonathan Schleifer wrote:
>
>> Well, I recently saw that Wippien has VPN support and uses XMPP for
>> the messaging part. I thought that it maybe might be a good idea to
>> have a XEP for VPN via XMPP. I think this could be achieved quite well
>
On Dec 12, 2008, at 20:09, Jonathan Schleifer wrote:
Well, I recently saw that Wippien has VPN support and uses XMPP for
the messaging part. I thought that it maybe might be a good idea to
have a XEP for VPN via XMPP. I think this could be achieved quite
well with Jingle. We would just need
Well, I recently saw that Wippien has VPN support and uses XMPP for
the messaging part. I thought that it maybe might be a good idea to
have a XEP for VPN via XMPP. I think this could be achieved quite well
with Jingle. We would just need a XEP which specifies how the packets
should be tran
On Thu, 11 Dec 2008 16:15:30 -0500, Stephen Pendleton
wrote:
>
> Some comments I have on 0255 during implementation:
>
>
> - XEP-0080 uses , , instead of , ...
> so the examples need to be changed. The schema looks right though.
Have updated the examples. Thanks for reporting. Also I ha
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
12 matches
Mail list logo
