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.
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. > > 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 > > 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). 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. > > 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. > > 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)). 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. 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. 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. Any of these two would work well. Pavel -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
