Hi! I had a closer look at Zope 2.8's Five and I'm concerned about the fact that Five ships with redundant interface definitions: - redundant code is always a problem because it's hard to keep things in sync - the fact that Five is maintained in a different repository and should work with different Zope versions makes it almost impossible to change Zope interfaces in a consistent way So my questions are: 1.) Why are interfaces that are available as Zope 2 interfaces duplicated in Five/interfaces.py instead of bridged? 2.) Could we move the interfaces that are currently not available as Zope 2 interfaces to the corresponding packages in Zope 2.8, using Five/interfaces.py just as an fallback for Zope 2.7 and old Five products? If people agree that this is problem, I'd volunteer to help resolving it. Cheers, Yuppie
yuppie wrote:
I had a closer look at Zope 2.8's Five and I'm concerned about the fact that Five ships with redundant interface definitions:
- redundant code is always a problem because it's hard to keep things in sync
- the fact that Five is maintained in a different repository and should work with different Zope versions makes it almost impossible to change Zope interfaces in a consistent way
So my questions are:
1.) Why are interfaces that are available as Zope 2 interfaces duplicated in Five/interfaces.py instead of bridged?
Partially I suspect this reason is historical -- the Zope 2 interfaces were created by Philipp von Weitershausen before Tres implemented the bridging functionality.
2.) Could we move the interfaces that are currently not available as Zope 2 interfaces to the corresponding packages in Zope 2.8, using Five/interfaces.py just as an fallback for Zope 2.7 and old Five products?
If people agree that this is problem, I'd volunteer to help resolving it.
It sounds like a reasonable idea, but it does introduce complications. This does mean we need a separate version of Five for merging into Zope 2.8. Another potential problem is that some Five-based code is also likely to stop working as the interface will change location (I'm not sure what bridge does in this respect; does it create a new location for the bridged interface?). If the interfaces change location due to bridging, this also means Five + 2.7 code would be incompatible with Zope 2.8 code that makes use of Five. I'm a bit worried about doing it now as it will take time and testing effort, then again, if we are to do it, it would be better to start moving things around before we release Zope 2.8.. Regards, Martijn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martijn Faassen wrote:
yuppie wrote:
I had a closer look at Zope 2.8's Five and I'm concerned about the fact that Five ships with redundant interface definitions:
- redundant code is always a problem because it's hard to keep things in sync
- the fact that Five is maintained in a different repository and should work with different Zope versions makes it almost impossible to change Zope interfaces in a consistent way
So my questions are:
1.) Why are interfaces that are available as Zope 2 interfaces duplicated in Five/interfaces.py instead of bridged?
Partially I suspect this reason is historical -- the Zope 2 interfaces were created by Philipp von Weitershausen before Tres implemented the bridging functionality.
2.) Could we move the interfaces that are currently not available as Zope 2 interfaces to the corresponding packages in Zope 2.8, using Five/interfaces.py just as an fallback for Zope 2.7 and old Five products?
Maybe we need to spell out what the fallback would look like more clearly.
If people agree that this is problem, I'd volunteer to help resolving it.
It sounds like a reasonable idea, but it does introduce complications. This does mean we need a separate version of Five for merging into Zope 2.8. Another potential problem is that some Five-based code is also likely to stop working as the interface will change location (I'm not sure what bridge does in this respect; does it create a new location for the bridged interface?).
The bridging code fabricates a new Z3 interface and bashes it into whatever module the directive specifies, so we could keep the same dotted names as the current interfaces.
If the interfaces change location due to bridging, this also means Five + 2.7 code would be incompatible with Zope 2.8 code that makes use of Five.
I'm a bit worried about doing it now as it will take time and testing effort, then again, if we are to do it, it would be better to start moving things around before we release Zope 2.8..
+1. I have an intent (but no time so far) to make the equivalent change for CMFonFive, as well. Tres. - -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCeMO+GqWXf00rNCgRAnqFAJ0TSKfcX7AnvVE7h4CGahn8CwDMdwCdHI2g OJ4vvoGtbvrLWRS6qBwAZ6A= =IHBw -----END PGP SIGNATURE-----
Tres Seaver wrote:
I had a closer look at Zope 2.8's Five and I'm concerned about the fact that Five ships with redundant interface definitions:
- redundant code is always a problem because it's hard to keep things in sync
- the fact that Five is maintained in a different repository and should work with different Zope versions makes it almost impossible to change Zope interfaces in a consistent way
So my questions are:
1.) Why are interfaces that are available as Zope 2 interfaces duplicated in Five/interfaces.py instead of bridged?
Partially I suspect this reason is historical -- the Zope 2 interfaces were created by Philipp von Weitershausen before Tres implemented the bridging functionality.
Correct.
2.) Could we move the interfaces that are currently not available as Zope 2 interfaces to the corresponding packages in Zope 2.8, using Five/interfaces.py just as an fallback for Zope 2.7 and old Five products?
Maybe we need to spell out what the fallback would look like more clearly.
If people agree that this is problem, I'd volunteer to help resolving it.
It sounds like a reasonable idea, but it does introduce complications. This does mean we need a separate version of Five for merging into Zope 2.8. Another potential problem is that some Five-based code is also likely to stop working as the interface will change location (I'm not sure what bridge does in this respect; does it create a new location for the bridged interface?).
The bridging code fabricates a new Z3 interface and bashes it into whatever module the directive specifies, so we could keep the same dotted names as the current interfaces.
Right. Here's what we could do: 1. Copy Five's interface definitions over to Zope 2.8 (mostly to OFS.interfaces, I guess) where they are added as Zope 2 interfaces 2. Keep Five's (redudant) interface definitions. They can stay at their status quo (status Zope 2.7, that is). 3. Add <five:bridge /> calls for every interface so that Five's interfaces are automatically kept up-to-date with the Zope 2.8 ones. The bridges would override the ones defined in the module, potentially updating with newer definitions. The only thing that we need to take care of is fallback for Zope 2.7 where the Zope 2 interfaces don't exist yet. If you want to do this, yuppie, feel free to do it. I would even be ok for this to be done for the 1.0 branch, provided you also add it on the trunk.
If the interfaces change location due to bridging, this also means Five + 2.7 code would be incompatible with Zope 2.8 code that makes use of Five.
I'm a bit worried about doing it now as it will take time and testing effort, then again, if we are to do it, it would be better to start moving things around before we release Zope 2.8..
+1. I have an intent (but no time so far) to make the equivalent change for CMFonFive, as well.
Cool. Philipp
Hi! Philipp von Weitershausen wrote:
Right. Here's what we could do:
1. Copy Five's interface definitions over to Zope 2.8 (mostly to OFS.interfaces, I guess) where they are added as Zope 2 interfaces
I would prefer to reserve the name 'interfaces' for Zope 3 interfaces. So far ZopeTestCase is the only package in Zope 2.8 that uses 'interfaces' for Zope 2 interfaces.
2. Keep Five's (redudant) interface definitions. They can stay at their status quo (status Zope 2.7, that is).
3. Add <five:bridge /> calls for every interface so that Five's interfaces are automatically kept up-to-date with the Zope 2.8 ones. The bridges would override the ones defined in the module, potentially updating with newer definitions. The only thing that we need to take care of is fallback for Zope 2.7 where the Zope 2 interfaces don't exist yet.
Would this work: Instead of modifying Five at all, could we just add zcml files to the Zope 2.8 packages with Zope 2 interfaces and override the interfaces in Five.interfaces?
If you want to do this, yuppie, feel free to do it. I would even be ok for this to be done for the 1.0 branch, provided you also add it on the trunk.
If I need to change something in Five: Do I need additional checkin rights on codespeak, or will my kupu login work? Cheers, Yuppie
yuppie wrote:
Philipp von Weitershausen wrote:
Right. Here's what we could do:
1. Copy Five's interface definitions over to Zope 2.8 (mostly to OFS.interfaces, I guess) where they are added as Zope 2 interfaces
I would prefer to reserve the name 'interfaces' for Zope 3 interfaces. So far ZopeTestCase is the only package in Zope 2.8 that uses 'interfaces' for Zope 2 interfaces.
Ok. I don't really care that much.
2. Keep Five's (redudant) interface definitions. They can stay at their status quo (status Zope 2.7, that is).
3. Add <five:bridge /> calls for every interface so that Five's interfaces are automatically kept up-to-date with the Zope 2.8 ones. The bridges would override the ones defined in the module, potentially updating with newer definitions. The only thing that we need to take care of is fallback for Zope 2.7 where the Zope 2 interfaces don't exist yet.
Would this work: Instead of modifying Five at all, could we just add zcml files to the Zope 2.8 packages with Zope 2 interfaces and override the interfaces in Five.interfaces?
Yes. We could, for example, add another Product to Zope 2.8 (e.g. 'BridgeInterfaces') that contains a configure.zcml file that does this; that way the ZCML file gets automatically picked up by Five. I leave it to you and the others to decide whether to use this approach (add additional ZCML files to Zope 2.8) or whether to modify Five. I guess your suggestion is slightly more elegant.
If you want to do this, yuppie, feel free to do it. I would even be ok for this to be done for the 1.0 branch, provided you also add it on the trunk.
If I need to change something in Five: Do I need additional checkin rights on codespeak, or will my kupu login work?
Your kupu login will work. Philipp
Philipp von Weitershausen wrote: [snip]
Right. Here's what we could do:
1. Copy Five's interface definitions over to Zope 2.8 (mostly to OFS.interfaces, I guess) where they are added as Zope 2 interfaces
2. Keep Five's (redudant) interface definitions. They can stay at their status quo (status Zope 2.7, that is).
3. Add <five:bridge /> calls for every interface so that Five's interfaces are automatically kept up-to-date with the Zope 2.8 ones. The bridges would override the ones defined in the module, potentially updating with newer definitions. The only thing that we need to take care of is fallback for Zope 2.7 where the Zope 2 interfaces don't exist yet.
So you would have the Zope 2.8 interfaces exist in the Five.interfaces module? If not, we do have a compatibility problem. Regards, Martijn
Martijn Faassen wrote:
Philipp von Weitershausen wrote: [snip]
Right. Here's what we could do:
1. Copy Five's interface definitions over to Zope 2.8 (mostly to OFS.interfaces, I guess) where they are added as Zope 2 interfaces
2. Keep Five's (redudant) interface definitions. They can stay at their status quo (status Zope 2.7, that is).
3. Add <five:bridge /> calls for every interface so that Five's interfaces are automatically kept up-to-date with the Zope 2.8 ones. The bridges would override the ones defined in the module, potentially updating with newer definitions. The only thing that we need to take care of is fallback for Zope 2.7 where the Zope 2 interfaces don't exist yet.
So you would have the Zope 2.8 interfaces exist in the Five.interfaces module?
Well, no. Five.interfaces would stay as it is; it seems to be pretty accurate for Zope 2.7 (especially with yuppie's fixes, which should be merged to the Five-1.0 branch, btw). Some interfaces were added to Zope 2.8 and it would make sense to manage all of them in the Zope tree for the future, not the Five tree. However, when run within Zope 2.8, we want Five.interfaces to be most accurate, so we would install bridges in Zope 2.8 that bridge the Zope 2.8 interfaces to Five.interfaces. At least that was yuppie's latest idea andI think it's elegant.
If not, we do have a compatibility problem.
I don't think we will. Philipp P.S.: In case you're wondering why I haven't done any work on the Five wrt testing/i18n: My hard drive had a head crash, the laptop is in for repair :( ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Philipp von Weitershausen wrote:
Martijn Faassen wrote:
So you would have the Zope 2.8 interfaces exist in the Five.interfaces module?
Well, no. Five.interfaces would stay as it is; it seems to be pretty accurate for Zope 2.7 (especially with yuppie's fixes, which should be merged to the Five-1.0 branch, btw).
Some interfaces were added to Zope 2.8 and it would make sense to manage all of them in the Zope tree for the future, not the Five tree. However, when run within Zope 2.8, we want Five.interfaces to be most accurate, so we would install bridges in Zope 2.8 that bridge the Zope 2.8 interfaces to Five.interfaces. At least that was yuppie's latest idea andI think it's elegant.
Well. This was not my *latest* idea. I tried to implement it that way, but that approach has some limitations: - While we want to get rid of z2 interfaces in the long run, this requires to add z2 interfaces to Zope. - You did use schema fields for the z3 interfaces. Backporting these interfaces to z2 interfaces is a regression. - It's not as easy to import bridged interfaces as to import static interfaces. We have to make sure they are already created. Please see me new proposal, posted today. Cheers, Yuppie
participants (4)
-
Martijn Faassen -
Philipp von Weitershausen -
Tres Seaver -
yuppie