Favicon/Link support?

[Paul Lindner]

Hi,

What’s the best way to get application specific favicons?  

I know that the spec support Activity.Field.STREAM_FAVICON_URL , but I’m interested in getting a default value for the app that could be specified in the gadget spec.  This would be used in the front-end UI.

My suggestion is that we support some variant of the existing <link> tag and adopt as much of existing html spec as possible:

   <link rel="icon" href="http://example.com/favicon.ico" type="image/vnd.microsoft.icon">
   <link rel="apple-touch-icon" href="/myicon.jpg"/>

This might also allow for adding TOS to a gadget spec as well:

  <link rel=”tos” href=”http://www.example.com/tos.html/”/>

[Kevin Brown]

I thought this was what the ModulePrefs.Icon element was for, but I could be mistaken.

--
~Kevin

[Paul Lindner]

Okay, I see it in the xsd.. Is there any other place that this is
documented?

I still like the idea of embedding <link> tags, since there will
likely be other types of content we may want to reference from a given
gadget definition and this covers just about all of them..

> > <link rel="tos" href="http://www.example.com/tos.html/"/><http://www.example.com/tos.html/%E2%80%9D/%3E>
> >
> > >
> >
>
>

--
Paul Lindner ||||| | | | | | | | | |
lin...@inuus.com

[Kevin Brown]

On Wed, Mar 5, 2008 at 3:45 PM, Paul Lindner <lin...@inuus.com> wrote:

Okay, I see it in the xsd..  Is there any other place that this is
documented?

Probably not. I think this was actually a feature that was in development as we were trying to figure out how to migrate the google gadgets format into something that made sense for an open standard. I'd call this one an "oversight" and something that needs clarification / modification / removal.
 

I still like the idea of embedding <link> tags, since there will
likely be other types of content we may want to reference from a given
gadget definition and this covers just about all of them..

I like this solution in general, but my only concern here is that understanding what "rel" means requires a bunch of possible rvalues for the server to interpret. It also would have to be elsewhere in the spec (ModulePrefs), since trying to extract it from the content would be difficult.

On Wed, Mar 05, 2008 at 03:14:39PM -0800, Kevin Brown wrote:
> I thought this was what the ModulePrefs.Icon element was for, but I could be
> mistaken.
>
> On Wed, Mar 5, 2008 at 3:09 PM, Paul Lindner <plin...@hi5.com> wrote:
>
> >  Hi,
> >
> > What's the best way to get application specific favicons?
> >
> > I know that the spec support Activity.Field.STREAM_FAVICON_URL , but I'm
> > interested in getting a default value for the app that could be specified in
> > the gadget spec.  This would be used in the front-end UI.
> >
> > My suggestion is that we support some variant of the existing <link> tag
> > and adopt as much of existing html spec as possible:
> >
> >    <link rel="icon" href="http://example.com/favicon.ico"
> > type="image/vnd.microsoft.icon">
> >    <link rel="apple-touch-icon" href="/myicon.jpg"/>
> >
> > This might also allow for adding TOS to a gadget spec as well:
> >

> >   <link rel="tos" href="http://www.example.com/tos.html/"/><http://www.example.com/tos.html/%E2%80%9D/%3E>
> >
> > >
> >
>
>

--
Paul Lindner        ||||| | | | |  |  |  |   |   |
lin...@inuus.com

--
~Kevin

[Paul Lindner]

On Wed, Mar 05, 2008 at 07:47:02PM -0500, Kevin Brown wrote:
> On Wed, Mar 5, 2008 at 3:45 PM, Paul Lindner <lin...@inuus.com> wrote:
>
> Okay, I see it in the xsd.. Is there any other place that this is
> documented?
>
> Probably not. I think this was actually a feature that was in
> development as we were trying to figure out how to migrate the
> google gadgets format into something that made sense for an open
> standard. I'd call this one an "oversight" and something that needs
> clarification / modification / removal.

Any suggestions on moving this forward?

> I still like the idea of embedding <link> tags, since there will
> likely be other types of content we may want to reference from a given
> gadget definition and this covers just about all of them..
>
>

> I like this solution in general, but my only concern here is that
> understanding what "rel" means requires a bunch of possible rvalues
> for the server to interpret. It also would have to be elsewhere in
> the spec (ModulePrefs), since trying to extract it from the content
> would be difficult.

How about adding them as child elements of ModulePrefs?

<ModulePrefs>
...
<link .. />
<link ... />
</ModulePrefs

Or a new top level element?

<ModuleLinks>
<link ... />
</ModuleLinks>

As for rel attributes, I just say store their literal values. I
expect that link tags are exposed as a list of items, nothing more,
the container/consumer can pick what it wants to do with each of
these.

Of course this also brings up another point, if one uses the lang
attribute we can localize content without having to do hangman
substitution:

<link rel="tos" lang="en" href="..." />
<link rel="tos" lang="es_ES" href="..." />

etc.

--
Paul Lindner ||||| | | | | | | | | |
lin...@inuus.com

[Kevin Brown]

On Wed, Mar 5, 2008 at 6:46 PM, Paul Lindner <lin...@inuus.com> wrote:

Any suggestions on moving this forward?

Since nobody (so far as I'm aware) is actually supporting <Icon> yet, I think we're pretty safe on making changes here. We probably need more feedback from other containers on this issue. I've added Nik Haldimann to the thread, since he was working on icon support for orkut before opensocial materialized.
 

How about adding them as child elements of ModulePrefs?

<ModulePrefs>
 ...
 <link ..  />
 <link ... />
</ModulePrefs

Or a new top level element?

<ModuleLinks>
 <link ... />
</ModuleLinks>

Child of ModulePrefs (consistent with other values). It's lame, but we should probably use <Link> instead of <link> for consistency's sake.
 

As for rel attributes, I just say store their literal values.  I
expect that link tags are exposed as a list of items, nothing more,
the container/consumer can pick what it wants to do with each of
these.

I think we'd want to define at least a small set of known rvalues initially, for things like favicon and the like.

Suggestions:

- canonical_url (Partially addresses issues of gadget identification when host names / urls move...very important issues for directory services)
- favicon (Optionally used by containers displaying a favicon in a canvas view)
- icon_32x32, icon_64x64, etc. (Different sizes for different contexts; highly useful for integration with mobile environments like iphone or android)

This could ultimately eliminate many of the module prefs attributes. I'm a big fan of the proposal for this reason alone.

Of course this also brings up another point, if one uses the lang
attribute we can localize content without having to do hangman
substitution:

 <link rel="tos" lang="en" href="..." />
 <link rel="tos" lang="es_ES" href="..." />

I think we should probably stick with hangman substitution for now, simply for consistency. This is a really worthwhile issue to bring up in potential future revisions of the spec, and I was thinking of things along the same lines myself, but I think we should leave it until we have some breathing room to introduce a new xml spec (with a new, or at least highly altered schema). That would be an opportunity to resolve other outstanding issues like only being able to specify one author, one author email address, etc. I don't want to distract from the core issue you're trying to address at the moment now though, so I'll save that discussion for another time.

[Paul Lindner]

To make our UI decent we decided to use the URL from the icon field as
part of our container support.

Here's our blog post on the topic:

http://www.hi5networks.com/developer/2008/03/add-an-icon-to-your-opensocial.html

> You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
> To post to this group, send email to opensocial-an...@googlegroups.com
> To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> -~----------~----~----~----~------~----~------~--~---
>

--
Paul Lindner ||||| | | | | | | | | |
lin...@inuus.com

[Niklaus Haldimann]

Chiming in a bit late on this ...

A clarification: My original design was for an Icon element within
ModulePrefs. That's what the canonical spec says too. From your blog
post it seems like you are supporting an icon attribute on
ModulePrefs.

I don't have a strong opinion whether to use <Icon> or the more
general <link> for this, but I think an attribute is inappropriate. An
element is preferrable because it's extensible, for example it allows
for multiple icons in the future (with, e.g., multiple sizes).

Nik

[Paul Lindner]

On Tue, Mar 11, 2008 at 12:12:57PM -0700, Niklaus Haldimann wrote:
>
> Chiming in a bit late on this ...
>
> A clarification: My original design was for an Icon element within
> ModulePrefs. That's what the canonical spec says too. From your blog
> post it seems like you are supporting an icon attribute on
> ModulePrefs.

You're correct, our error. We'd like to follow the specification, so
can you provide some examples of the correct usage?

From this XSD:

<xs:element name="Icon">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="mode">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="base64"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="type" type="xs:string"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>

It appears that this is the correct way to implement an Icon tag:

<Icon mode="base64" type="image/gif">
... Base64'd image here
</Icon>

I'd much prefer a link here instead of inlined content..

> I don't have a strong opinion whether to use <Icon> or the more
> general <link> for this, but I think an attribute is inappropriate. An
> element is preferrable because it's extensible, for example it allows
> for multiple icons in the future (with, e.g., multiple sizes).

Okay,

> > Paul Lindner ||||| | | | | | | | | |
> > lin...@inuus.com

[Kevin Brown]

On Tue, Mar 18, 2008 at 5:16 PM, Paul Lindner <lin...@inuus.com> wrote:

<Icon mode="base64" type="image/gif">
 ... Base64'd image here
</Icon>

I was under the impression (and Nik can correct me if I'm wrong on this one), that when "mode" was not present, we treated the value as a url. Perhaps we should modify this to make it so that the valid "mode" values are "url" and "base64"? I'm not really sure what's up with these attribute names, they seem wrong to me.

You might have noticed that this is how I implemented in Shindig. See http://svn.apache.org/viewvc/incubator/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/spec/Icon.java?view=markup

[Cassie]

To wrap up this proposal, does the spec need to change at all?
I couldn't figure out whether having the Icon tag within the ModulePrefs was good enough to do what you wanted Paul.

Thanks!

- Cassi

[Brian (MySpace)]

Can we get <xs:enumeration value="href"/> added to the spec? "href"
seems to be the common term in the spec so it is consistent. It
sounds like this behavior is supported by Shindig. Can we make it
official? Are there any plans to localize the icon? I understand it
is pretty small and my not be worth localizing, but while we are
discussing it we may as well understand all the consequences. MySpace
icons are 16x16, should a set size be decided?

Also, can we get the values for "type" nailed down? Then developers
would know 1.) what the platforms are looking for, 2.) what is
supported by each platform, and 3.) all the platforms can try to be
consistent.

On Apr 1, 4:18 am, Cassie <d...@google.com> wrote:
> To wrap up this proposal, does the spec need to change at all?
> I couldn't figure out whether having the Icon tag within the ModulePrefs was
> good enough to do what you wanted Paul.
>
> Thanks!
>
> - Cassi
>
>
>

> On Wed, Mar 19, 2008 at 2:38 AM, Kevin Brown <e...@google.com> wrote:

> > On Tue, Mar 18, 2008 at 5:16 PM, Paul Lindner <lind...@inuus.com> wrote:
>
> > > <Icon mode="base64" type="image/gif">
> > >  ... Base64'd image here
> > > </Icon>
>
> > I was under the impression (and Nik can correct me if I'm wrong on this
> > one), that when "mode" was not present, we treated the value as a url.
> > Perhaps we should modify this to make it so that the valid "mode" values are
> > "url" and "base64"? I'm not really sure what's up with these attribute
> > names, they seem wrong to me.
>
> > You might have noticed that this is how I implemented in Shindig. See

> >http://svn.apache.org/viewvc/incubator/shindig/trunk/java/gadgets/src...- Hide quoted text -
>
> - Show quoted text -

[John Hjelmstad]

Icon mode values: I personally favor "url", as IMHO it's more accurate and there's precedence in <Content type="url"...> for instance.

Icon type values: Agreed that type values should be nailed down. The obvious starting place is all approved MIME types with type="image" as defined by the IANA: http://www.iana.org/assignments/media-types/image/. However, this misses some common usages, particularly those prefixed "x-", eg. "image/x-icon" (many as shown here: http://www.w3schools.com/media/media_mimeref.asp)

Icon localization: Sounds reasonable, though I don't have a strong opinion. Three syntactical options for localizing:
1. Use message bundle hangman substitution eg. __MSG_icon_url__. This is a bit hacky, but uses existing logic paths and syntax.
Pros: Uses existing syntax and infrastructure. Cons: Hacky, overloads message substitution.
2. Add lang/country attributes to <Icon> declarations, making <Icon> repeatable.
Pros: Cleaner, doesn't conflate default value with lang-specific values, can use same lang/country selection algorithm as message bundles. Cons: Forces the issue of repeated Icon tags - problem? Also, repeats Locale-specific information in somewhere that's not MessageBundle specific.
3. Add <Locale> tags as children of <Icon>, eg. <Icon mode="url" type="image/x-icon"><Locale lang="en">http://foo.com/en.ico</Locale></Icon>
Pros: Confuses default value with locale-specific values syntactically, eg. <Icon...>defaultValueHere<Locale lang="en">enSpecificValue</Locale></Icon>.

Of these, #2 sounds cleanest to me.

Icon size: I think we should avoid encoding a default icon size in the spec, to avoid imposing particular layout/sizing requirements on containers and to keep the door open for changing common practice. That said, image resizing doesn't always yield pretty results. To me this suggests new declarative syntax for the size of a given icon, to allow a container the ability to select from the "best" match for the desired size. Eg.
<Icon mode="base64" type="image/x-icon" height="16" width="16">
  ...
</Icon>
<Icon mode="base64" type="image/x-icon" height="32" width="32">
</Icon>

This is sufficiently separate from mode/typing, so I'd suggest separating it into a separate spec request if desired, and punting on the issue in the meantime.

John

[Kevin Brown]

On Sun, Apr 6, 2008 at 10:05 AM, John Hjelmstad <fa...@google.com> wrote:

Icon mode values: I personally favor "url", as IMHO it's more accurate and there's precedence in <Content type="url"...> for instance.

HREF is never really appropriate for anything that isn't present as an html link, so I agree (href is an abbbreviation of "Hypertext Reference"). I think we're already inconsistent with this in the spec right now anyway though.

- <Locale> -- Uses the "messages" attribute, which is more semantically correct, but there's nothing in the name that tells you at first glance that it's supposed to be a url.

- <Preload> -- Uses "href", which really makes no sense, since Preloads are supposed to be pre-fetched http responses.

- <Content> Uses "href" (for type=url gadgets). This is also wrong, because it's not a link.

- <ModulePrefs> -- Labels some attributes as foo_url, and others that are also urls as foo (author_photo and thumbnail are both urls, but how are you supposed to know that without reading the spec?)

In future versions of the spec, we should clean up these inconsistencies.

Icon type values: Agreed that type values should be nailed down. The obvious starting place is all approved MIME types with type="image" as defined by the IANA: http://www.iana.org/assignments/media-types/image/. However, this misses some common usages, particularly those prefixed "x-", eg. "image/x-icon" (many as shown here: http://www.w3schools.com/media/media_mimeref.asp)

That's unnecessary in the same way that adding a type attribute to <script> tags are unnecessary. The server that serves the image will indicate the mime type. There's no reason to stick it in the spec (from a security perspective, you can't trust either anyway and you have to compare the mime type against a the file header to ensure it really is what it claims to be).

The type attribute was originally there to indicate inline files (base64 encoded representation of an image, similar to a data uri, as in "data:image/jpeg;<base64data>"). The history on this one is that this was something requested by the Google Toolbar team. It might be useful to retain this functionality, but that's a separate discussion from the use of mime types for remotely retrieved images. For data uris, the correct way to insert mime type is at the beginning of the data block.

I'd say the appropriate types would be "file" or "inline" if we support the inline stuff at all. Alternatively, we could be really "clever" and just let container types like toolbar to just support data: uris
 

Icon localization: Sounds reasonable, though I don't have a strong opinion. Three syntactical options for localizing:
1. Use message bundle hangman substitution eg. __MSG_icon_url__. This is a bit hacky, but uses existing logic paths and syntax.
Pros: Uses existing syntax and infrastructure. Cons: Hacky, overloads message substitution.

How does this overload message substitution? This is exactly how message substitution was designed to be used, and how it's currently used in every other context. I dislike the substitution mechanism, personally, but it's what's been supported thus far and it would be inappropriate to diverge for one element.
 

2. Add lang/country attributes to <Icon> declarations, making <Icon> repeatable.
Pros: Cleaner, doesn't conflate default value with lang-specific values, can use same lang/country selection algorithm as message bundles. Cons: Forces the issue of repeated Icon tags - problem? Also, repeats Locale-specific information in somewhere that's not MessageBundle specific.
3. Add <Locale> tags as children of <Icon>, eg. <Icon mode="url" type="image/x-icon"><Locale lang="en">http://foo.com/en.ico</Locale></Icon>
Pros: Confuses default value with locale-specific values syntactically, eg. <Icon...>defaultValueHere<Locale lang="en">enSpecificValue</Locale></Icon>.

Of these, #2 sounds cleanest to me.

And it's completely inconsistent with the rest of the spec. Sounds like a potential idea for a new schema, but in the current spec it would make implementation more difficult for containers while confusing developers with the inconsistency.

Icon size: I think we should avoid encoding a default icon size in the spec, to avoid imposing particular layout/sizing requirements on containers and to keep the door open for changing common practice. That said, image resizing doesn't always yield pretty results. To me this suggests new declarative syntax for the size of a given icon, to allow a container the ability to select from the "best" match for the desired size. Eg.
<Icon mode="base64" type="image/x-icon" height="16" width="16">

+1, though we might also want some semantic annotation such as <Icon type="favicon">, <Icon type="titlebar">, etc.

--
~Kevin

[John Hjelmstad]

On Sun, Apr 6, 2008 at 9:30 PM, Kevin Brown <et...@google.com> wrote:

On Sun, Apr 6, 2008 at 10:05 AM, John Hjelmstad <fa...@google.com> wrote:

Icon mode values: I personally favor "url", as IMHO it's more accurate and there's precedence in <Content type="url"...> for instance.

HREF is never really appropriate for anything that isn't present as an html link, so I agree (href is an abbbreviation of "Hypertext Reference"). I think we're already inconsistent with this in the spec right now anyway though.

- <Locale> -- Uses the "messages" attribute, which is more semantically correct, but there's nothing in the name that tells you at first glance that it's supposed to be a url.

- <Preload> -- Uses "href", which really makes no sense, since Preloads are supposed to be pre-fetched http responses.

- <Content> Uses "href" (for type=url gadgets). This is also wrong, because it's not a link.

- <ModulePrefs> -- Labels some attributes as foo_url, and others that are also urls as foo (author_photo and thumbnail are both urls, but how are you supposed to know that without reading the spec?)

In future versions of the spec, we should clean up these inconsistencies.

True. So "url".
 

Icon type values: Agreed that type values should be nailed down. The obvious starting place is all approved MIME types with type="image" as defined by the IANA: http://www.iana.org/assignments/media-types/image/. However, this misses some common usages, particularly those prefixed "x-", eg. "image/x-icon" (many as shown here: http://www.w3schools.com/media/media_mimeref.asp)

That's unnecessary in the same way that adding a type attribute to <script> tags are unnecessary. The server that serves the image will indicate the mime type. There's no reason to stick it in the spec (from a security perspective, you can't trust either anyway and you have to compare the mime type against a the file header to ensure it really is what it claims to be).

The type attribute was originally there to indicate inline files (base64 encoded representation of an image, similar to a data uri, as in "data:image/jpeg;<base64data>"). The history on this one is that this was something requested by the Google Toolbar team. It might be useful to retain this functionality, but that's a separate discussion from the use of mime types for remotely retrieved images. For data uris, the correct way to insert mime type is at the beginning of the data block.

I'd say the appropriate types would be "file" or "inline" if we support the inline stuff at all. Alternatively, we could be really "clever" and just let container types like toolbar to just support data: uris

Makes sense. So you're saying that the type value provides no useful hint in the case of inline data? Or would you suggest deprecating type overall?
 

 

Icon localization: Sounds reasonable, though I don't have a strong opinion. Three syntactical options for localizing:
1. Use message bundle hangman substitution eg. __MSG_icon_url__. This is a bit hacky, but uses existing logic paths and syntax.
Pros: Uses existing syntax and infrastructure. Cons: Hacky, overloads message substitution.

How does this overload message substitution? This is exactly how message substitution was designed to be used, and how it's currently used in every other context. I dislike the substitution mechanism, personally, but it's what's been supported thus far and it would be inappropriate to diverge for one element.

Because they're not messages/language, and are more "code-like." I'm fine with this option myself as well though.
 

 

2. Add lang/country attributes to <Icon> declarations, making <Icon> repeatable.
Pros: Cleaner, doesn't conflate default value with lang-specific values, can use same lang/country selection algorithm as message bundles. Cons: Forces the issue of repeated Icon tags - problem? Also, repeats Locale-specific information in somewhere that's not MessageBundle specific.
3. Add <Locale> tags as children of <Icon>, eg. <Icon mode="url" type="image/x-icon"><Locale lang="en">http://foo.com/en.ico</Locale></Icon>
Pros: Confuses default value with locale-specific values syntactically, eg. <Icon...>defaultValueHere<Locale lang="en">enSpecificValue</Locale></Icon>.

Of these, #2 sounds cleanest to me.

And it's completely inconsistent with the rest of the spec. Sounds like a potential idea for a new schema, but in the current spec it would make implementation more difficult for containers while confusing developers with the inconsistency.

Inconsistent in what way? In that the syntax isn't already present? :)
 

[Brian (MySpace)]

"url" is fine with me, as long as we can get something in the spec.

Mr. Hjelmstad makes a valid point about the mime type when the file is
inline. Otherwise it will be more difficult to determine what format
it is (gif, jpg, etc).

I don't think many developers will need to have multiple icons for
multiple languages / countries. It is only 16x16 (or thereabouts),
anything more than a character or two will be difficult to read to
begin with.

I like the width and height, but we can go with the "type" idea. I do
think developers may end up with multiple icons of varying sizes for
the different platforms.

[Kevin Brown]

On Mon, Apr 7, 2008 at 5:20 AM, John Hjelmstad <fa...@google.com> wrote:

Makes sense. So you're saying that the type value provides no useful hint in the case of inline data? Or would you suggest deprecating type overall?

Not quite -- I'm saying that there's a precedent for inline, base64 encoded images: data uris, and it would make a lot of sense to just follow that standard here.

<Icon>http://example.org/icon.png</Icon>
<Icon>data:image/jpeg;<data></Icon>

And it's completely inconsistent with the rest of the spec. Sounds like a potential idea for a new schema, but in the current spec it would make implementation more difficult for containers while confusing developers with the inconsistency.

Inconsistent in what way? In that the syntax isn't already present? :)

In that it would introduce a custom localization mechanism for one element in the spec that differs from how localization is done everywhere else in the spec.

--
~Kevin

[John Hjelmstad]

* "type" makes conceptual sense to me, but I wonder if we'd end up with a situation that encodes size directly in our type values anyway, eg. "favicon" to start, then "favicon32x32" at some unspecified point when browsers up the resolution-ante (or equivalent such condition).

* True, adding lang/country to Icon introduces custom localization, but the argument here is that this is a fundamentally new type of localization, different than messages. I could be persuaded either way (eg. options #1 or #2 that I'd listed).

John

[Brian (MySpace)]

On Apr 7, 2:40 pm, "Kevin Brown" <e...@google.com> wrote:
> On Mon, Apr 7, 2008 at 5:20 AM, John Hjelmstad <fa...@google.com> wrote:
> > Makes sense. So you're saying that the type value provides no useful hint
> > in the case of inline data? Or would you suggest deprecating type overall?
>
> Not quite -- I'm saying that there's a precedent for inline, base64 encoded
> images: data uris, and it would make a lot of sense to just follow that
> standard here.
>
> <Icon>http://example.org/icon.png</Icon>
> <Icon>data:image/jpeg;<data></Icon>
>

This is the first example I have seen of how the data should be
formatted and I was not aware that the type would be included as you
have indicated. Is this documented anywhere? Do developers know
about this? Have any developers implemented it anywhere?

The only information I have gotten on this so far has been from the
XSD and from this thread. I couldn't find any information in the
Google OpenSocial documentation and I am wondering if developers are
confused or if it is just me.

[Kevin Brown]

On Tue, Apr 8, 2008 at 4:41 PM, Brian (MySpace) <bfr...@myspace.com> wrote:

This is the first example I have seen of how the data should be
formatted and I was not aware that the type would be included as you
have indicated.  Is this documented anywhere?  Do developers know
about this?  Have any developers implemented it anywhere?

Sorry, this isn't actually in the spec in the present form. I'm just proposing that we use the standard data uris. Many browsers (FF2+, IE8, newer versions of Opera and Safari) support this syntax, so it would be natural to support the syntax. Servers can easily transform the base 64 encoded data into an appropriate output image.

The only information I have gotten on this so far has been from the
XSD and from this thread.  I couldn't find any information in the
Google OpenSocial documentation and I am wondering if developers are
confused or if it is just me.

I think the only public thing at this point (other than the mailing list) is what's in the XSD and this thread. We've been debating the right way to do icon support, not discussing how it's actually meant to be used. So far as I can tell, nobody actually supports <Icon> yet, so it probably doesn't matter what the final outcome of this discussion is.

--
~Kevin

[Cassie]

I'm having a little bit of a hard time following this thread.

There is a discussion going on over here:
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/c146cb26feb86885#
Which wants to add a general "link" type to the module prefs. This
link type would have a rel and href param.

Brian from myspace - is this what you were looking for? Do you want to
comment over on the other thread? Or is this discussion taking us
somewhere entirely new?

Thanks for holding my hand :)

- Cassie

[Amar Gandhi]

Is there status on support for Favicons? We would like to implement them in
Orkut but are blocked on the spec.

As with help/support links, I'll defer to the majority on the exact syntax.
All we need is a way to programmatically fetch a favicon.ico url.

[Cassie]

I am officially closing this thread discussion and considering it being taken over by this one:
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/c146cb26feb86885#

Amar - you will find what you are looking for over there.
Thanks.

- Cassie