[Standards] Simple Jingle example(s) and spec(s) wanted
stpeter at jabber.org
Tue Feb 6 19:28:58 UTC 2007
Rachel Blackman wrote:
> On Feb 6, 2007, at 10:02 AM, Peter Saint-Andre wrote:
>> Maybe we need to do a better job of showing developers what the
>> migration paths are. Maybe we need to do a better job of incenting
>> developers through code bounties (the XSF has the money, let's use it
>> for good). I'm open to any and all suggestions. But let's not stick
>> with broken extensions that don't really solve the problem at hand,
>> just because the extension is already defined. I don't want to throw
>> things out if they work just fine. But I also want to make sure that
>> we have working protocols, instead of half-working extensions that
>> lead to a poor user experience (as I think we have right now with file
> +1 as it's basically what I was trying to say.
> That just, 'oh, well, we'll put a new file transfer XEP out' is all well
> and good, but that in the past we've never defined solid migration
> paths... and if this is handled the same way many past
> protocol-replacements have been, we'll basically have a lot of clients
> that stick to the old stream-profile S5B file transfer, and can't talk
> to newer clients.
> This is a Bad Thing. There needs to be some way to ensure people keep
> their implementations current. Maybe a yearly certification process
> isn't it, but SOMETHING needs to happen. I'm not addressing the
> technical points, since I don't know enough about the Jingle-FT to judge
> it; just saying, if we're going to replace file transfer, it needs to be
> done in some sort of sane, sensible method of migration.
> Otherwise, if Adium can't send to Psi because Adium goes Jingle-FT and
> Psi stays stream-profile, you're going to reach a situation where we
> have people logging onto AIM just to send files to each other. Hence...
> yes. Migration. Planning. Organization. Something! :)
> Really shutting up now. :)
Not necessary, feedback is good. Someone needs to keep us honest. :)
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards