We are suggesting an extention to the gadget XML for the gadget to
declare which views it supports. For instance, a gadget could declare
only to have a profile view; in which case the title would not link to
the canvas (since there is none). This will be especially useful
though for the non-standard views. As I remember correctly, Hi5 has a
view where there is no owner (we are thinking of offering something
similar); it might be useful to know if the gadget supports this view.
Looking at the content sections for this is not enough; there might be
"default" content sections, or any switch between content sections
might be done in javascript.
It could look something like
<supportedviews>profile,canvas,etc</supportedviews>
or
<supportedviews>
<view>profile</view>
<view>canvas</view>
<view>etc</view>
</supportedviews>
Let me know what you think of it. It might be especially interesting
to hear from the containers that already have non-standard views.
Could you give a little more context on the proposal here? At first glance this syntax seems redundant, since the same information can be gleaned from existing view attributes on <Content> sections.
On Sun, Apr 6, 2008 at 5:34 PM, Reinoud Elhorst <rein...@hyves.nl> wrote:
> We are suggesting an extention to the gadget XML for the gadget to > declare which views it supports. For instance, a gadget could declare > only to have a profile view; in which case the title would not link to > the canvas (since there is none). This will be especially useful > though for the non-standard views. As I remember correctly, Hi5 has a > view where there is no owner (we are thinking of offering something > similar); it might be useful to know if the gadget supports this view.
> Looking at the content sections for this is not enough; there might be > "default" content sections, or any switch between content sections > might be done in javascript.
> It could look something like > <supportedviews>profile,canvas,etc</supportedviews> > or > <supportedviews> > <view>profile</view> > <view>canvas</view> > <view>etc</view> > </supportedviews>
> Let me know what you think of it. It might be especially interesting > to hear from the containers that already have non-standard views.
On Sun, Apr 6, 2008 at 10:29 AM, John Hjelmstad <fa...@google.com> wrote: > Could you give a little more context on the proposal here? At first glance > this syntax seems redundant, since the same information can be gleaned from > existing view attributes on <Content> sections.
> --John
> On Sun, Apr 6, 2008 at 5:34 PM, Reinoud Elhorst <rein...@hyves.nl> wrote:
> > We are suggesting an extention to the gadget XML for the gadget to > > declare which views it supports. For instance, a gadget could declare > > only to have a profile view; in which case the title would not link to > > the canvas (since there is none). This will be especially useful > > though for the non-standard views. As I remember correctly, Hi5 has a > > view where there is no owner (we are thinking of offering something > > similar); it might be useful to know if the gadget supports this view.
> > Looking at the content sections for this is not enough; there might be > > "default" content sections, or any switch between content sections > > might be done in javascript.
> > It could look something like > > <supportedviews>profile,canvas,etc</supportedviews> > > or > > <supportedviews> > > <view>profile</view> > > <view>canvas</view> > > <view>etc</view> > > </supportedviews>
> > Let me know what you think of it. It might be especially interesting > > to hear from the containers that already have non-standard views.
I had some more discussions on this. The problem is that the view "default" matches anything. So if I have a very specific view, that's only present on my container, that renders in a star-shaped iframe, and only makes sense for gadgets that have a black background (obviously a purely hypothetical case; still you can easily see how specific views require specific support from the gadget), any gadget specifying a "default" view section, will seem to support my view. As a container, I don't know whether the developer just created a "default" section because he was too lazy to specify sections, whether there is a switch between views being made in javascript, or whether his gadget is a black star shaped thing in any view.
On a more practical level, as I understand how MySpace supports gadgets now, is that they have 3 views: - - canvas - - profile - - innerprofile Innerprofile is what you see when you go to your own profile. When a gadget developer submits his gadget to myspace, he has to specify whether it makes sense to show his gadget on only the innerprofile (e.g. todo list), only on the canvas/profile (e.g. superwall), or both (e.g. shelfari, showing your books on your profile, and showing your friend's books on your innerprofile) As shown before, the catchall functionality of the "default" view currently makes it impossible to retrieve this information from the gadget XML. When more containers will want to support a similar functionality, gadget developers will have to specify the views the gadget is supporting again in each container's web interface.
In a talk I had with Dan, Cassie and John Hjelmstad yesterday, we thought of several possible solutions: - - Support an extra tag in the spec as I suggested originally. Perhaps, "supportedviews" isn't the best terminology here, something "preferredviews" might be more accurate. - - Extend the spec description of the content-sections in such a way that it is clear that any view that is explicitly supported is mentioned somewhere. So instead of just one <content type="default"> section, it would make sense to specify <content type="profile,innerprofile,canvas,starshapedblackthingy,default"> It would let the container know that it has specific support for those types, and in addition has a default view for any other type. In javascript the switch may be made between the views - - This informations should be stored in some global gadget directory. The problem here is that we don't have a global gadget directory yet, and I don't think it's a good idea to have each container keep it's own data about this now.
Please let me know if I've been able to at least convince you of the need now :); I would be interested in what solution would be preferred by the community.
Kevin Brown wrote: > I'm with John on this one. What does this provide that simply examining the > content sections doesn't? If I have a spec that looks like this:
> The supported views are "profile", "canvas", "magic", and "grandpa".
> What cases aren't covered here?
> On Sun, Apr 6, 2008 at 10:29 AM, John Hjelmstad <fa...@google.com> wrote:
>> Could you give a little more context on the proposal here? At first glance >> this syntax seems redundant, since the same information can be gleaned from >> existing view attributes on <Content> sections.
>> --John
>> On Sun, Apr 6, 2008 at 5:34 PM, Reinoud Elhorst <rein...@hyves.nl> wrote:
>>> We are suggesting an extention to the gadget XML for the gadget to >>> declare which views it supports. For instance, a gadget could declare >>> only to have a profile view; in which case the title would not link to >>> the canvas (since there is none). This will be especially useful >>> though for the non-standard views. As I remember correctly, Hi5 has a >>> view where there is no owner (we are thinking of offering something >>> similar); it might be useful to know if the gadget supports this view.
>>> Looking at the content sections for this is not enough; there might be >>> "default" content sections, or any switch between content sections >>> might be done in javascript.
>>> It could look something like >>> <supportedviews>profile,canvas,etc</supportedviews> >>> or >>> <supportedviews> >>> <view>profile</view> >>> <view>canvas</view> >>> <view>etc</view> >>> </supportedviews>
>>> Let me know what you think of it. It might be especially interesting >>> to hear from the containers that already have non-standard views.
>>> Reinoud Elhorst >>> Hyves
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
On Tue, Apr 8, 2008 at 3:49 AM, Reinoud Elhorst <rein...@hyves.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1
> I had some more discussions on this. The problem is that the view > "default" matches anything. So if I have a very specific view, that's > only present on my container, that renders in a star-shaped iframe, and > only makes sense for gadgets that have a black background (obviously a > purely hypothetical case; still you can easily see how specific views > require specific support from the gadget), any gadget specifying a > "default" view section, will seem to support my view. As a container, I > don't know whether the developer just created a "default" section > because he was too lazy to specify sections, whether there is a switch > between views being made in javascript, or whether his gadget is a black > star shaped thing in any view.
Yes, that's exactly the point. A developer that doesn't want this behavior should simply not declare a default view.
On a more practical level, as I understand how MySpace supports gadgets
> now, is that they have 3 views: > - - canvas > - - profile > - - innerprofile > Innerprofile is what you see when you go to your own profile. When a > gadget developer submits his gadget to myspace, he has to specify > whether it makes sense to show his gadget on only the innerprofile (e.g. > todo list), only on the canvas/profile (e.g. superwall), or both (e.g. > shelfari, showing your books on your profile, and showing your friend's > books on your innerprofile) > As shown before, the catchall functionality of the "default" view > currently makes it impossible to retrieve this information from the > gadget XML. > When more containers will want to support a similar functionality, > gadget developers will have to specify the views the gadget is > supporting again in each container's web interface.
> In a talk I had with Dan, Cassie and John Hjelmstad yesterday, we > thought of several possible solutions: > - - Support an extra tag in the spec as I suggested originally. Perhaps, > "supportedviews" isn't the best terminology here, something > "preferredviews" might be more accurate. > - - Extend the spec description of the content-sections in such a way that > it is clear that any view that is explicitly supported is mentioned > somewhere. So instead of just one > <content type="default"> > section, it would make sense to specify > <content type="profile,innerprofile,canvas,starshapedblackthingy,default"> > It would let the container know that it has specific support for those > types, and in addition has a default view for any other type. In > javascript the switch may be made between the views
This is exactly how the current syntax works. If a developer doesn't want to provide a default view, they simply omit it (including omitting any unnamed content sections, which are also treated as "default"). Many gadgets are already doing this today.
> - - This informations should be stored in some global gadget directory. > The problem here is that we don't have a global gadget directory yet, > and I don't think it's a good idea to have each container keep it's own > data about this now.
> Please let me know if I've been able to at least convince you of the > need now :); I would be interested in what solution would be preferred > by the community.
I think we already have the mechanism in place to do exactly what you want. Not liking the syntax is different from not supporting it. The syntax of most of the spec xml is non-optimal, but changing things just because it isn't ideal is difficult. We're better off creating a new schema that isn't broken.
> Kevin Brown wrote: > > I'm with John on this one. What does this provide that simply examining > the > > content sections doesn't? If I have a spec that looks like this:
> > The supported views are "profile", "canvas", "magic", and "grandpa".
> > What cases aren't covered here?
> > On Sun, Apr 6, 2008 at 10:29 AM, John Hjelmstad <fa...@google.com> > wrote:
> >> Could you give a little more context on the proposal here? At first > glance > >> this syntax seems redundant, since the same information can be gleaned > from > >> existing view attributes on <Content> sections.
> >> --John
> >> On Sun, Apr 6, 2008 at 5:34 PM, Reinoud Elhorst <rein...@hyves.nl> > wrote:
> >>> We are suggesting an extention to the gadget XML for the gadget to > >>> declare which views it supports. For instance, a gadget could declare > >>> only to have a profile view; in which case the title would not link to > >>> the canvas (since there is none). This will be especially useful > >>> though for the non-standard views. As I remember correctly, Hi5 has a > >>> view where there is no owner (we are thinking of offering something > >>> similar); it might be useful to know if the gadget supports this view.
> >>> Looking at the content sections for this is not enough; there might be > >>> "default" content sections, or any switch between content sections > >>> might be done in javascript.
> >>> It could look something like > >>> <supportedviews>profile,canvas,etc</supportedviews> > >>> or > >>> <supportedviews> > >>> <view>profile</view> > >>> <view>canvas</view> > >>> <view>etc</view> > >>> </supportedviews>
> >>> Let me know what you think of it. It might be especially interesting > >>> to hear from the containers that already have non-standard views.
> >>> Reinoud Elhorst > >>> Hyves
> -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
Kevin Brown wrote: > On Tue, Apr 8, 2008 at 3:49 AM, Reinoud Elhorst <rein...@hyves.nl> wrote:
> I had some more discussions on this. The problem is that the view > "default" matches anything. So if I have a very specific view, that's > only present on my container, that renders in a star-shaped iframe, and > only makes sense for gadgets that have a black background (obviously a > purely hypothetical case; still you can easily see how specific views > require specific support from the gadget), any gadget specifying a > "default" view section, will seem to support my view. As a container, I > don't know whether the developer just created a "default" section > because he was too lazy to specify sections, whether there is a switch > between views being made in javascript, or whether his gadget is a black > star shaped thing in any view.
>> Yes, that's exactly the point. A developer that doesn't want this behavior >> should simply not declare a default view.
In that case, it's questionable what the value of the default view is, if by specifying a default view, you claim to support every view that can ever be imagined in the future. At the very least, I think the spec should be very clear about this point; I don't think most gadget developers start by reading the spec through.
>> On a more practical level, as I understand how MySpace supports gadgets > now, is that they have 3 views: > - canvas > - profile > - innerprofile > Innerprofile is what you see when you go to your own profile. When a > gadget developer submits his gadget to myspace, he has to specify > whether it makes sense to show his gadget on only the innerprofile (e.g. > todo list), only on the canvas/profile (e.g. superwall), or both (e.g. > shelfari, showing your books on your profile, and showing your friend's > books on your innerprofile) > As shown before, the catchall functionality of the "default" view > currently makes it impossible to retrieve this information from the > gadget XML. > When more containers will want to support a similar functionality, > gadget developers will have to specify the views the gadget is > supporting again in each container's web interface.
> In a talk I had with Dan, Cassie and John Hjelmstad yesterday, we > thought of several possible solutions: > - Support an extra tag in the spec as I suggested originally. Perhaps, > "supportedviews" isn't the best terminology here, something > "preferredviews" might be more accurate. > - Extend the spec description of the content-sections in such a way that > it is clear that any view that is explicitly supported is mentioned > somewhere. So instead of just one > <content type="default"> > section, it would make sense to specify > <content type="profile,innerprofile,canvas,starshapedblackthingy,default"> > It would let the container know that it has specific support for those > types, and in addition has a default view for any other type. In > javascript the switch may be made between the views
>> This is exactly how the current syntax works. If a developer doesn't want to >> provide a default view, they simply omit it (including omitting any unnamed >> content sections, which are also treated as "default"). Many gadgets are >> already doing this today.
> - This informations should be stored in some global gadget directory. > The problem here is that we don't have a global gadget directory yet, > and I don't think it's a good idea to have each container keep it's own > data about this now.
> Please let me know if I've been able to at least convince you of the > need now :); I would be interested in what solution would be preferred > by the community.
>> I think we already have the mechanism in place to do exactly what you want. >> Not liking the syntax is different from not supporting it. The syntax of >> most of the spec xml is non-optimal, but changing things just because it >> isn't ideal is difficult. We're better off creating a new schema that isn't >> broken.
It might be interesting to check the top x opensocial gadgets out there now, and see how they behave. If indeed they very seldom specify a default view, checking the specified views would work.
On the practical side, we do need the information on what views are supported. If many gadgets have a default view, and no other way exists in the spec to decide what views are supported, it seems that we'd either need to specify a hyves-specific extension to the spec, or need to collect the data when a gadget developer submits his gadget to our site. In the latter case, it would make sense that we'd share that data back to some/the central directory when it is released.
> Kevin Brown wrote: >>>> I'm with John on this one. What does this provide that simply examining > the >>>> content sections doesn't? If I have a spec that looks like this:
>>>> The supported views are "profile", "canvas", "magic", and "grandpa".
>>>> What cases aren't covered here?
>>>> On Sun, Apr 6, 2008 at 10:29 AM, John Hjelmstad <fa...@google.com> > wrote: >>>>> Could you give a little more context on the proposal here? At first > glance >>>>> this syntax seems redundant, since the same information can be gleaned > from >>>>> existing view attributes on <Content> sections.
>>>>> --John
>>>>> On Sun, Apr 6, 2008 at 5:34 PM, Reinoud Elhorst <rein...@hyves.nl> > wrote: >>>>>> We are suggesting an extention to the gadget XML for the gadget to >>>>>> declare which views it supports. For instance, a gadget could declare >>>>>> only to have a profile view; in which case the title would not link to >>>>>> the canvas (since there is none). This will be especially useful >>>>>> though for the non-standard views. As I remember correctly, Hi5 has a >>>>>> view where there is no owner (we are thinking of offering something >>>>>> similar); it might be useful to know if the gadget supports this view.
>>>>>> Looking at the content sections for this is not enough; there might be >>>>>> "default" content sections, or any switch between content sections >>>>>> might be done in javascript.
>>>>>> It could look something like >>>>>> <supportedviews>profile,canvas,etc</supportedviews> >>>>>> or >>>>>> <supportedviews> >>>>>> <view>profile</view> >>>>>> <view>canvas</view> >>>>>> <view>etc</view> >>>>>> </supportedviews>
>>>>>> Let me know what you think of it. It might be especially interesting >>>>>> to hear from the containers that already have non-standard views.
On Tue, Apr 8, 2008 at 2:42 PM, Reinoud Elhorst <rein...@hyves.nl> wrote: > In that case, it's questionable what the value of the default view is, > if by specifying a default view, you claim to support every view that > can ever be imagined in the future. At the very least, I think the spec > should be very clear about this point; I don't think most gadget > developers start by reading the spec through.
The default view should usually be an error or promotional message, not a functional version of the gadget. That's exactly what it's intended for. I'm all for adding explicitness in the spec -- it's far too ambiguous now.
It might be interesting to check the top x opensocial gadgets out there
> now, and see how they behave. If indeed they very seldom specify a > default view, checking the specified views would work.
> On the practical side, we do need the information on what views are > supported. If many gadgets have a default view, and no other way exists > in the spec to decide what views are supported, it seems that we'd > either need to specify a hyves-specific extension to the spec, or need > to collect the data when a gadget developer submits his gadget to our > site. In the latter case, it would make sense that we'd share that data > back to some/the central directory when it is released.
The developer has to change their spec in either case; changing it to add explicit view enumeration on the content section is no different from adding a new element. The new element requires implementations to change as well though, which makes little sense if the developers have to modify their gadgets anyway.
It's worth noting that the supporting the default is entirely optional for containers. If your container chooses to ignore the default section, that's perfectly acceptable.
On Wed, Apr 9, 2008 at 12:11 AM, Kevin Brown <e...@google.com> wrote: > On Tue, Apr 8, 2008 at 2:42 PM, Reinoud Elhorst <rein...@hyves.nl> wrote:
>> In that case, it's questionable what the value of the default view is, >> if by specifying a default view, you claim to support every view that >> can ever be imagined in the future. At the very least, I think the spec >> should be very clear about this point; I don't think most gadget >> developers start by reading the spec through.
> The default view should usually be an error or promotional message, not a > functional version of the gadget. That's exactly what it's intended for. I'm > all for adding explicitness in the spec -- it's far too ambiguous now.
>> It might be interesting to check the top x opensocial gadgets out there >> now, and see how they behave. If indeed they very seldom specify a >> default view, checking the specified views would work.
>> On the practical side, we do need the information on what views are >> supported. If many gadgets have a default view, and no other way exists >> in the spec to decide what views are supported, it seems that we'd >> either need to specify a hyves-specific extension to the spec, or need >> to collect the data when a gadget developer submits his gadget to our >> site. In the latter case, it would make sense that we'd share that data >> back to some/the central directory when it is released.
> The developer has to change their spec in either case; changing it to add > explicit view enumeration on the content section is no different from adding > a new element. The new element requires implementations to change as well > though, which makes little sense if the developers have to modify their > gadgets anyway.
> It's worth noting that the supporting the default is entirely optional for > containers. If your container chooses to ignore the default section, that's > perfectly acceptable.
Is Kevin's view that "The default view should usually be an error or promotional message, not a functional version of the gadget" the general view in the community (I haven't checked how this is being done in real life gadgets at the moment)? In this case, this should be in the gadget spec very clearly. I do think however that this is at odds with the traditional google gadgets and backwards compatibility.
I still stand with the original proposal to let the gadget (optionally) specify with views it supports.
At the very least, I think it should become clear what exactly the "default" view is for, and this should be well documented.
On Mon, Apr 14, 2008 at 2:00 PM, Cassie <d...@google.com> wrote:
> Did we want to do anything to the spec for any of this?
> - Cassie
> On Wed, Apr 9, 2008 at 12:11 AM, Kevin Brown <e...@google.com> wrote: > > On Tue, Apr 8, 2008 at 2:42 PM, Reinoud Elhorst <rein...@hyves.nl> > wrote:
> >> In that case, it's questionable what the value of the default view is, > >> if by specifying a default view, you claim to support every view that > >> can ever be imagined in the future. At the very least, I think the spec > >> should be very clear about this point; I don't think most gadget > >> developers start by reading the spec through.
> > The default view should usually be an error or promotional message, not > a > > functional version of the gadget. That's exactly what it's intended for. > I'm > > all for adding explicitness in the spec -- it's far too ambiguous now.
> >> It might be interesting to check the top x opensocial gadgets out there > >> now, and see how they behave. If indeed they very seldom specify a > >> default view, checking the specified views would work.
> >> On the practical side, we do need the information on what views are > >> supported. If many gadgets have a default view, and no other way exists > >> in the spec to decide what views are supported, it seems that we'd > >> either need to specify a hyves-specific extension to the spec, or need > >> to collect the data when a gadget developer submits his gadget to our > >> site. In the latter case, it would make sense that we'd share that data > >> back to some/the central directory when it is released.
> > The developer has to change their spec in either case; changing it to > add > > explicit view enumeration on the content section is no different from > adding > > a new element. The new element requires implementations to change as > well > > though, which makes little sense if the developers have to modify their > > gadgets anyway.
> > It's worth noting that the supporting the default is entirely optional > for > > containers. If your container chooses to ignore the default section, > that's > > perfectly acceptable.
On Mon, Apr 14, 2008 at 5:21 AM, Reinoud Elhorst <rein...@hyves.nl> wrote: > Is Kevin's view that "The default view should usually be an error or > promotional message, not a functional version of the gadget" the general > view in the community (I haven't checked how this is being done in real life > gadgets at the moment)? In this case, this should be in the gadget spec very > clearly. I do think however that this is at odds with the traditional google > gadgets and backwards compatibility.
This might be fairly controversial, but I've been thinking it for a while and I'm sure other people have as well -- is this really that important?
> I still stand with the original proposal to let the gadget (optionally) > specify with views it supports.
> At the very least, I think it should become clear what exactly the > "default" view is for, and this should be well documented.
> On Mon, Apr 14, 2008 at 2:00 PM, Cassie <d...@google.com> wrote:
> > Did we want to do anything to the spec for any of this?
> > - Cassie
> > On Wed, Apr 9, 2008 at 12:11 AM, Kevin Brown <e...@google.com> wrote: > > > On Tue, Apr 8, 2008 at 2:42 PM, Reinoud Elhorst <rein...@hyves.nl> > > wrote:
> > >> In that case, it's questionable what the value of the default view > > is, > > >> if by specifying a default view, you claim to support every view that > > >> can ever be imagined in the future. At the very least, I think the > > spec > > >> should be very clear about this point; I don't think most gadget > > >> developers start by reading the spec through.
> > > The default view should usually be an error or promotional message, > > not a > > > functional version of the gadget. That's exactly what it's intended > > for. I'm > > > all for adding explicitness in the spec -- it's far too ambiguous now.
> > >> It might be interesting to check the top x opensocial gadgets out > > there > > >> now, and see how they behave. If indeed they very seldom specify a > > >> default view, checking the specified views would work.
> > >> On the practical side, we do need the information on what views are > > >> supported. If many gadgets have a default view, and no other way > > exists > > >> in the spec to decide what views are supported, it seems that we'd > > >> either need to specify a hyves-specific extension to the spec, or > > need > > >> to collect the data when a gadget developer submits his gadget to our > > >> site. In the latter case, it would make sense that we'd share that > > data > > >> back to some/the central directory when it is released.
> > > The developer has to change their spec in either case; changing it to > > add > > > explicit view enumeration on the content section is no different from > > adding > > > a new element. The new element requires implementations to change as > > well > > > though, which makes little sense if the developers have to modify > > their > > > gadgets anyway.
> > > It's worth noting that the supporting the default is entirely optional > > for > > > containers. If your container chooses to ignore the default section, > > that's > > > perfectly acceptable.
I'm not sure that gadget developers are currently using the default view in this manner, nor will they adopt this approach unless containers standardize on it. Once you start writing container-specific code, there's not much point to using the "default" view, so all it takes is one container not following this behavior to negate the utility of it.
I'm for adding a clarification as to the intent of "default" view sections to the spec. It's ambiguous and therefore not very useful (from a container compatibility point of view) right now.
On Mon, Apr 14, 2008 at 12:10 PM, Kevin Brown <e...@google.com> wrote: > On Mon, Apr 14, 2008 at 5:21 AM, Reinoud Elhorst <rein...@hyves.nl> wrote:
> > Is Kevin's view that "The default view should usually be an error or > > promotional message, not a functional version of the gadget" the general > > view in the community (I haven't checked how this is being done in real life > > gadgets at the moment)? In this case, this should be in the gadget spec very > > clearly. I do think however that this is at odds with the traditional google > > gadgets and backwards compatibility.
> This might be fairly controversial, but I've been thinking it for a while > and I'm sure other people have as well -- is this really that important?
> > I still stand with the original proposal to let the gadget (optionally) > > specify with views it supports.
> > At the very least, I think it should become clear what exactly the > > "default" view is for, and this should be well documented.
> > On Mon, Apr 14, 2008 at 2:00 PM, Cassie <d...@google.com> wrote:
> > > Did we want to do anything to the spec for any of this?
> > > - Cassie
> > > On Wed, Apr 9, 2008 at 12:11 AM, Kevin Brown <e...@google.com> wrote: > > > > On Tue, Apr 8, 2008 at 2:42 PM, Reinoud Elhorst <rein...@hyves.nl> > > > wrote:
> > > >> In that case, it's questionable what the value of the default view > > > is, > > > >> if by specifying a default view, you claim to support every view > > > that > > > >> can ever be imagined in the future. At the very least, I think the > > > spec > > > >> should be very clear about this point; I don't think most gadget > > > >> developers start by reading the spec through.
> > > > The default view should usually be an error or promotional message, > > > not a > > > > functional version of the gadget. That's exactly what it's intended > > > for. I'm > > > > all for adding explicitness in the spec -- it's far too ambiguous > > > now.
> > > >> It might be interesting to check the top x opensocial gadgets out > > > there > > > >> now, and see how they behave. If indeed they very seldom specify a > > > >> default view, checking the specified views would work.
> > > >> On the practical side, we do need the information on what views are > > > >> supported. If many gadgets have a default view, and no other way > > > exists > > > >> in the spec to decide what views are supported, it seems that we'd > > > >> either need to specify a hyves-specific extension to the spec, or > > > need > > > >> to collect the data when a gadget developer submits his gadget to > > > our > > > >> site. In the latter case, it would make sense that we'd share that > > > data > > > >> back to some/the central directory when it is released.
> > > > The developer has to change their spec in either case; changing it > > > to add > > > > explicit view enumeration on the content section is no different > > > from adding > > > > a new element. The new element requires implementations to change as > > > well > > > > though, which makes little sense if the developers have to modify > > > their > > > > gadgets anyway.
> > > > It's worth noting that the supporting the default is entirely > > > optional for > > > > containers. If your container chooses to ignore the default section, > > > that's > > > > perfectly acceptable.
> I'm not sure that gadget developers are currently using the default view in > this manner, nor will they adopt this approach unless containers standardize > on it. Once you start writing container-specific code, there's not much > point to using the "default" view, so all it takes is one container not > following this behavior to negate the utility of it.
> I'm for adding a clarification as to the intent of "default" view sections > to the spec. It's ambiguous and therefore not very useful (from a container > compatibility point of view) right now.
> ~Arne
> On Mon, Apr 14, 2008 at 12:10 PM, Kevin Brown <e...@google.com> wrote:
>> On Mon, Apr 14, 2008 at 5:21 AM, Reinoud Elhorst <rein...@hyves.nl> >> wrote:
>>> Is Kevin's view that "The default view should usually be an error or >>> promotional message, not a functional version of the gadget" the general >>> view in the community (I haven't checked how this is being done in real life >>> gadgets at the moment)? In this case, this should be in the gadget spec very >>> clearly. I do think however that this is at odds with the traditional google >>> gadgets and backwards compatibility.
>> This might be fairly controversial, but I've been thinking it for a while >> and I'm sure other people have as well -- is this really that important?
>>> I still stand with the original proposal to let the gadget (optionally) >>> specify with views it supports.
>>> At the very least, I think it should become clear what exactly the >>> "default" view is for, and this should be well documented.
>>> On Mon, Apr 14, 2008 at 2:00 PM, Cassie <d...@google.com> wrote:
>>>> Did we want to do anything to the spec for any of this?
>>>> - Cassie
>>>> On Wed, Apr 9, 2008 at 12:11 AM, Kevin Brown <e...@google.com> wrote: >>>> > On Tue, Apr 8, 2008 at 2:42 PM, Reinoud Elhorst <rein...@hyves.nl> >>>> wrote:
>>>> >> In that case, it's questionable what the value of the default view >>>> is, >>>> >> if by specifying a default view, you claim to support every view that >>>> >> can ever be imagined in the future. At the very least, I think the >>>> spec >>>> >> should be very clear about this point; I don't think most gadget >>>> >> developers start by reading the spec through.
>>>> > The default view should usually be an error or promotional message, >>>> not a >>>> > functional version of the gadget. That's exactly what it's intended >>>> for. I'm >>>> > all for adding explicitness in the spec -- it's far too ambiguous now.
>>>> >> It might be interesting to check the top x opensocial gadgets out >>>> there >>>> >> now, and see how they behave. If indeed they very seldom specify a >>>> >> default view, checking the specified views would work.
>>>> >> On the practical side, we do need the information on what views are >>>> >> supported. If many gadgets have a default view, and no other way >>>> exists >>>> >> in the spec to decide what views are supported, it seems that we'd >>>> >> either need to specify a hyves-specific extension to the spec, or >>>> need >>>> >> to collect the data when a gadget developer submits his gadget to our >>>> >> site. In the latter case, it would make sense that we'd share that >>>> data >>>> >> back to some/the central directory when it is released.
>>>> > The developer has to change their spec in either case; changing it to >>>> add >>>> > explicit view enumeration on the content section is no different from >>>> adding >>>> > a new element. The new element requires implementations to change as >>>> well >>>> > though, which makes little sense if the developers have to modify >>>> their >>>> > gadgets anyway.
>>>> > It's worth noting that the supporting the default is entirely optional >>>> for >>>> > containers. If your container chooses to ignore the default section, >>>> that's >>>> > perfectly acceptable.
|
