FW: Forward compatibility for plug-ins?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

FW: Forward compatibility for plug-ins?

Kip Streithorst
Administrator

I haven’t heard any responses on this issue.  Does anyone have any feedback on this?  If I don’t hear anything in another week I’m going to assume that no one needs forward compatibility and that if you ever try to exercise it, Opticks.exe and OpticksBatch.exe are allowed to crash horribly with no useful error message.

 

Thanks,

Kip

 


From: Streithorst, Kip [mailto:[hidden email]]
Sent: Monday, May 12, 2008 10:36 AM
To: [hidden email]
Subject: Forward compatibility for plug-ins?

 

All,

 

There is some code being worked on that depending on it’s implementation will break forward compatibility for plug-ins.  Before we integrate this branch I wanted to solicit some feedback related to this.  First here are my definitions of backward compatibility and forward compatibility:

 

Backward Compatibility – A plug-in can be compiled and built for version 4.1.X of Opticks, but will continue to work with version 4.1.X+1 and version 4.1.X+2 of Opticks.

 

Forward Compatibility – A plug-in can be compiled and built for version 4.1.X of Opticks, but will continue to work with version 4.1.X-1 and version 4.1.X-2 of Opticks.

 

Please note that for binary compatible versions of Opticks, ie. the third digit of the version number changes we have always guaranteed backward compatibility and will continue to do so.

 

The question on forward compatibility is mainly whether changes to the Opticks SDK should always be done in a way that allows forward compatibility until a plug-in developer decides to break forward compatibility or should changes to the Opticks SDK never be forward compatible (and by never I mean a plug-in that tries to execute forward compatibility would crash Opticks when loaded).

 

Please let me know your opinions in the next week because this does affect the timeline for getting this other bit of code in.

 

Thanks,

Kip


This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.
Reply | Threaded
Open this post in threaded view
|

RE: FW: Forward compatibility for plug-ins?

John Prikkel

Kip, I don’t believe we need forward compatibility.

 

However, crashing is a different issue. Can’t you put a simple check into the interface for the plug-ins and not load ones that aren’t at the same compatibility level. This should be rather simple. Add one more external interface to the plug-in module interface. For example, like get_name() add “float get_interface_version()”. Then compare the version returned. If the “get_interface_version” external interface doesn’t exist, assume it is an older version and don’t load it.

 

Opticks  Plug-In Module  Load  Description

1.0      1.0             Yes   Load the plug-in modules, same interface version

1.1      1.0             Yes   Minor interface change, non-breaking, added methods to an interface or new interface

1.0      2.0             No    Don’t load plug-in module, it is a future interface version

1.0      1.1             No    Minor interface change, possible missing methods or interfaces

2.0      1.0             No    Don’t load previous interface version

 

If you need help adding this capability, I may be able to support it. These could be part of the Plug-In library and the complexity can easily be hidden from developers.

 

Thanks,

John

 


From: Streithorst, Kip [mailto:[hidden email]]
Sent: Wednesday, May 28, 2008 2:54 PM
To: [hidden email]
Subject: FW: Forward compatibility for plug-ins?

 

I haven’t heard any responses on this issue.  Does anyone have any feedback on this?  If I don’t hear anything in another week I’m going to assume that no one needs forward compatibility and that if you ever try to exercise it, Opticks.exe and OpticksBatch.exe are allowed to crash horribly with no useful error message.

 

Thanks,

Kip

 


From: Streithorst, Kip [mailto:[hidden email]]
Sent: Monday, May 12, 2008 10:36 AM
To: [hidden email]
Subject: Forward compatibility for plug-ins?

 

All,

 

There is some code being worked on that depending on it’s implementation will break forward compatibility for plug-ins.  Before we integrate this branch I wanted to solicit some feedback related to this.  First here are my definitions of backward compatibility and forward compatibility:

 

Backward Compatibility – A plug-in can be compiled and built for version 4.1.X of Opticks, but will continue to work with version 4.1.X+1 and version 4.1.X+2 of Opticks.

 

Forward Compatibility – A plug-in can be compiled and built for version 4.1.X of Opticks, but will continue to work with version 4.1.X-1 and version 4.1.X-2 of Opticks.

 

Please note that for binary compatible versions of Opticks, ie. the third digit of the version number changes we have always guaranteed backward compatibility and will continue to do so.

 

The question on forward compatibility is mainly whether changes to the Opticks SDK should always be done in a way that allows forward compatibility until a plug-in developer decides to break forward compatibility or should changes to the Opticks SDK never be forward compatible (and by never I mean a plug-in that tries to execute forward compatibility would crash Opticks when loaded).

 

Please let me know your opinions in the next week because this does affect the timeline for getting this other bit of code in.

 

Thanks,

Kip


This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.
Reply | Threaded
Open this post in threaded view
|

RE: RE: Forward compatibility for plug-ins?

John Prikkel
In reply to this post by Kip Streithorst

Kip, I guess you could even use the existing “opticks_get_module_interface_version”. It isn’t a float, but you could increment the interface version by 100 for every major release and use single digits for minor releases. Or change the interface to support floats.

 


From: Prikkel, John
Sent: Thursday, May 29, 2008 9:34 AM
To: '[hidden email]'
Subject: RE: FW: Forward compatibility for plug-ins?

 

Kip, I don’t believe we need forward compatibility.

 

However, crashing is a different issue. Can’t you put a simple check into the interface for the plug-ins and not load ones that aren’t at the same compatibility level. This should be rather simple. Add one more external interface to the plug-in module interface. For example, like get_name() add “float get_interface_version()”. Then compare the version returned. If the “get_interface_version” external interface doesn’t exist, assume it is an older version and don’t load it.

 

Opticks  Plug-In Module  Load  Description

1.0      1.0             Yes   Load the plug-in modules, same interface version

1.1      1.0             Yes   Minor interface change, non-breaking, added methods to an interface or new interface

1.0      2.0             No    Don’t load plug-in module, it is a future interface version

1.0      1.1             No    Minor interface change, possible missing methods or interfaces

2.0      1.0             No    Don’t load previous interface version

 

If you need help adding this capability, I may be able to support it. These could be part of the Plug-In library and the complexity can easily be hidden from developers.

 

Thanks,

John

 


From: Streithorst, Kip [mailto:[hidden email]]
Sent: Wednesday, May 28, 2008 2:54 PM
To: [hidden email]
Subject: FW: Forward compatibility for plug-ins?

 

I haven’t heard any responses on this issue.  Does anyone have any feedback on this?  If I don’t hear anything in another week I’m going to assume that no one needs forward compatibility and that if you ever try to exercise it, Opticks.exe and OpticksBatch.exe are allowed to crash horribly with no useful error message.

 

Thanks,

Kip

 


From: Streithorst, Kip [mailto:[hidden email]]
Sent: Monday, May 12, 2008 10:36 AM
To: [hidden email]
Subject: Forward compatibility for plug-ins?

 

All,

 

There is some code being worked on that depending on it’s implementation will break forward compatibility for plug-ins.  Before we integrate this branch I wanted to solicit some feedback related to this.  First here are my definitions of backward compatibility and forward compatibility:

 

Backward Compatibility – A plug-in can be compiled and built for version 4.1.X of Opticks, but will continue to work with version 4.1.X+1 and version 4.1.X+2 of Opticks.

 

Forward Compatibility – A plug-in can be compiled and built for version 4.1.X of Opticks, but will continue to work with version 4.1.X-1 and version 4.1.X-2 of Opticks.

 

Please note that for binary compatible versions of Opticks, ie. the third digit of the version number changes we have always guaranteed backward compatibility and will continue to do so.

 

The question on forward compatibility is mainly whether changes to the Opticks SDK should always be done in a way that allows forward compatibility until a plug-in developer decides to break forward compatibility or should changes to the Opticks SDK never be forward compatible (and by never I mean a plug-in that tries to execute forward compatibility would crash Opticks when loaded).

 

Please let me know your opinions in the next week because this does affect the timeline for getting this other bit of code in.

 

Thanks,

Kip


This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.
Reply | Threaded
Open this post in threaded view
|

RE: RE: RE: Forward compatibility for plug-ins?

Kip Streithorst
Administrator

John,

 

I’m good with this approach in principle.  The question is how complex do we make the rules governing when to update the module interface version supported by Opticks versus the one built into PlugInLib.  The simplest approach would be to update the module interface version at every release including release candidates.  A more complex and error prone approach would be to monitor the changes being made and only when they are forward compatible breaking do we update the module interface version.  There’s also the question of do we worry about the case where a plug-in developer builds against a PlugInLib.lib in one version of the SDK but uses interface files from a different version of the SDK?  I say we have to ignore this problem, but just thought I should ask.  I mainly stressed crash in my last post to drive home the point that we either support forward compatibility or we don’t and if we don’t we can try to be nice as you’re suggesting, but we don’t make guarantee’s.

 

Thanks,

Kip

 


From: Prikkel, John [mailto:[hidden email]]
Sent: Thursday, May 29, 2008 11:21 AM
To: [hidden email]
Subject: RE: RE: Forward compatibility for plug-ins?

 

Kip, I guess you could even use the existing “opticks_get_module_interface_version”. It isn’t a float, but you could increment the interface version by 100 for every major release and use single digits for minor releases. Or change the interface to support floats.

 


From: Prikkel, John
Sent: Thursday, May 29, 2008 9:34 AM
To: '[hidden email]'
Subject: RE: FW: Forward compatibility for plug-ins?

 

Kip, I don’t believe we need forward compatibility.

 

However, crashing is a different issue. Can’t you put a simple check into the interface for the plug-ins and not load ones that aren’t at the same compatibility level. This should be rather simple. Add one more external interface to the plug-in module interface. For example, like get_name() add “float get_interface_version()”. Then compare the version returned. If the “get_interface_version” external interface doesn’t exist, assume it is an older version and don’t load it.

 

Opticks  Plug-In Module  Load  Description

1.0      1.0             Yes   Load the plug-in modules, same interface version

1.1      1.0             Yes   Minor interface change, non-breaking, added methods to an interface or new interface

1.0      2.0             No    Don’t load plug-in module, it is a future interface version

1.0      1.1             No    Minor interface change, possible missing methods or interfaces

2.0      1.0             No    Don’t load previous interface version

 

If you need help adding this capability, I may be able to support it. These could be part of the Plug-In library and the complexity can easily be hidden from developers.

 

Thanks,

John

 


From: Streithorst, Kip [mailto:[hidden email]]
Sent: Wednesday, May 28, 2008 2:54 PM
To: [hidden email]
Subject: FW: Forward compatibility for plug-ins?

 

I haven’t heard any responses on this issue.  Does anyone have any feedback on this?  If I don’t hear anything in another week I’m going to assume that no one needs forward compatibility and that if you ever try to exercise it, Opticks.exe and OpticksBatch.exe are allowed to crash horribly with no useful error message.

 

Thanks,

Kip

 


From: Streithorst, Kip [mailto:[hidden email]]
Sent: Monday, May 12, 2008 10:36 AM
To: [hidden email]
Subject: Forward compatibility for plug-ins?

 

All,

 

There is some code being worked on that depending on it’s implementation will break forward compatibility for plug-ins.  Before we integrate this branch I wanted to solicit some feedback related to this.  First here are my definitions of backward compatibility and forward compatibility:

 

Backward Compatibility – A plug-in can be compiled and built for version 4.1.X of Opticks, but will continue to work with version 4.1.X+1 and version 4.1.X+2 of Opticks.

 

Forward Compatibility – A plug-in can be compiled and built for version 4.1.X of Opticks, but will continue to work with version 4.1.X-1 and version 4.1.X-2 of Opticks.

 

Please note that for binary compatible versions of Opticks, ie. the third digit of the version number changes we have always guaranteed backward compatibility and will continue to do so.

 

The question on forward compatibility is mainly whether changes to the Opticks SDK should always be done in a way that allows forward compatibility until a plug-in developer decides to break forward compatibility or should changes to the Opticks SDK never be forward compatible (and by never I mean a plug-in that tries to execute forward compatibility would crash Opticks when loaded).

 

Please let me know your opinions in the next week because this does affect the timeline for getting this other bit of code in.

 

Thanks,

Kip


This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.
Reply | Threaded
Open this post in threaded view
|

RE: RE: RE: RE: Forward compatibility for plug-ins?

John Prikkel

Kip, either way of updating the interface version number is fine with me. I agree we don’t need to worry about mixing header files and a older plug-in lib.

 


From: Streithorst, Kip [mailto:[hidden email]]
Sent: Friday, May 30, 2008 4:47 PM
To: [hidden email]
Subject: RE: RE: RE: Forward compatibility for plug-ins?

 

John,

 

I’m good with this approach in principle.  The question is how complex do we make the rules governing when to update the module interface version supported by Opticks versus the one built into PlugInLib.  The simplest approach would be to update the module interface version at every release including release candidates.  A more complex and error prone approach would be to monitor the changes being made and only when they are forward compatible breaking do we update the module interface version.  There’s also the question of do we worry about the case where a plug-in developer builds against a PlugInLib.lib in one version of the SDK but uses interface files from a different version of the SDK?  I say we have to ignore this problem, but just thought I should ask.  I mainly stressed crash in my last post to drive home the point that we either support forward compatibility or we don’t and if we don’t we can try to be nice as you’re suggesting, but we don’t make guarantee’s.

 

Thanks,

Kip

 


From: Prikkel, John [mailto:[hidden email]]
Sent: Thursday, May 29, 2008 11:21 AM
To: [hidden email]
Subject: RE: RE: Forward compatibility for plug-ins?

 

Kip, I guess you could even use the existing “opticks_get_module_interface_version”. It isn’t a float, but you could increment the interface version by 100 for every major release and use single digits for minor releases. Or change the interface to support floats.

 


From: Prikkel, John
Sent: Thursday, May 29, 2008 9:34 AM
To: '[hidden email]'
Subject: RE: FW: Forward compatibility for plug-ins?

 

Kip, I don’t believe we need forward compatibility.

 

However, crashing is a different issue. Can’t you put a simple check into the interface for the plug-ins and not load ones that aren’t at the same compatibility level. This should be rather simple. Add one more external interface to the plug-in module interface. For example, like get_name() add “float get_interface_version()”. Then compare the version returned. If the “get_interface_version” external interface doesn’t exist, assume it is an older version and don’t load it.

 

Opticks  Plug-In Module  Load  Description

1.0      1.0             Yes   Load the plug-in modules, same interface version

1.1      1.0             Yes   Minor interface change, non-breaking, added methods to an interface or new interface

1.0      2.0             No    Don’t load plug-in module, it is a future interface version

1.0      1.1             No    Minor interface change, possible missing methods or interfaces

2.0      1.0             No    Don’t load previous interface version

 

If you need help adding this capability, I may be able to support it. These could be part of the Plug-In library and the complexity can easily be hidden from developers.

 

Thanks,

John

 


From: Streithorst, Kip [mailto:[hidden email]]
Sent: Wednesday, May 28, 2008 2:54 PM
To: [hidden email]
Subject: FW: Forward compatibility for plug-ins?

 

I haven’t heard any responses on this issue.  Does anyone have any feedback on this?  If I don’t hear anything in another week I’m going to assume that no one needs forward compatibility and that if you ever try to exercise it, Opticks.exe and OpticksBatch.exe are allowed to crash horribly with no useful error message.

 

Thanks,

Kip

 


From: Streithorst, Kip [mailto:[hidden email]]
Sent: Monday, May 12, 2008 10:36 AM
To: [hidden email]
Subject: Forward compatibility for plug-ins?

 

All,

 

There is some code being worked on that depending on it’s implementation will break forward compatibility for plug-ins.  Before we integrate this branch I wanted to solicit some feedback related to this.  First here are my definitions of backward compatibility and forward compatibility:

 

Backward Compatibility – A plug-in can be compiled and built for version 4.1.X of Opticks, but will continue to work with version 4.1.X+1 and version 4.1.X+2 of Opticks.

 

Forward Compatibility – A plug-in can be compiled and built for version 4.1.X of Opticks, but will continue to work with version 4.1.X-1 and version 4.1.X-2 of Opticks.

 

Please note that for binary compatible versions of Opticks, ie. the third digit of the version number changes we have always guaranteed backward compatibility and will continue to do so.

 

The question on forward compatibility is mainly whether changes to the Opticks SDK should always be done in a way that allows forward compatibility until a plug-in developer decides to break forward compatibility or should changes to the Opticks SDK never be forward compatible (and by never I mean a plug-in that tries to execute forward compatibility would crash Opticks when loaded).

 

Please let me know your opinions in the next week because this does affect the timeline for getting this other bit of code in.

 

Thanks,

Kip


This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.