Adding a version identifier for the gadget...

[Mark W.]

During an internal review of the versioning work (http://
codereview.appspot.com/152136) the question was raised about a
versioning scheme for the gadget itself. We have a version identifier
for the spec and required features, but not for the entire gadget. I
thought, at one point, this was discussed, if it was, I apologize for
brining it up again. I did a quick troll through these threads and it
jump out at me.

That said... The feeling was that this was a valuable piece of meta
data that can be used in multiple places, e.g. tooling, when a gadget
is added to the container, et...

Since we've done the work to describe the version scheme, and we've
added @specificationVersion, could we also add a @gadgetVersion or
@moduleVersion. This could conform to the same scheme as everything
else, and (if it's optional) follow the same defaults as
@specificationVersion.

Thanks,

-Mark W.

[David Boyer]

Is there a case where a gadget provider would have two different
implementations of a gadget targeted at different versions of the
OpenSocial spec?

It seems reasonable to me that we would target 0.9 for the next 6
months, in anticipation of 0.9 support at major social sites soon (if
not already), but that the 1 year goal would be 1.0.

Say it a different way,

The way I read Mark's statement. I would have a gadget url, and a
version inside the gadget. There would only ever be one version of
the gadget available.

What if we could add there was a standard mechanism for the container
to indicate its version support when it requests the gadget. Examples
might be :

* http://example.com/gadgets/mygadget.xml?version=1.0
* http://example.com/gadgets/mygadget.xml#1.0
* http://example.com/gadgets/mygadget.xml?supports=1.0.22,0.9.1,0.8

This could be taken too far. Might be to much. Nice thing about it,
is that containers could do this now, with current gadgets and nothing
would break. They would just be ignored. It wouldn't obviate the
need for the rendering engine to check to make sure that he could
render the gadget.xml received.

The negative part of the way I suggest it is that it could only work
with gadget provider service that was implemented via some dynamic
http service to interpret the versioning data. It couldn't be done
with static files.

The static compatible alternative would be a gadget file naming
convention. Like

For a container that supported 1.2.12, 1.1.13, 1.0.5, and 0.9.1 he
might make a series of requests
http://example.com/gadgets/mygadget.1.2.12.xml
http://example.com/gadgets/mygadget.1.2.xml
http://example.com/gadgets/mygadget.1.1.13.xml
<you get the idea>

That's potentially a lot of 404s. Not sure if that's as bad as it
seems, but basic line latency would cause a potentially large lag in
perceived responsiveness depending on how far down the stack you had
to go to find a gadget you could render.

Just brainstorming out loud.

[Jon]

The idea of a version is so universal it might be a good idea to
standardize on a gadget version. From the spec side we could specify
the format, e.g. X.Y.Z, and suggest meanings. This would give
management tools something standard to look for in gadgets, but what
they would do is probably be out of scope for the spec. Plus this
value needs to be part of the gadget XML.

I think how we find a gadget (e.g. its URL) could include versioning
of some type, but once the XML is located, everything you need to know
is inside it..

On Dec 4, 8:15 am, David Boyer <mang...@gmail.com> wrote:
> Is there a case where a gadget provider would have two different
> implementations of a gadget targeted at different versions of the
> OpenSocial spec?
>
> It seems reasonable to me that we would target 0.9 for the next 6
> months, in anticipation of 0.9 support at major social sites soon (if
> not already), but that the 1 year goal would be 1.0.
>
> Say it a different way,
>
> The way I read Mark's statement.  I would have a gadget url, and a
> version inside the gadget.  There would only ever be one version of
> the gadget available.
>
> What if we could add there was a standard mechanism for the container
> to indicate its version support when it requests the gadget. Examples
> might be :
>
>  *http://example.com/gadgets/mygadget.xml?version=1.0
>  *http://example.com/gadgets/mygadget.xml#1.0

>  *http://example.com/gadgets/mygadget.xml?supports=1.0.22,0.9.1,0.8

>
> This could be taken too far. Might be to much.  Nice thing about it,
> is that containers could do this now, with current gadgets and nothing
> would break.  They would just be ignored.  It wouldn't obviate the
> need for the rendering engine to check to make sure that he could
> render the gadget.xml received.
>
> The negative part of the way I suggest it is that it could only work
> with gadget provider service that was implemented via some dynamic
> http service to interpret the versioning data.  It couldn't be done
> with static files.
>
> The static compatible alternative would be a gadget file naming
> convention. Like
>
> For a container that supported 1.2.12, 1.1.13, 1.0.5, and 0.9.1 he

> might make a series of requestshttp://example.com/gadgets/mygadget.1.2.12.xmlhttp://example.com/gadgets/mygadget.1.2.xmlhttp://example.com/gadgets/mygadget.1.1.13.xml

[Randy Hudson]

Why doesn't fetching a gadget spec work the rest of the way the
Internet works?
For example:

GET http://www.google.com/ig/modules/horoscope.xml
Accept: application/opensocial-0.9+xml,application/
opensocial-0.8+xml;q=0.9,*/*;q=0.8

Accept-Language: en-us,en;q=0.5

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Accept-Encoding: gzip,deflate

[other standard request headers]
------------------------------------------------------------------------
HTTP/1.x 200 OK

Content-Type: application/opensocial-0.9+xml; charset=UTF-8

Expires: Fri, 04 Dec 2009 18:14:25 GMT

Cache-Control: public, max-age=3600

Content-Encoding: gzip

[other standard response headers]
...

And the entity would contain the appropriate gadget specification for
an OpenSocial 0.9-compliant container, with localized (US English)
content.

Imagine if browsers worked like this:
How to render a web page to the User given a URL:
1. Load the document at the given URL
2. Iff the document looks like a "manifest" to other documents:
2.1. Process the manifest, looking for the desired entry (e.g.
html, xhtml, html5, etc.)
2.2. Load the document at the URL for the matched entry
3. Search the currently loaded document for "Message Bundles", for
each bundle entry:
3.1. Load the message bundle at the entry's URL
3.2. In certain places (you have to guess) perform message
substitution
3.3. Loop
4. Done

Yuck! But even worse, now there are multiple, public URLs to each
format of the same document. I might decide to link to the URL for
the xhtml version of a page. This isn't how the web usually works.

I think there are benefits to using headers for content negotiation
with gadgets too. Message Bundles and Application Manifests could be
removed from the spec, becoming internal/implementation details to
those serving up gadget specs.

[David Boyer]

Great point.

On Dec 4, 1:50 pm, Randy Hudson <randy.hud...@gmail.com> wrote:
> Why doesn't fetching a gadget spec work the rest of the way the
> Internet works?
> For example:
>

> GEThttp://www.google.com/ig/modules/horoscope.xml

[Kevin Brown]

On Fri, Dec 4, 2009 at 10:50 AM, Randy Hudson <randy....@gmail.com> wrote:

Why doesn't fetching a gadget spec work the rest of the way the
Internet works?

I agree with what you're saying in principal, but unfortunately there are far too many gadget authors who don't fully understand these specifications (and the tools that they use do a poor job of implementing them).

After all, this is the reason why the spec requires honoring "refresh" parameters for various HTTP requests as an override for HTTP headers.

That said, while what you've proposed is how the internet works in the specs, it's not exactly how it works in reality. How many websites actually honor Accept-* correctly? Accept-Encoding is the only thing I'm confident works in most situations.

--

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.

[Tim Moore]

There was a proposal that was considered for 0.9 and then dropped due
to time constraints:

http://wiki.opensocial.org/index.php?title=Versioning_Applications

[Mark W.]

So it seems like some of the concepts got included but not all. Given
that we've now defined the version scheme, and have very little
semantics around @specificationVersion, is it worth considering adding
@gadgetVersion. My concern is that the current schemas don't have
extensibility elements in them. Adding this in another version would
require a schema change, and likely introduce compatibility issues--
resulting in 2.0.

-Mark W.

[Randy Hudson]

> I agree with what you're saying in principal, but unfortunately there are
> far too many gadget authors who don't fully understand these specifications
> (and the tools that they use do a poor job of implementing them).

What I'm proposing has little impact on gadget authors. Sites that
host gadget specs could still support message bundles and application
manifests, but such things would be taken out of the spec in favor of
standard content negotiation using headers.

An analogy would be HTML and JSP. Browsers don't have a clue what JSP
is, yet HTML developers can still use it for i18n and other features
on servers that support it.

> That said, while what you've proposed is how the internet works in the
> specs, it's not exactly how it works in reality. How many websites actually
> honor Accept-* correctly? Accept-Encoding is the only thing I'm confident
> works in most situations.

So, some websites don't respond differently to accept headers? I
don't understand. The issue is how should content negotiation work,
and it sounds like you're saying some sites don't support content
negotiation. That's doesn't seem like a vote for either approach.

[Tim Moore]

My concern is that versioning gadgets themselves will probably require
a lot of new behavior in the containers in order to support the
ability for users to choose between several versions, or to choose
automatically based on criteria specified by the gadget author (like
in the original proposal). I think that puts it outside of the scope
that we decided on for 1.0. I agree that it is something that will be
important to have, though, so it should probably be a high priority
for 1.1.

I believe that the consensus from the "Gadgets XML reference" thread
[1] was that the schema should allow for extension where it makes
sense. Right now it says that containers must allow non-validating
spec files, for better or worse, so adding a new attribute in 1.1
shouldn't cause any backwards-compatibility issues as long as it's
optional.

-- Tim

[1] http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/4eb813e1ccdc0b6a

[Mark W.]

A couple of thoughts/questions....

I'm not sure that the new behavior/semantics introduced to support a
gadget version would have to be that much different than what we've
got to add for @specificationVersion.

I've got a bigger question on this:

"Right now it says that containers must allow non-validating
spec files, for better or worse, so adding a new attribute in 1.1
shouldn't cause any backwards-compatibility issues as long as it's
optional."

One of the things we are talking about in the threads on compliance
and extensions is if/how we add wildcard elements to the schemas so
they validate. If the spec has the text above in it, then I'd argue
that we don't need schema validation at all and should not even try to
do it. We could come up with some words that say you MUST have the
following elements, that SHOULD look like this schema, but you MAY
have additional elements.

I was under the impression that going forward, we wanted to be able to
validate a gadget xml with the schema. So while containers should
support 0.9 and prior in a non-validating way, once we publish 1.0, is
this when we expect to validate using XSDs?

-Mark W.

On Dec 7, 2:21 pm, Tim Moore <tmo...@atlassian.com> wrote:
> My concern is that versioning gadgets themselves will probably require
> a lot of new behavior in the containers in order to support the
> ability for users to choose between several versions, or to choose
> automatically based on criteria specified by the gadget author (like
> in the original proposal). I think that puts it outside of the scope
> that we decided on for 1.0. I agree that it is something that will be
> important to have, though, so it should probably be a high priority
> for 1.1.
>
> I believe that the consensus from the "Gadgets XML reference" thread
> [1] was that the schema should allow for extension where it makes
> sense. Right now it says that containers must allow non-validating
> spec files, for better or worse, so adding a new attribute in 1.1
> shouldn't cause any backwards-compatibility issues as long as it's
> optional.
>
> -- Tim
>

> [1]http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thr...

[Lane LiaBraaten]

Keep in mind that lots of gadget specs are hosted on static file servers so using HTTP headers or URL parameters for versioning is a non-starter.

-Lane

[Randy Hudson]

> Keep in mind that lots of gadget specs are hosted on static file servers so
> using HTTP headers or URL parameters for versioning is a non-starter.
>
> -Lane

Sure, there's stuff out there today, but that's not a reason not to
fix what's broken.

[Lane LiaBraaten]

I'm confident we can find a solution that allows developers to take advantage of gadget versioning while not imposing new requirements for the hosting environment.

-Lane

[Tim Moore]

On Dec 7, 12:34 pm, "Mark W." <weitz...@us.ibm.com> wrote:
> A couple of thoughts/questions....
>
> I'm not sure that the new behavior/semantics introduced to support a
> gadget version would have to be that much different than what we've
> got to add for @specificationVersion.

I guess that depends on what those semantics would be. Maybe we've got
different ideas in mind. Are we talking about just pointing to
different gadget spec files for different specification versions?

Supporting @specificationVersion in a 1.0 container won't require
doing anything more than checking for the attribute and refusing to
render gadgets that specify a value >1.0.

What requirements did you have in mind for gadget versioning?

> I've got a bigger question on this:
> "Right now it says that containers must allow non-validating
> spec files, for better or worse, so adding a new attribute in 1.1
> shouldn't cause any backwards-compatibility issues as long as it's
> optional."
>
> One of the things we are talking about in the threads on compliance
> and extensions is if/how we add wildcard elements to the schemas so
> they validate. If the spec has the text above in it, then I'd argue
> that we don't need schema validation at all and should not even try to
> do it. We could come up with some words that say you MUST have the
> following elements, that SHOULD look like this schema, but you MAY
> have additional elements.
>
> I was under the impression that going forward, we wanted to be able to
> validate a gadget xml with the schema. So while containers should
> support 0.9 and prior in a non-validating way, once we publish 1.0, is
> this when we expect to validate using XSDs?

I would prefer if the spec allowed containers to validate using a
schema that allows controlled extension, but I'm not 100% up to speed
with where the progress on that is. Assuming either that we have a
schema that allows a new attribute in the Module element or that we
continue to disallow validation against the schema, there wouldn't be
a backwards-compatibility issue adding a version attribute in a 1.1
spec version.

-- Tim

[Mark W.]

<<Are we talking about just pointing to different gadget spec files
for different specification versions?>>

I wasn't thinking it would necessarily have to be separate files.
Here's the SocialHelloWorld.xml from shindig. Notice I just added the
version attribute. We came across this as we were reviewing this
proposal internally. We compared what OpenSocial had to what we've
done internally as well as what groups like OpenAjax have done (http://
www.openajax.org/member/wiki/OpenAjax_Metadata_Specification_Widget_Metadata#widget_element_version_attribute).
OpenAjax, for example, simply says, "The version attribute specifies
the version number that the widget developer has assigned to this
widget."

In terms of semantics, that's about all I was thinking. Going forward,
we could add more semantics around it if we want/need to.


<Module>
<ModulePrefs title="Social Hello World"
description="The Social Hello World Application Displays
multilingual hello messages"
thumbnail="http://localhost:8080/"
icon="http://localhost:8080/gadgets/files/
samplecontainer/examples/icon.png" version="1.0.0">
<Require feature="osapi"></Require>
<Require feature="dynamic-height"></Require>
</ModulePrefs>

-----
Re: Schema validation...
Are you thinking schema validation of:
a) gadget xml
II) data models only
3) request/respons xml (rest)
d) all of the above

(maybe want to start a separate thread with reply to above...)

[Jon]

I think we have come full circle, passing through the Application
Manifest concept. If we do anything for 1.0, I'm "+1" for what Mark
and some others propose: Simply adding an attribute in the Gadget XML.
Implementations are totally free to ignore it, but it standardizes on
an attribute name, and perhaps values for the attribute (e.g. is
"1.0.1a" legal? And what might it mean?). Some containers may use it,
and more will over time.

Jon

On Dec 8, 6:05 pm, "Mark W." <weitz...@us.ibm.com> wrote:
> <<Are we talking about just pointing to different gadget spec files
> for different specification versions?>>
>
> I wasn't thinking it would necessarily have to be separate files.
> Here's the SocialHelloWorld.xml from shindig. Notice I just added the
> version attribute. We came across this as we were reviewing this
> proposal internally. We compared what OpenSocial had to what we've

> done internally as well as what groups like OpenAjax have done (http://www.openajax.org/member/wiki/OpenAjax_Metadata_Specification_Widget_M...).

> OpenAjax, for example, simply says, "The version attribute specifies
> the version number that the widget developer has assigned to this
> widget."
>
> In terms of semantics, that's about all I was thinking. Going forward,
> we could add more semantics around it if we want/need to.
>
> <Module>
>  <ModulePrefs title="Social Hello World"
>               description="The Social Hello World Application Displays
> multilingual hello messages"
>               thumbnail="http://localhost:8080/"
>               icon="http://localhost:8080/gadgets/files/
> samplecontainer/examples/icon.png" version="1.0.0">
>    <Require feature="osapi"></Require>
>    <Require feature="dynamic-height"></Require>
>  </ModulePrefs>
>

> > -- Tim

[Randy Hudson]

> I'm confident we can find a solution that allows developers to take
> advantage of gadget versioning while not imposing new requirements for the
> hosting environment.

Where can I find a hosting environment that has solved the problem of
hosting multiple incarnations of the same gadget, i.e. one per
revision of the OpenSocial spec?

[Dave]

Randy,

The point that Lane is making is that he does not want to add more
barriers to entry for Gadget developers. At this point you can create
a Gadget and make it available with nothing more than static web
server, no server side logic, header parsing, etc. required.

I could be wrong here, but I believe the consensus in the OpenSocial
community is that we want a versioning solution that works in the very
same hosting environment.

- Dave

[Randy Hudson]

> Randy,
>
> The point that Lane is making is that he does not want to add more
> barriers to entry for Gadget developers. At this point you can create
> a Gadget and make it available with nothing more than static web
> server, no server side logic, header parsing, etc. required.

Developers could still do that, just as you can with HTML. The
barrier to entry for gadget developers is between developer and gadget
host. How a container then negotiates versions with that gadget host
does not directly impact the gadget developers.

> I could be wrong here, but I believe the consensus in the OpenSocial
> community is that we want a versioning solution that works in the very
> same hosting environment.

But that's what I was (poorly) hinting at in my last reply. If the
hosting environment is them "same", then what is versioning solution?
AFAIK, there isn't one today. Lane implied that my suggestion would
be a new requirement for gadget hosts. But the new requirement is
that gadget hosts support version negotiation. I was just proposing
one solution.

I can certainly appreciate why someone invested in an existing gadget
host might be reluctant to agree to make changes, but unless that host
has already solved the problem, some amount of change seems
inevitable. Processing HTTP headers does not seem like an
unreasonable amount of work. Existing hosts which completely ignore
the headers would still work fine.

While this is some additional logic at the gadget host, it would at
the same time simplify things on the other side (the gadget container).

[Lane LiaBraaten]

I think we're talking past each other w.r.t. terminology.  When I say hosting environment I mean the system that makes the gadget XML file available on the internet.  

For example, the Google Gadget editor provides hosting for gadget XML files, but the developer can't control the HTTP headers used when a container (e.g. MySpace) fetches the gadget XML file.

-Lane

[Chirag Shah]

> For example, the Google Gadget editor provides hosting for gadget XML files,
> but the developer can't control the HTTP headers used when a container (e.g.
> MySpace) fetches the gadget XML file.

Doesn't Myspace require developers to upload their gadget XML file
rather than making an HTTP request to fetch it?
http://wiki.developer.myspace.com/uploads/5/56/AppGadgetXmlButton.png

[Randy Hudson]

On Dec 10, 5:23 pm, Lane LiaBraaten <lliab...@google.com> wrote:
> I think we're talking past each other w.r.t. terminology.  When I say
> hosting environment I mean the system that makes the gadget XML file
> available on the internet.

Yes, that was my understanding as well.

> For example, the Google Gadget editor provides hosting for gadget XML files,
> but the developer can't control the HTTP headers used when a container (e.g.
> MySpace) fetches the gadget XML file.

It's not surprising that GGE doesn't support something that doesn't
exist. If the change were made to use headers, GGE may one day decide
to support it via any number of possible tool enhancements. If GGE
does *not* change at all, it continues to work just the same as it
does today.

By the same logic, I guess data pipelining shouldn't be in the spec,
since GGE doesn't support it?

[Dave]

If you have a better proposal for gadget version then please write it
up so folks can consider it in full and vote on it. However, I think
you are going to find resistance and I'll try to explain why.

Currently a gadget developer can make his gadget available by placing
it on the web on a simple static web server or a simple file sharing
service where he has no access to server-side logic and thus no
ability to parse headers, participate in content negotiation, etc. In
other words, the current gadget hosting requirements do not require
server-side logic.

By asking gadget developers to use accept headers and content
negotiation, as you have suggested, you are adding new hosting
requirements -- requiring gadget developers to place their gadgets on
a web server with some form of server-side logic that can parse
headers, etc. That is a big deal and I think most folks are going to
vote -1 to a proposal that introduces a dependency on server side
logic for gadget hosting. I know I would.

- Dave

[Mark W.]

OK...

So we've bounced around a lot on this thread. Following Dave's
suggestion, I'd like to make a concrete proposal. Here it is:

We should add @moduleVersion to the Module.

The text would read:
<t>
Gadget definitions SHOULD contain a @moduleVersion in the root Module
element. The value of @moduleVersion MUST conform to the rules defined
in the <xref target="Versioning">Versioning</xref> section of this
spec.
</t>

We would have to add the element @moduleVersion to the canonical XSD
as well. This essentially is all that we need to do for 1.0 and all I
was suggesting we add.

Could we get some +1 or -1 on just that concept?

-Mark W.


On Dec 14, 3:15 pm, Dave <snoopd...@gmail.com> wrote:

[Jon]

Which of these are true:
If a gadget developer chooses to use moduleVersion, and the
moduleVersion is unchanged:

1) The container can assume that the gadget XML itself is unchanged
(or interchangeable with others of the same version).

2) The container can assume that the "gadget" is unchanged (or
interchangeable). By "gadget" I mean everything associated with it:
external message bundles, external JavaScript and images, etc...

[Lane LiaBraaten]

Could someone provide a couple of use cases that we're trying to address here?

Thanks,

Lane

[Randy Hudson]

> Currently a gadget developer can make his gadget available by placing
> it on the web on a simple static web server or a simple file sharing
> service where he has no access to server-side logic and thus no
> ability to parse headers, participate in content negotiation, etc. In
> other words, the current gadget hosting requirements do not require
> server-side logic.

That's not true for gadgets in general*, but, even so, this would not
change even if headers were the mechanism for negotiating content**.
What you all are saying applies to HTML as well, yet developers can
still host HTML on static web servers. Headers are the mechanism for
negotiating HTML content, but server processing of headers is
optional. Is hosting gadgets so much different than hosting HTML that
we need to reinvent the wheel. Is there any chance that servers
hosting gadgets also need to host HTML resources referenced by those
gadgets?

Ok, that was my last stand. I'm going to surrender on the whole
headers idea before I get decapitated myself.

*Gadgets which use data pipelining, OAuth, or any other number of
OpenSocial features require server-side logic.

**Just to clarify, the use of headers I'm proposing is only to
negotiate the version of the OpenSocial Spec to which the gadget was
written.

[Randy Hudson]

> We should add @moduleVersion to the Module.
>

> Could we get some +1 or -1 on just that concept?
>
> -Mark W.

This sounds fine to me. Perhaps "version" would be sufficient and
match "title", "author" etc., (if its an attribute of that same
element). To make sure I understand, the version is describing the
features of the gadget, right? In other words, the gadget's version
might change (indicating some new function) even though it still
depends on the same level of the OpenSocial spec. Other than display
this to the user, would containers do anything else with this
attribute?

I'm more interested in which version(s) of OpenSocial Spec the
different versions of a gadget supports, and then how does a container
gets to these different versions of an application.

Can a 0.9 container optimize the rendered gadget when it knows the
gadget only requires 0.8 and not 0.9? (i.e., Does the container need
to declare functions like "_IG_FetchXmlContent" that aren't even in
the spec?)

How does a new version of the application take advantage of 0.9
features while still making available the 0.8-compatible version for
containers that don't yet support 0.9? How do containers know about
the existence of these different versions?

Is it legal for a gadget to require features "opensocial-0.8" and
"osapi.data" at the same time?

[Mark W.]

Randy,

> To make sure I understand, the version is describing the
> features of the gadget, right?  In other words, the gadget's version
> might change (indicating some new function) even though it still
> depends on the same level of the OpenSocial spec.  

Correct.

> Other than display
> this to the user, would containers do anything else with this
> attribute?

At this point, it is undefined what the container would do with it. It
could be used in various scenarios, including tooling and container
deployment. The reason that I'm proposing adding it here is, in part,
to help us get some consistency across the different widget/gadget
formats that are leveraged within an enterprise. This would help the
be managed consistently.

The other questions you raise have to do more with
@specificationVersion. I'll let the other folks take a stab at them
first.

-Mark W.

[Mark W.]

Jon,

I don't think we need to infer any kind of relationship, at this
point, between container and moduleVersion. In this way, it works the
same way it does today and is a more formalized mechanism of
specifying the version of the module versus simply adding xml
comments.

I think we could introduce behavior around module version if we
wanted. I'd look at this more along the lines of APIs and semantics
(similar to what we've defined in the versioning section) the physical
file changes. For example, if I've got a gadget, version 1.0.0, that
inlines all the javascript, and I then choose to externalize it in a
separate file, I should not be required to change the version number.
Ditto for internationalization. However, if I add APIs, but don't
change/remove existing ones, I'd expect an increment in the version.
(Expect, but not require.)

-Mark W.

[Tim Moore]

That sounds fine to me. +1

-- Tim

On Dec 15, 5:46 am, "Mark W." <weitz...@us.ibm.com> wrote:

[Dave]

+1

[Evan Gilbert]

Clarification needed (sorry, this thread is long & confusing) - is @moduleVersion for a developer with multiple versions of their same gadget?

If so, I'm slightly against (close to a -1 but could be swayed). The previous spec proposal @ http://wiki.opensocial.org/index.php?title=Versioning_Applications was a cleaner solution for this use case and one that we already agreed was a good spec enhancement (the only reason it didn't make it into 0.9 was that we didn't have a prototype).

The ability to have one document reference multiple versions of a gadget (for % based rollouts, A/B testing, different containers) seems to be extremely useful and something we can use to make our developers lives better. It's unclear to me when we would actually use the @moduleVersion inlined in the gadget.

[Jon]

Mark,

I read the spec a bit differently:

It says that gadget developers "SHOULD" use versions - OK so its
optional.

If they do it "MUST" conform to rules. This places a burden on the
gadget developer, should they choose to use versioning, but what is
that burden?

You said:
> For example, if I've got a gadget, version 1.0.0, that
> inlines all the javascript, and I then choose to externalize it in a
> separate file, I should not be required to change the version number.

This is a gray area, one I was asking about.
So I could agree that since there is really no "end user visible"
change in the gadget, the version number would not have to change.
However "container visible" changes did happen - thus the gray area.
Can container tooling expect any specification mandated behavior?

But:

> Ditto for internationalization. However, if I add APIs, but don't
> change/remove existing ones, I'd expect an increment in the version.
> (Expect, but not require.)

Since one "MUST" obey the rules of versioning, and something "end user
visible" changed, wouldn't they HAVE to bump the version number.
If even this is optional, then the version becomes somewhat
meaningless to the whole process.