GNOME Bugzilla – Bug 653682
Change WebServiceDetails.web_service_addresses to support vCard-like arbitrary parameters
Last modified: 2011-08-12 16:02:29 UTC
The main purpose of this change is to support the lossless expression of our Web service addresses as vCard attributes (and vice versa). Proposed API changes: + /* { service-name => { (params, web-service-address), ... } } - public abstract MultiMap<string, string> web_service_addresses + public abstract MultiMap<string, FieldDetails> web_service_addresses ---------------------------- We could possibly avoid this API break by making clients rely upon the values stored in UrlDetails, but then they would need to parse all the various URLs themselves (which is obviously not ideal).
I think it would be neater to change it to the following: + public abstract MultiMap<string, WebServiceAddressFieldDetails> web_service_addresses where “WebServiceAddressFieldDetails” is a clumsily-named subclass of FieldDetails which is specialised for web service addresses. This gives us flexibility to add web service address-specific stuff to its API in future without worrying about other users of FieldDetails. At the moment, for example, static constants for the various standard vCard attribute values could be defined on WebServiceAddressFieldDetails.
(In reply to comment #1) > I think it would be neater to change it to the following: > > + public abstract MultiMap<string, WebServiceAddressFieldDetails> > web_service_addresses > > where “WebServiceAddressFieldDetails” is a clumsily-named subclass of > FieldDetails which is specialised for web service addresses. This gives us > flexibility to add web service address-specific stuff to its API in future > without worrying about other users of FieldDetails. At the moment, for example, > static constants for the various standard vCard attribute values could be > defined on WebServiceAddressFieldDetails. You mean, common parameter values, like "home", "work", etc.? There are some TYPE values that are common for every field (home, work, other) and only a handful which are specific to the attribute name (eg, TYPE=car and TYPE=tty only commonly apply the TEL attribute). I can't think of any parameter (name, value) pairs that we'd want to pre-define for web services that wouldn't already be covered by TYPE={home, work, other}.
(In reply to comment #2) > (In reply to comment #1) > > I think it would be neater to change it to the following: > > > > + public abstract MultiMap<string, WebServiceAddressFieldDetails> > > web_service_addresses > > > > where “WebServiceAddressFieldDetails” is a clumsily-named subclass of > > FieldDetails which is specialised for web service addresses. This gives us > > flexibility to add web service address-specific stuff to its API in future > > without worrying about other users of FieldDetails. At the moment, for example, > > static constants for the various standard vCard attribute values could be > > defined on WebServiceAddressFieldDetails. > > You mean, common parameter values, like "home", "work", etc.? > > There are some TYPE values that are common for every field (home, work, other) > and only a handful which are specific to the attribute name (eg, TYPE=car and > TYPE=tty only commonly apply the TEL attribute). > > I can't think of any parameter (name, value) pairs that we'd want to pre-define > for web services that wouldn't already be covered by TYPE={home, work, other}. That's what I meant. I guess we don't need any of those on WebServiceAddressFieldDetails then; but I still think that subclassing FieldDetails instead of using it directly is a more future-proof plan.
(In reply to comment #1) > I think it would be neater to change it to the following: > > + public abstract MultiMap<string, WebServiceAddressFieldDetails> > web_service_addresses > > where “WebServiceAddressFieldDetails” is a clumsily-named subclass of > FieldDetails which is specialised for web service addresses. This gives us > flexibility to add web service address-specific stuff to its API in future > without worrying about other users of FieldDetails. At the moment, for example, > static constants for the various standard vCard attribute values could be > defined on WebServiceAddressFieldDetails. By that rationale, shouldn't we do the same for EmailDetails.email_addresses, PhoneDetails.phone_numbers, UrlDetails.urls (and ImDetails.im_addresses, which you've already suggested)?
(In reply to comment #4) > (In reply to comment #1) > > I think it would be neater to change it to the following: > > > > + public abstract MultiMap<string, WebServiceAddressFieldDetails> > > web_service_addresses > > > > where “WebServiceAddressFieldDetails” is a clumsily-named subclass of > > FieldDetails which is specialised for web service addresses. This gives us > > flexibility to add web service address-specific stuff to its API in future > > without worrying about other users of FieldDetails. At the moment, for example, > > static constants for the various standard vCard attribute values could be > > defined on WebServiceAddressFieldDetails. > > By that rationale, shouldn't we do the same for EmailDetails.email_addresses, > PhoneDetails.phone_numbers, UrlDetails.urls (and ImDetails.im_addresses, which > you've already suggested)? If we want them to be able to support vCard-like arbitrary parameters, yes.
*** Bug 646079 has been marked as a duplicate of this bug. ***
commit eb1d4fd077d5a8489b750d82fde8f13d9a3c8e4b Author: Travis Reitter <travis.reitter@collabora.co.uk> Date: Tue Aug 9 17:40:41 2011 +0200 Support vCard-like parameters for web service addresses Closes: bgo#653682 - Change WebServiceDetails.web_service_addresses to suppo vCard-like arbitrary parameters