Proposal for 0.8: Declare which views are supported in the gadget xml
Reinoud Elhorst
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
John Hjelmstad
--John
Kevin Brown
<Content type="html" view="profile"/>
<Content type="html" view="canvas"/>
<Content type="html"/>
The supported views are "profile", "canvas", and "default".
If I have this:
<Content type="html"/>
The only supported view is "default".
If I have this:
<Content type="profile, canvas, magic, grandpa"/>
The supported views are "profile", "canvas", "magic", and "grandpa".
What cases aren't covered here?
~Kevin
Reinoud Elhorst
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.
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.
Reinoud Elhorst
Hyves
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH+02rqCQnCrE98GgRAp5bAKC5NOlDtezwp2GKMvEpL8q9xK//ZQCgoLM4
t3f6tbitQDHUaMQgAakZ3O4=
=N0D9
-----END PGP SIGNATURE-----
Kevin Brown
-----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.
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
Reinoud Elhorst
> On Tue, Apr 8, 2008 at 3:49 AM, Reinoud Elhorst <rei...@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
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
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.
--
~Kevin
Cassie
- Cassie
Reinoud Elhorst
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.
Kevin Brown
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?
--
~Kevin
Arne Roomann-Kurrik
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
OpenSocial IRC - irc://irc.freenode.net/opensocial
Cassie
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/1845cdb2f3d17777
Thanks.
- Cassie