[jdev] Re: Implementing searchable jabber profiles

[Sebastiaan Deckers]

Maybe this thread should move to standards JIG.  Here's my € 0,02.

The way vCards work is transparent to the client('s dvelopers).  No 
pubsub, no authorization, etc.  Just fire and forget.  This is one of 
the reasons so many clients support it.
I don't think x-data should replace vCards.  Instead some often used 
fields should be standardized (var, type, label) as is done in MUC.
See: http://www.jabber.org/jeps/jep-0045.html#registrar-formtype
The x-data fields is then just added to the vCard XML to ensure 
backwards compatibility to some extent.


Trejkaz Xaoza wrote:

>On Wed, 5 Jan 2005 07:11, Peter Saint-Andre wrote:
>  
>
>>I lean toward using x:data as the wire protocol because (i) some Jabber
>>clients already support it, (ii) it is generic (not limited to merely a
>>vCard replacement, which is good for specialized communities such as
>>dating and gaming services), and (iii) I don't really care what the
>>backend data storage format is (database, RDF, or whatever).
>>    
>>
>Generic profiles are a really good idea.  This way, sites which do integrate 
>with a forum can have profiles which exactly match the forum profiles.  There 
>would then be little or no translation between the two, beyond the XML -> 
>database -> XML translation which would need to be done regardless.
>
>Search becomes more consistent too, since the search form can somewhat mirror 
>the actual profile.
>
>Extension might get more interesting though.  Supposing two independent 
>servers wanted to add an extra field to the form.  In my case, it might be 
>the "description" field, since it doesn't appear to be in the spec (yet?) and 
>I always use this field on my real vCard.  Two servers picking the same name 
>would be able to aggregate their databases.  I wonder if the confusion coming 
>from two servers picking different names would even be important, or whether 
>any aggregators would simply ignore the non-standard fields.
>
>TX
>