| 1 | Should we merge the two products into 1? | Yaw’s view - the two products should be merged for the following reasons: reduce duplication of efforts better manage people’s time and resources New developer work on GOBii-EBS instead of GOBii-standalone provide more control on standalone’s run and maintain to EBS ease of integrating other GOBii-standalone components into EBS allow for smother transition of GOBii clients into EBS in the future
Kevin’s view: does not recommend that the two products be merged to 1. It is possible but not without significant effort (possibly significant delays as well) for the following reasons: what has been designed and implemented for the past 6 months is utilizing the microintegrator connecting the GOBii backend to the service gateway - this includes various improvements and simplification to the GOBii backend. with a new middleware utilizing aspect objects, no XML configuration files, no volume dependencies (ie. NFS drives for the gobii_bundle), and some database changes, integrating the web layer is not a simple feat. This will require significant effort and code rewrite. So the decision to do so should be based on a concrete use case. If we are saying that the automated loading should be done through templates via the web services, then changes in GOBii-EBS will have to be reverted to accommodate this integration. However, if we keep the microintegrator approach of linking the backend to the SG, this requirement is already satisfied with the current architecture. web API integrations to the SG is done through a separate SG module called API manager not through the microintegrators (dataflows), as far as I know and this will have to be designed thoroughly prior to any integration. Depending on what the API will be used for, this may also require some rewrite on what we’ve already implemented.
Tom’s view: I think we are merging. My definition of this is likely different from yours and also Kevin’s. I then want to define more specifically what we mean by merging. For EBS V3.0 we will: reduce duplication of efforts better manage people’s time and resources EBS team, inclusive of former GOBii team, will work on GOBii-EBS instead of GOBii-standalone provide more control on standalone’s run and maintain (a responsibility of the EBS team) focus on backend integration (database and digest layers) evaluate which other components of GOBii will be considered for integration and how in subsequent EBS versions
|
