Modules for CS10 & CS10.5

I have a module that was compiled with CS10.0 Builder and runs mostly fine with CS10.5. The one catch is performance: The module contains some heavy operations and runs many times slower on CS10.5. However, once I recompile the module for CS10.5 it run more or less at the same order as it does on CS10.0.

I'm now finding modules on the Knowledge Center (e.g., Content Server UI Widgets) that are compatible with CS10.0 and CS10.5. Are these modules somehow optimized for both CS10.0 and CS10.5? Or is the performance hit for maintaining backwards compatibility not a concern for these types of modules?

Thanks, Chris

Find more posts tagged with

Comments

Kyle_Swidrovich

Hey Chris,

I had a chat with R&D.

Scripts need to be recompiled on first call because the script format has changed slightly between versions (64-bit integers). This could take some time.
This doesn't have anything to do with the new compiler, since the code that's actually run is all generated by the old compiler.

UI Widgets has a base bare bones bit of Oscript that mostly handles the install/uninstall of the module. Very little is done in Oscript. The practice of one module version spanning multiple CS releases is not recommended and with the upcoming new release of UI Widgets there will be a 10.0.1 version and a 10.5 version.

Regards,
Kyle

Chris Meyer

Hi Kyle,

Thanks for your reply. I confess, I didn't understand the first half of your response with regards to scripts being recompiled but not actually being recompiled because it's generated by the old compiler. Can you explain this again? Perhaps I'm not clear if it's the IDE or CS service which is doing the recompiling (on the fly?).

The second half is clear, and is sort of what I expected. But how does OpenText maintain two code branches on any module? Are bug fixes and new features implemented independently in each? I'll admit this is the main reason I haven't done much with CS IDE 10.5 yet; I require compatibility with CS10.0, and would find it highly error prone to maintain two branches. Fortunately, things are forward compatible from CS10.0 to CS10.5 as long as I recompile the ospace with the new IDE.

Lastly, this might be a feature idea for OpenText. Would it be possible to package a module with two ospaces: one for CS10.0 and another for CS10.5? At install or service start the the appropriate ospace is automatically selected for the instance. Apple is doing this kind of thing with iOS where a single app contains both a 32bit and 64bit binary, and the appropriate is chosen for the device hardware. It's quite convenient and (mostly) transparent to the developer and user.

Thanks, Chris

Kyle_Swidrovich

Hi Chris,

Essentially, 10.5 can't make use of pre-compiled 10.0 scripts within the Ospaces so a recompilation is necessary. That recompilation, however, is done using the older compiler since the code in the scripts is in the older 10.0 format.

I've reached out to R&D to help clarify the first point for you. Hopefully, you'll see a comment arrive in the forum soon.

Regarding the two code branches, yes, they are maintained independently.

This is essential for various reasons. For example, new features are intended for the latest release only and supported environments between old and new versions are different (e.g., Windows 2003 backplane vs. Windows 2012, IE 8 support, etc.)

The scope of QA becomes quite large if you try to have one module be supported for versions spanning eras of web, OS and DB technology. You also end up with a lot of conditionals in your code.

Packaging multiple versions into one installer is a great idea, but only if their release cycles align across the multiple versions.

That could be something for us to consider for certain modules, like UI Widgets.

Cheers,

Kyle

Hans Stoop

Hi Kyle,

The option to have 2 2 OSpaces, one for each CS version, would especially be usefull for partner and professional services, because we deliver modules that need to cross CS versions.

Hans

From: eLink Entry: Content Server Development Forum [mailto:development@elinkkc.opentext.com]
Sent: Freitag, 1. August 2014 00:32
To: eLink Recipient
Subject: RE Modules for CS10 & CS10.5

RE Modules for CS10 & CS10.5

Posted bykswidrov@opentext.com (Swidrovich, Kyle) On 07/31/2014 06:32 PM

Hi Chris,

I've reached out to R&D to help clarify the first point for you. Hopefully, you'll see a comment arrive in the forum soon.

Regarding the two code branches, yes, they are maintained independently.

The scope of QA becomes quite large if you try to have one module be supported for versions spanning eras of web, OS and DB technology. You also end up with a lot of conditionals in your code.

Packaging multiple versions into one installer is a great idea, but only if their release cycles align across the multiple versions.

That could be something for us to consider for certain modules, like UI Widgets.

Cheers,

Kyle

[To post a comment, use the normal reply function]
Topic:	Modules for CS10 & CS10.5
Forum:	Content Server Development Forum
Content Server:	Knowledge Center

Chris Meyer

Hi Kyle,

Thanks for the clarification. So if Content Server 10.5 is recompiling any CS10.0 ospace on start, then is the resulting binary optimized for running on 10.5? If not, then is it just creating something compatible but not optimized? I ask because of my original post: My CS10.0 ospace works in CS10.5, but is slower until I rebuild with the 10.5 IDE.

I suppose the advantages of maintaining one or two branches of code for a module is subjective with regards to effort. But I suppose it's less of an issue if the CS10.0 version has fallen into maintenance mode. I just can't imagine that partners are doing this while most customer installations are still on CS10.0 (which is an assumption on my part).

I'd be curious to know what other developers are doing to manage a CS10.0 and CS10.5 version of their modules. As I wrote before, I still do all my work with Builder and rebuild in CS10.5 to create a compatible version. It's the only way I see how to actively develop for both environments without having to maintain separate branches of code.

Thanks! Chris

Chris Meyer

Hi Hans,

I've taken a simple approach by having two ospace directories in my module:

ospace/ospace_105/

I then add installation instructions to rename the directories according to their environment. It would be fantastic if this could be automated.

[QUOTE]The option to have 2 2 OSpaces, one for each CS version, would especially be usefull for partner and professional services, because we deliver modules that need to cross CS versions.[/QUOTE]