I think the question comes down to whether we want to fix the other fields now or wait until Shindig 3. My concern is if we fix the other fields now we will break existing consumers when they upgrade.
On Thursday, October 18, 2012, Jan Willem Janssen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/16/12 3:34 PM, Ryan Baxter wrote: > > So you are saying according to the spec Account for example should > > be a subclass of a PluralField object which has the properties > > defined within the spec [1], right? > > That is one way of doing this. There are other ways as well, of course. > > My concern is that the current implementation is not consistent for > the plural fields. So, either use *one* representation for plural > fields (for example by using List<PluralField<?>>) and use this > consistently for all entities... > > > > [1] > > > http://opensocial-resources.googlecode.com/svn/spec/trunk/Core-Data.xml#Plural-Field > > > > On Tue, Oct 16, 2012 at 4:06 AM, Jan Willem Janssen < > > [email protected] <javascript:;>> wrote: > > > > On 10/13/12 12:30 AM, Henry Saputra wrote: > >>>> As for your question, I think I am kind of loss on what your > >>>> concerns are? > >>>> > >>>> Could you give a bit more example of what conflict or > >>>> confusion about matching the fields for the Person data type > >>>> with the spec? > > > > For example, taken the following fields: > > > > - "accounts": the spec defines this field as PluralField<Account>. > > Shindig implements this as List<Account>, with no possibility to > > specify the primary account; - "addresses": also a > > PluralField<Address>, which is implemented in Shindig as > > List<Address>, while the Address object has a field primary; - > > "emails": PluralField<Email>, implemented as a List<ListField> in > > Shindig. > > > > So it appears there are three ways of defining a PluralField in > > Shindig (actually two: the first item is a bug IMO). Which one > > should be used for adding new PluralFields? > > > > In addition: there are several fields in Person implemented as > > enumeration of fixed values, while the spec doesn't mention > > anything on these value constraints (e.g. "drinker"). Shouldn't > > these fields be made less restricted? > > > > - -- > Met vriendelijke groeten | Kind regards > > Jan Willem Janssen | Software Architect > +31 631 765 814 > > /My world is:/ > > Luminis Technologies B.V. > IJsselburcht 3 > 6825 BS Arnhem > +31 88 586 46 30 > > http://www.luminis-technologies.com > http://www.luminis.eu > > KvK (CoC) 09 16 28 93 > BTW (VAT) NL8169.78.566.B.01 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJQf+JSAAoJEKF/mP2eHDc43YUP/1e7Rp7/NrRjWUFaKM5upSgB > gGHkbFmSoDJOhXwg5K2nqe7/yxi4c66m7rxVlbav+5o1lhxG88f2e/wxdkyc09u2 > 4ZmgpS0E4wR7lJdjbDSz57pnlRGzGaN0MfYSzdVxhfQ1cvNI8eng1IaWzNODCMna > PleGmT1jAeO2gNrg+0GHjh6wlTBOxwep+0hwDjUfOt+9FxsBa3VoWRsQJvLgaRPh > A0QDhuqfpPjE2kGPVHtt4uVTh2toZKCbLcRuEmg4IQ7XQWol/uuoKjjDZkSLRAqz > K9uqSAnLQHQg7IJzNqNLTCdhH2jHW3bSquWvYLCnBenJLm0tLFYhw2rk1cgIcTSn > NLEzLQ+TTdfXe6aZrd29uB3W+fVxXrvOh7apHna0pQGmsS0x9d9zkf16E07r9TcA > tCS486qA6a0FTwp/5K+8hCC0obnuVG6a0Rmm77oAHFY7YAiPKKCZ5PGZhwuLXYmP > /1pYscPkXadExA9nAXABY36HUxlRgSbvmARu+wzUjKbmtG4jgeniixqM5KWI/TE+ > hVdJ1psT2GCnof/1t5fWsaMIDnlFkonv2+ueGdTrPZonJVhYaB2HeZ/D51K9SoZm > agP51jdulWj7h1rpdRM3lMmxfbYO8l8+LmWfAGjHWhJKazqd0a8nY45m1Mp65BZk > s/wHB4i+0QYjbhdBBFGV > =ifXA > -----END PGP SIGNATURE----- > >
