IDE already reads plugin version directly from Chrome config files. But plugin needs to know which version of NB it is talking to - perhaps INIT message with status accepted should send also IDE version to plugin?

One other thing that Honza and I discussed is that the IDE should be prepared for the potential situation that we need to publish two Chrome plugins for different versions of the IDE, and the user installs both of them. In that case, both of these plugins will initiate the handshake, and the IDE needs to react accordingly. How exactly would this be done?

Honza/Denis wrote the plugin and its initial handshake but looking at the code the scenario with two NB plugins in the browser would work like this:

#1) IDE asks "Chrome with NB integration" to open foo.html
#2) both NB plugins notice a new tab being opened in the Chrome and both send to WebSocket server running in IDE a messsage of type INIT and that message in addition to URL will contains also version of NB browser plugin, that is something like {type:INIT, url:"foo.html", plugin-version:"7.3"} and {type:INIT, url:"foo.html", plugin-version:"7.4"} (just illustration)
#3) IDE accepts one INIT message according to its version and rejects the other one

So to summarize what should be implemented in this issue:
* INIT message coming from browser to IDE contains browser plugin version; and
* INIT message coming from IDE to browser contains IDE version

Would you agree Honza or do you think we need something else?

> Would you agree Honza or do you think we need something else?

I agree. In fact, I had exactly this in my mind when I was considering several NB extensions installed at once. If we implement this then the extension for 7.3 (resp. 7.4) will continue to talk to NB 7.3 (resp. 7.4) only.

This works well if we end up with a separate extension for each release. What about the scenario that you (=David) suggested, i.e., having at most one extension installed? If we implement what you have described then NB 7.3 will reject messages with version different from 7.3. That means that NB 7.3 will reject the messages from the extension once it is upgraded to 7.4 (in the one-extension scenario). How is this going to work?

One solution would be for the upgraded extension to send two INIT messages. One with version 7.3 and one with version 7.4.

I was just writing something similar but got a "mid-air colision" - your comment got there first Honzo :-) Here is my response to David:

> Would you agree Honza or do you think we need something else?

I agree, but I think we need to exactly specify what "plugin-version" is. I assume that we don't know in advance whether the 7.4 plugin will be backward compatible with 7.3 - it may or it may not, right? 
If it is compatible, then there will be just one plugin for 7.3 + 7.4, and we need to avoid the situation that after receiving INIT message from browser plugin 7.4, the IDE will refuse it and think that there is another message coming from browser plugin 7.3 - which will not come, as there is just one plugin. So I would suggest "plugin-version" to mean "the earliest version of the IDE with which this plugin is compatible" - would you agree?

> So I would suggest "plugin-version" to mean "the earliest version of
> the IDE with which this plugin is compatible" - would you agree?

This probably is not the best idea. The extension distributed with NB 7.3 will send "7.3" there (there is no other possible value to send by this extension). But this would mean that this extension is forward compatible with NB 7.4, NB 7.5 by your definition. This is not correct.

Maybe we should put all the versions of the IDE that the extension supports into this "version" field. The extension for NB 7.3 will have just "7.3" there. If our extension for NB 7.4 will replace the old one then it will send "7.3,7.4". If we end up with two extensions then the new one will send just "7.4".

(In reply to comment #6)
> Maybe we should put all the versions of the IDE that the extension supports
> into this "version" field. The extension for NB 7.3 will have just "7.3" there.
> If our extension for NB 7.4 will replace the old one then it will send
> "7.3,7.4". If we end up with two extensions then the new one will send just
> "7.4".

This should work well I think.

Another alternative would be to disconnect browser plugin versioning from IDE versioning and use major version to denote backward compatibility. Or we could use versioning like "1.7.3.xxx" and in NB 7.4 release either "1.7.4.xxx" or "2.7.4.xxx"

Should not you guys be sleeping! :-)

> This probably is not the best idea.

What I had in mind is that the IDE would of course know what value to require - if NetBeans 7.4 is backward compatible with 7.3, then it knows it expects "7.3", if it's not compatible then it knows it expects "7.4".

> use major version to denote backward compatibility

I think that's probably the best solution, I like it.

Implemented - the INIT message (sent by extension to IDE) contains "version" attribute. The value of this attribute is "1.7.3" for the extension distributed with NetBeans 7.3. On the other hand, NetBeans 7.3 accepts INIT messages whose version starts with "1.".

Modified files: http://hg.netbeans.org/web-main/rev/534b1e7d5e65

Looks good Honza. Thanks.

Two comments:

* just for future usage I would also send IDE version back to plugin in INIT response from IDE

* I thought that we would have just one versioning scheme, that is NetBeans.VERSION would be the same as version in chrome's plugin manifest, that is for example "1.7.3.65" (true Oracle product versioning :-) instead of "0.6.5"

> just for future usage I would also send IDE version back to plugin in INIT
> response from IDE

OK, I have added the "version" attribute into this message as well. Its value is "7.3" for NB 7.3. See [1].

> I thought that we would have just one versioning scheme, that is
> NetBeans.VERSION would be the same as version in chrome's plugin manifest,
> that is for example "1.7.3.65" (true Oracle product versioning :-)
> instead of "0.6.5"

While I don't see any use-case why this would be needed it was tempting for me to concatenate "1.7.3" with the extension version just to produce insanely long version number (i.e. to construct the version number "in the Oracle way" ;-) ). Unfortunately, it turned out to be surprisingly difficult to get the version number of the extension from its JavaScript code. I have found three solutions and all of them are ugly or problematic. Hence, it seems to be better not to include the version of the extension in the "version" attribute of the INIT message.

FYI: the solutions that I have found are the following:

1. Hard-code the version not only in manifest but also in the JavaScript code.
2. Use chrome.app.getDetails().getVersion(). This method is not included
   in any official API (i.e., it is not documented) and accoding to [2]
   it is going to change most likely.
3. The extension can obtain the manifest by doing XmlHttpRequest
   to its URL:
   var xhr = new XMLHttpRequest();
   xhr.open("GET", chrome.extension.getURL("manifest.json"), false);
   xhr.send();
   var resp = JSON.parse(xhr.responseText);

[1] http://hg.netbeans.org/web-main/rev/049bd600ea7f
[2] http://code.google.com/p/chromium/issues/detail?id=111354

(In reply to comment #11)
> OK, I have added the "version" attribute into this message as well. Its value
> is "7.3" for NB 7.3. See [1].

Thanks.

> While I don't see any use-case why this would be needed it was tempting for me
> to concatenate "1.7.3" with the extension version just to produce insanely long
> version number

Neither can I see a use-case. But the moment we have two versions it looks like a design choice and people will be asking which version is for what and when to increase one and not the other one etc. Maybe we could for now keep them manually in semi-sync and later when Chrome has an API to read version improve it? By "semi-sync" I mean to keep NetBeans.VERSION as is ("1.7.3") as it will not change often but change version in manifest to something like 1.7.3.0.6.5 or just 1.7.3.65 and just keep increasing last number. This is minor thing though.