On Mon, 04 Aug 2008 19:50:01 -0600 Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
> 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 user > > > >>> 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). > >> 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. > >> +1 > >> > > > > Thanks 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.). > Exactement :). (You know Hercule Poirot, don't you?) > >>> 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. :) > Ok, it's just, there are no data forms in PEP, at least not with special meaning to PEP. What we could do... is include some special element in the server-side-implemented User Profile... but it might be better to... (read on) > > Breaking the simple case means complexity for all clients. > > > >>> 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. > >> 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 prefer 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? > None with semantics defined in the PEP. If we put it there, it's just a bunch of XML elements, isn't it (from the PEP view)? > > 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. > Probably by the backend. It could even include data that will not be presented by the User Profile group of XEPs. I agree we should not make any assumptions here and leave the form schema to the implementors. > > 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... In pubsub words this would mean that the user is not the owner (nor publisher) of some of his profile nodes. For these particular nodes (set up by server), he's only a subscriber. The problem is... PEP: > 2.2 One Publisher Per Node > There is no need for multiple publishers to a PEP service, since by > definition the service generates information associated with only one > entity. The owner-publisher for every node is the bare JID of the > account owner. And this would not be the case. I suggest we RECOMMEND that the clients check for it using "XEP-0060, 5.7 Retrieve Affiliations" and proceed if either affiliations retrieval is unsupported or it says they are owners/subscribers. Even though this is not required by PEP (as far as I understand it), a "MAY" or "SHOULD" won't do much harm. > Hmm. > > Let's chat about this in the jdev room in the next day or two. Looking forward. Pavel -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
