I am considering creating a totally new application in OpenInsight. However with the recent announcement of Revelation's jRev initiative I have the following questions.

1) How easy will it be to port OpenInsight applications to jRev. Will Revelation supply appropriate tools or will we have another AREV to OI fiasco? Are jRev and OI sufficiently close philosophically to make a good adjustment, or are they radically different as AREV and OI were?

2) What will be the main programming language in jRev - Java or BASIC+? Revelation's announcement says jRev will 'support' BASIC+. That's not he same as saying it's programming language is BASIC+. Will I then have to learn a new programming language?

Frank,

1) How easy will it be to port OpenInsight applications to jRev. Will Revelation supply appropriate tools or will we have another AREV to OI fiasco? Are jRev and OI sufficiently close philosophically to make a good adjustment, or are they radically different as AREV and OI were?

The ease of porting depends on the application. In our migration planning, we group application implementation into three categories:

• Data Whether you are using OpenInsight's own LH database or connecting to other databases via ODBC or direct Connection Objects, we will continue to provide that functionality. We have a "100% Pure Java" implementation of the LH filing system as well as a JNI (native interface) implementation that hooks up to the LH/NPP and through the LH/NPP to the LH/NT Service. (The LH implementation will be in one of the "sand box" releases delivered to Works customers in the first half of 1998.) Additionally, we are extending the active data dictionary to build a component-oriented model of working with data, independent of the database type.
• Logic Your logic in the form of BASIC+ procedures, event scripts, and dictionary symbolics will be supported. Minor changes are planned for the language to provide a more standard object-oriented syntax (replacing some of the function calls used to access properties and events in BASIC+ today).
• GUI OpenInsight form layouts will be converted to standard jRev component definitions.

The above three, if perfectly isolated, are ideal porting scenarios. We have also identified implementation areas that could have problems:

• Overlap Where the above areas overlap, porting becomes complicated. For example, where the GUI is being programmatically constructed (using, for example, Utility Create) the implementation is less portable and potentially not portable. This is related to, among other things, the specific data structures used in OpenInsight, like the SYSREPOSWINEXES structure. In cases such as this, we plan to document the manner in which similar functionality is available. (In the case of Utility Create, for example, you would instantiate and manipulate any desired control and add it to the window; just like Utility Create, this can occur at run-time.)
• OS Support for OS-specific features will not be part of the core jRev product. The need for OS-specific functionality is obviated by the extensive functionality provided by the default Java packages (collections of Java classes). Related to Windows, this is not expected to be traumatic since Microsoft has also provided the Windows API as a set of Java classes. (Not counting the JNI interface to the LH/NPP, we have not needed to access OS-dependent functionality in our jRev development.)
• GUI Mappings The BASIC+ wrapper functions including Get_Property, Set_Property, Send_Event, etc. will exist to provide mapping to the equivalent functionality provided by JavaBean components, providing easy migration of event scripts. (Today in OpenInsight, these functions are used to map the control and property names to the correct property implementor.) In some cases, the set of available properties and events will not be identical and the default mapping that we provide may work slightly differently; however, we do not expect problems in this area.
• Tools Dependence on the names and implementations of specific OpenInsight tools will break. There will not be any 16-bit Windows executables or DLL's as part of jRev, and any RunWin execution or DLL invocation of OpenInsight system DLL's will need to be replaced with the jRev equivalent. We do not expect this to be a problem since the jRev toolset is being developed in jRev and will thus be available to developers using jRev.
• Binary The BASIC+ language is dependent on a Variant data structure, the Dynamic Array. This data structure supports length-encoded binary data, integer data, and floating point data. Using a reserved range of characters (the "system delimiters") it provides a dynamic array implementation. In jRev, this data structure is expanded to support Unicode (2-byte character) data as well. Binary data will still be supported, but it is possible that Unicode support may break some existing code that makes certain assumptions about binary data. The up-side is support for all international character sets and dynamic arrays that can truly contain binary data in any element. (We don't expect existing code to break. We have planned extensively to support the transparent conversions of data just like numbers and strings are transparently handled today in BASIC+.)

In summary, we believe we can automatically port most parts of an application and we can identify the types of implementations that will not directly port (or may act differently when ported) and document what steps are required to resolve those issues.

2) What will be the main programming language in jRev - Java or BASIC+? Revelation's announcement says jRev will 'support' BASIC+. That's not he same as saying it's programming language is BASIC+. Will I then have to learn a new programming language?

jRev will support at least two scripting languages: Java and BASIC+. These languages are used to implement the properties, methods, and events of the CORBAble JavaBean components that construct a jRev application. We don't have "THE" or "THE MAIN" scripting language. Each of the two languages we provide has a purpose: Java is the standard language in the Java environment, and BASIC+ is the language that our OpenInsight customers have built applications with! The scripting languages plug into our Java compiler package and are used to produce "100% Pure Java" components and applications. We do not have a proprietary compiled binary format for code; we are using the standards provided by the Java language and JVM specifications.

To specifically answer your question, you will not have to learn a new programming language. Out of the languages we support, it is your choice which language to use (maybe even both!).

I am considering creating a totally new application in OpenInsight. However with the recent announcement of Revelation's jRev initiative I have the following questions.

I hope I have answered your questions. Without hesitation, I encourage you to use OpenInsight as your application development tool today, assured that your applications have a path to tomorrow.

Cameron Purdy

info@revelation.com

Cameron,

Thank you for that response. It has even illuminated me more than the e-mail response I got from you last week. I do have a couple of questions to add (should be easy ones!)

We have a "100% Pure Java" implementation of the LH filing system as well as a JNI (native interface) implementation that hooks up to the LH/NPP and through the LH/NPP to the LH/NT Service…. OS Support for OS-specific features will not be part of the core jRev product. The need for OS-specific functionality is obviated by the extensive functionality provided by the default Java packages (collections of Java classes). Related to Windows, this is not expected to be traumatic since Microsoft has also provided the Windows API as a set of Java classes. (Not counting the JNI interface to the LH/NPP, we have not needed to access OS-dependent functionality in our jRev development.)

Basically, what capabilities will we have for running jRev on a non-Windows OS? Will I finally be able to create an LH-based application for the Mac? The above discussion regarding LH/NPP as being a Windows dependent functionality gives me a feeling that LH won't work on the Mac. Is this where JNI comes in to play?

Thanks,

dbakke@srpcs.com

SRP Computer Solutions

Don,

Basically, what capabilities will we have for running jRev on a non-Windows OS? Will I finally be able to create an LH-based application for the Mac?

jRev is being implemented in Java. If the Mac (or some other computer or OS) provides a JVM, jRev applications, including jRev itself, should run in that environment.

The above discussion regarding LH/NPP as being a Windows dependent functionality gives me a feeling that LH won't work on the Mac. Is this where JNI comes in to play?

We have two implementations of LH in Java. One loads a platform specific library (a Win32 version of LH/NPP) and uses it, thus allowing Java to use the LH/NPP in local mode and also connect to the LH/NT Service. The second implementation is built in "100% Pure Java" and is the basis for a cross-platform LH service, similar to the LH/NLM and LH/NT Service.

Cameron Purdy

info@revelation.com

—————————–68921951612328–

When you (cameron) say that it will work on any platform that

supports JVM does that mean that you are running the

jrev aplicaction within a browser? not within the particular os.

Pedro Azpurua

Pedro Azpurua,

When you say that it will work on any platform that supports JVM does that mean that you are running the jrev aplicaction within a browser? not within the particular os.

Both are possible.

Cameron Purdy

info@revelation.com

View this thread on the forum...