[Standards] Vcard4 implementation in Movim

Valérian Saliou valerian at valeriansaliou.name
Thu Aug 22 08:55:23 UTC 2013


Hey Tim,

"Deferred" does not mean "Deprecated", it simply means that an active/draft XEP has not been updated for a long time (more than 6 months I believe).
By the way, I think the best thing to do is definitely not deprecating it, but rather switching it to "Obsolete".

We really have an opportunity to leverage the adoption of this XEP and broaden this. A good starting point would be to have a production-stable mod_vcard4 for Prosody and its forks (if not already done), and then moving fast on client implementations.

Cheers,

-- 

Valérian Saliou

Jappix & FrenchTouch Web Agency founder.
Uno IM product lead.

More about me on my personal page.

On Aug 22, 2013, at 9:28 AM, Jaussoin Timothée <edhelas at gmail.com> wrote:

> Le 13/08/2013 20:17, Valérian Saliou a écrit :
>> Hey,
>> 
>> 
>> The transition to vCard4 could be made possible by having one single vCard module that would handle both the legacy vcard-temp and the newest vCard4. The module would put an abstraction layer over the legacy vCard thing so that it can handle/serve the set/get for vcard-temp also, while storing and managing database vCard data as if it was all-vCard4.
>> 
>> Then, the clients still storing vcard-temp (that said, all the clients available as of today - except OneSocialWeb and probably BuddyCloud), would not have to be updated so that the vCard4 compatible clients can retrieve the proper/new vCard4 of an user only storing vcard-temp.
>> 
>> We are really looking forward to implementing vCard4 XEP in Jappix, too - as we work closely with the Movim team!
>> 
>> We can also look into making such an hybrid Prosody/Metronome module to handle that idea.
>> 
>> 
>> Cheers,
>> 
>> -- 
>> 
>> Valérian Saliou
>> 
>> Jappix & FrenchTouch Web Agency founder.
>> Uno IM product lead.
>> 
>> More about me on my personal page.
>> 
>> On Aug 13, 2013, at 7:01 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>> 
>>> On 8/13/13 8:01 AM, Jaussoin Timothée wrote:
>>>> Hi !
>>>> 
>>>> I see that the XEP-0292 has been deffered but I think that XMPP really
>>>> need a descent and modenr vCard support 
>>> 
>>> I completely agree, which is why I authored XEP-0292.
>>> 
>>> IMHO it needs only a few small fixes (the XSLT is incomplete). I will
>>> commit to updating it by the end of August.
>>> 
>>>> so I will implement the XEP in
>>>> Movim using the PEP specification.
>>> 
>>> That's great news! Please send any implementation feedback to this list.
>>> 
>>>> We really need to forget vcard-temp now and go ahead.
>>> 
>>> +1 :-)
>>> 
>>>> If you are an XMPP developers I invite you to do the same :)
>>>> 
>>>> I don't think that there's any change to do server-side ? It's just a
>>>> simple PEP node for me. Can you confirm this (or not) ?
>>> 
>>> For the IQ-based storage, some server-side changes would be needed.
>>> However, as I understand it many server implementations don't use
>>> vcard-temp as the native data storage format anyway (or, if they did,
>>> they could run vcard-temp data through a corrected and complete XSLT to
>>> serve up vCard4 data). Maybe I need to work on this for Prosody... ;-)
>>> 
>>> Peter
>>> 
>>> -- 
>>> Peter Saint-Andre
>>> https://stpeter.im/
>>> 
>>> 
>> 
> Hi !
> 
> Maybe we can change the vcard-temp XEP status to deffered, update the vCard4 XEP to only keep the PEP part (I see that in this XEP there's two way to set the vCard, a simple PEP node and a weird IQ/vcard-temp like way).
> 
> We can also try to clean all the existents avatar/vcards XEP to keep a simple "unique way" to implement all theses things.
> 
> Tim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20130822/98cea84c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20130822/98cea84c/attachment.bin>


More information about the Standards mailing list