Closed robmoffat closed 6 days ago
so does this mean that we are relaxing or removing the requirement to have window.fdc3
always set?
@Roaders that is the plan, yes. By making setting it the default we can easily support existing.apps (that add only a getAgent
call), and allow others to turn it off if they need to (they could also just ignore it).
Great, that sounds good. I agree that defaulting to true makes the mast sense.
I'll restart my opinion as confirmation. I think we should:
window.fdc3
by default (and handle the fact that it might already be set or frozen by a container as they will continue to do this)fdc3Ready
event when its set (unless it was already fired by the container!)setWindowGlobal
flag as an argument to getAgent
, which is true by default - set to false to disable the behaviour.window.fdc3
when its ready to use, to recommendation that it is set as soon as possible after a window is opened, and to queue any requests made to it until it is ready to use.
Closed as decided and implemented
We've been discussing whether the getAgent options should have a parameter for backwards compatibility which will set
window.fdc3
and fire thefdc3Ready
event. For pre-existing applications upgrading to FDC3 For the web and making heavy use of those features, this will save a lot of effort when upgrading togetAgent
.Question for discussion:
Should this parameter be set to true or false by default? i.e.
window.fdc3
and firefdc3Ready
getAgent
wherever you need an instance of theDesktopAgent
.Some comments from email discussion:
@robmoffat said:
@kriswest said:
Derek Novavi then suggested that improving backwards compatibility would make FDC3 For The Web easier to accept when it comes to voting.
Thoughts?