Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
|
gemstoneport [2017/06/03 13:26] christian [The Gemstone port] |
gemstoneport [2017/06/03 15:41] christian [Decision Matrix] |
||
|---|---|---|---|
| Line 33: | Line 33: | ||
| * but, since GBS is commercial, porting and maintaining should not depend on this | * but, since GBS is commercial, porting and maintaining should not depend on this | ||
| * use it for porting Values? | * use it for porting Values? | ||
| + | ===== Decision Matrix ===== | ||
| + | |||
| + | < | ||
| + | <table class=" | ||
| + | |||
| + | < | ||
| + | <th> Approach | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||
| + | <tr> | ||
| + | <td> fileOut30 | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||
| + | <tr> | ||
| + | <td> XML fileOut | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||
| + | <tr> | ||
| + | <td> Values | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||
| + | <tr> | ||
| + | <td> Topaz input | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||
| + | </ | ||
| + | < | ||
| + | </ | ||
| + | |||
| + | The chunk format used by Squeak and Pharo does not support extensions needed for Gemstone (pundles, treat namespaces, ...). It also depends on Monticello, which I don't understand. This is not further considered. | ||
| + | |||
| + | XML fileOut would be nice if there would be an XML reader for Gemstone. Then, the fileOut could be extended with special tags for renamings and replacings etc.. On Gemstone, the XML structures need to be interpreted to setup namespaces and compile the source appropriately. | ||
| + | |||
| + | The Values approach is the same as the XML fileOut except that the reader is there (once I ported the Values to Gemstone by hand). The drawback is that it is yet another format for code interchange... (although a good one, I think). | ||
| + | |||
| + | Currently, I tend to favor the last solution where all the Gemstone code for input is generated solely from VW. There is a goodie in the public store (GemKitForStore (Copyright from OOCL)) which may have a Topaz input writer... | ||
| + | |||
| ===== Processing steps ===== | ===== Processing steps ===== | ||