Pavel Simerda wrote:
Hello Peter,this is just reactions to your post, I will later summarize what I have and include some examples so we can advance from theory to something real.
Sounds good!
On Thu, 31 Jul 2008 08:23:36 -0600 Peter Saint-Andre <[EMAIL PROTECTED]> wrote: (citation shortened)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.Just to remind... this means all information the client author implements.Note: No additional server requirements, PEP is ok for us.I would like to keep this as simple as possible, with no support from the server except PEP and client just reads/stores PEP data.
Yes, I think that's a good goal.
3) The harder case - server publishes a pre-existing non-xmpp profile with its own structure on behalf of the userb) 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).We can do this with x:data, because we can specify that some fields are *fixed*, for example: <profile xmlns='urn:xmpp:tmp:profile'> <x xmlns='jabber:x:data' type='result'>...</x> </profile>You hit the point. Data forms do a good job for user interaction and forms. This is why we have them, isn't it? Moreover, as backend-based store *already requires* some complexity on the server, there is no problem in implementing it there. Some client authors, on the other hand, would not like to implement all this stuff. But there's a simple solution to that. Implement it on the server side and use what clients already can! * XEP-0050: Ad-Hoc Commands * XEP-0004: Data Forms This way we don't even need to specify the protocol. Though we may want to (I don't know) like it's done in XEP-0133: Service Administration
The FORM_TYPE stuff (XEP-0068) is one way to scope the data form. Another approach is the wrapper element & namespace as in User Profile. I see these as two ways of doing the same thing. But in PEP the wrapper element is more useful because PEP says that there is one node per namespace.
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.I don't see why the case of more complex data requires an intermediate presentation layer etc.Because we don't want to put SQL, LDAP and all other backend reperesentation into XMPP. By the word "intermediate" I mean the XMPP representation, because it sits between the backend (e.g. SQL) store and the client's user interface (e.g. a graphical window).
Aha, ok. That makes sense.
Actually it's not more complex data but more complex storage (something is in the backend store, something is in the PEP store.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!Agreed.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.+1Thanks for confirmation.We have to define fixed sets of fields (with value formats) to allow client authors to create usable viewing user interfaces.See above on <field type='fixed'> -- x:data helps us here.Fixed in a different meaning. Fixed sets of fields - the sections/groups of fields that are defined so that clients know what data they will get.
Right. And we'll do that via namespacing the data "buckets" (basic, home contact data, work contact data, etc.).
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.I think an application can specify some fields as fixed and ignore any changes generated by the client. But then the PEP service needs to be a bit specialized because it's not just publishing payloads but inspecting the XML of the payload to see if it matches some business rules.I don't think we should misuse PEP syntax for things it cannot do itself. That's why I don't like (a). I included it for completeness.
OK. :)
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.I think this would be part of the form.It cannot be if we don't break the PEP way (use case (2)).
I'm not convinced of that, but I think we need to chat about it in real time instead of sending email messages back and forth. :)
Breaking the simple case means complexity for all clients.I'm not sure of the best location to solve this -- PEP itself (your proposal seems complex to me) or the x:data form. Right now I preferNote: 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.the latter. Perhaps it's time for another groupchat about this in the jdev room. :)We cannot do this with x:data because in PEP, there's no x:data actually read by the client.
There isn't? Why not?
It's not as complex as it may seem (I'm still putting my thougts together so forgive me if I forget to write something or write too much). It's just a single list of nodes that shouldn't be published by the client. Service discovery looks like a good method to me.
But the list of nodes is determined by the data scheme of the backend database (or in your model by the intermediate application between the database and the PEP service). As a result, we can't standardize this via FORM_TYPEs.
Another possibility would be a single attribute (e.g. read-only) for every published node that would tell you if you can change it or not.
But that would be an addition to pubsub/PEP, right? So now it's not standard PEP anymore...
Hmm. Let's chat about this in the jdev room in the next day or two. /psa
smime.p7s
Description: S/MIME Cryptographic Signature
