Hello, I'm going to describe the issues we discussed in the jdev MUC room from my point of view. I'll also try to offer something new :).
dwd pointed out many issues with enterprise-grade solutions and user profiles. stpeter suggested that these may also affect bigger public services (e.g. Facebook). I unfortunately missed these issues in my previous posts. *For all*: please read at least sections (1) through (3), they're short. 1) Common requirements - getting user profiles Servers must support *XEP-0163: Personal Eventing via Pubsub* to push the profile data to the client. Clients must be able to recieve PEP data, parse the profile data, and implement UI for viewing it. 2) The simpler case - user publishes his xmpp-based profile Clients should be able to *set* at least the most basic information. We need PEP support, profile data structure knowledge and UI for setting the data. Note: No additional server requirements, PEP is ok for us. 3) The harder case - server publishes a pre-existing non-xmpp profile with its own structure on behalf of the user a) viewing profile The server has to map the profile to the profile schema as well as it can and publish it with the PEP. The mapping may not be obvious in some cases. The client just views what it gets. b) setting profile The server may or may not allow the user to set the profile data through Jabber. What's more, the server should be able to specify which fields are read-write and which read-only (or even absent in the data model). This requires a totally different approach to setting the profile. 4) The controversy - model versus protocol In the simple case (2), we define a data model for user profiles. We also specify methods to retrieve them and publish them. Client authors design the UI. But in (3), we actually define an intermediate presentation layer so other clients understand the data and can present them in the UI. We omit or fix fields on the server-side and limit the flexibility we would otherwise offer. Many backend stores will only offer basic info and contacts. Shall we drop all other info sections and disallow any future extensions? I believe we should not! 5) Possible solutions for profile setting I believe we agree on the need to split the user profile into several PEP nodes (groups of fields) to avoid unnecessary data flows. We have to define fixed sets of fields (with value formats) to allow client authors to create usable viewing user interfaces. When we start thinking about setting the profile, the controversy shows itself. a) We could require user profile setting implementation on both the client and server side and disallow PEP publishing (this is effectively what the current version does, it uses PEP syntax but requires special handling!). But this means that we cannot use User Profile without server support which is weird! We're only using PEP events but not publishing features. This also means the client implementation will be a bit more complicated than necessary for (2). The added server-side and client-side complexity may extend the vcard-temp's usage and defer real-world implementation of XEP-0154. b) As the setting method for the backend-based profiles is totally different, it follows we could just ignore it and leave it to a different protocol/extension. No required server support (except for backend-based profiles). We're using PEP's publishing functionality. Client support only consists of PEP, profile elements and user interface. A backend-based profile server would reject any publishing requests with an appropriate error. Additionally, there would be a disco feature(s) that would warn the client not to set the profile (as it will be rejected anyway). Usually we announce features but this would rather be an exception from implied functionality of PEP. Disco would also say which URIs should not be set via PEP. Note: Backend-based settings would be done the same way it is done without Jabber. Additionally, we can use HTML forms over HTTP (with a web browser) or any user interaction technology, including ad-hoc commands. c) If we stick with (b) but we need the missing protocol for setting backend-based profile, we can do it. We can use service discovery to discover support for flexible profile setting. This disco feature also suggest we SHOULD NOT set the profile via PEP. The steps for a client to set a profile could be as follows: * we discover server requires special handling of some PEP (profile-related) nodes * we discover which nodes are to be handled specially * we let the user set the non-backend nodes without restriction * for a backend-based node, we take following steps: * we ask the server which fields we can set * we let the user fill in (modify) data (in an appropriate UI) * we send the data to the server (finished) This would be best described by <iq/> stanzas with answers from the server. d) Waits for you to write. Note: (a) is difficult and unnecessary, (b) and (c) both offer good performance for both (2) and (3). The main difference between them is that (3) offers a custom protocol with the possibility to create custom client UIs (generic jabber client authors may be reluctant to do this) and (2) offers NONE but lets the authors use existing technology. 6) Minor issues Server should announce which profile-related PEP nodes are to be handled by special means to avoid confusion. All PEP nodes that are not announced as specially-handled (backend-based) should be considered publishable by the client. The notion of non-publishable (or read-only/server-handled/whatever) PEP nodes could be solved in the PEP spec (and/or pubsub that I still have to read better) instead of User Profile XEPs. Cheers, pavlix -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
