After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 653682 - Change WebServiceDetails.web_service_addresses to support vCard-like arbitrary parameters
Change WebServiceDetails.web_service_addresses to support vCard-like arbitrar...
Status: RESOLVED FIXED
Product: folks
Classification: Platform
Component: general
git master
Other Linux
: Normal normal
: folks-0.6.0
Assigned To: folks-maint
folks-maint
: 646079 (view as bug list)
Depends on:
Blocks: 653233 653684 655597 655911
 
 
Reported: 2011-06-29 22:11 UTC by Travis Reitter
Modified: 2011-08-12 16:02 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Travis Reitter 2011-06-29 22:11:02 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).
Comment 1 Philip Withnall 2011-06-29 23:31:39 UTC
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.
Comment 2 Travis Reitter 2011-06-30 00:14:16 UTC
(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}.
Comment 3 Philip Withnall 2011-06-30 07:58:07 UTC
(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.
Comment 4 Travis Reitter 2011-07-07 17:12:02 UTC
(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)?
Comment 5 Philip Withnall 2011-07-08 07:41:58 UTC
(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.
Comment 6 Travis Reitter 2011-07-11 23:11:19 UTC
*** Bug 646079 has been marked as a duplicate of this bug. ***
Comment 7 Travis Reitter 2011-08-12 16:02:29 UTC
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