17 replies to this topic

[CSuarezdelReal]

An Open Issue:

I have seen tons of excellent comments in this site for almost a couple of years. I have been fascinated by the answers that several active members have so nicely shared with us. Several authors of the notes very well deserve to be called Gurus. Others may not have all that knowledge but are an important contribution to the content of this knowledge database and give us a complete view of the ProIV world.

I love the basic philosophy of ProIV. I really admire the person that firstly conceived this design and development concept. Hundreds of languages and applications have risen since then and I still love the way to create applications with ProIV, no matter if I use Visual Basic or Oracle's JDeveloper.

But sadly I have faced and even read here, there are a lot of modern concepts that ProIV does not support. Rob Donovan has shared an example of what the people that gives life to this site can do, creating this very site and the graphical front end interface ProIV IDE.

So, my challenge to all of us is... why do not create OURSELVES, an open RAD Environment out of the basic concept of ProIV, but spiced with all those powerhouse software engineering oddies as Structured Programming, Object Oriented Programming and a Virtual Machine, among others.

I am not talking about taking ProIV and convert it to a new level, but to start from a brand new project were the idea of a next generation RAD is the core of it. ProIV is a nice prototype to be considered, but the last thing I would like to do is violating copyrights or other legal interests there could exist with ProIV.

May I suggest using Java as the procedural language behind it?. Besides its self-managed memory schema, I found it as powerful as C, but elegant and scientifically created.

The final application could be a pure Java bytecode that should be executed by any Java’s VM.

We all have seen severe limitations with ProIV. Some of us may be using ProIV because we have to. But I am sure there are a lot of us that use it because we like it.

I would like to create very quickly screens, reports or updates functions with state-of-the-art features. I may not know so much about IDE’s, the ones I have seen or used are just good creating screens and reports, powerful tools for record processing and updates, just as ProIV does, with a clear design are very rare.

We may start as an enhancement to the open, universal IDE “eclipse”. After all, that is the way Linux started and just look where it is now. Non commercial projects as PostgresSQL, MySQL, eclipse and Linux itself have demonstrated that creating extraordinary tools with this approach is possible.

Of course I just have the vision, so I invite other people to enrich this proposal with their suggestions.

Any volunteer wants to join that journey?.

csuarezdelreal@hotmail.com

[CSuarezdelReal]

Thanks for your comments!

Yes, it may sounds as YAJIDE (Yet Another Java IDE, remember yacc), and I guess that is one of the reasons it could be very little attractive for people that visit this site regularly. Certainly eclipse is a very attractive way to go.

What I see about IDE's is that they only provide the skin of the project, the user interface, screens and reports with the underlying database queries needed to show the necessary information. I love the way Pro-IV deals with updates, the grid of files where you can clearly determine what the function does. That's the main part I would like to stress in a RAD. An IDE where we can develop a medium to complex application in a fraction of the time it would take to code thousands of lines opening the database, declaring relationships and doing cascading key-mapping and all those time-consuming programming tasks we have not to deal directly when using Pro-IV. I would like to create a high quality application from scratch in a few hours. That would be the tool I am looking for.

I would like it to be a natural home for XML documents and their manipulation, maybe based on Postgres as its data container and, why not?, save the code in tables (or persistent XML documents) where ourselves, as we do with Pro-IV), can create functions to read the characteristics of them or even create easily functions that can create functions, the easy way, just as Lisp can.

To tell the truth, I was asking for collaboration here because I have been looking for such a platform for several years and I have not found any products that come close to what I look for.

I see the life adventure as a very basic rule, be the leader, follow the leader or die. We have been following a "leader" as Pro-IV. But if we are not so comfortable with the path is taking, why not taking the leadership by ourselves?.

[Dan Shannon]

Claudio

I think there's a significant number of PRO-IV developers out there who'd love to see a better IDE - or even just a good alternative to the various PRO-IV-supplied ones (native, SL, Studio, ProAide, VIP). Many of those, I'm sure, would be willing and able to grant time and effort to such a project.

But there are some limiting factors:

1. Size of the market - we're talking about thousands, not millions, of PRO-IV developers, in the whole world. That means that development would be slow. I built an IDE in PRO-IV myself in my spare time, and it's quite good, but it took 7 years to get it to a stage where I was genuinely happy with it. Now some people do use it in anger, but we're talking users counted on fingers and toes here. Rob Donovan, our esteemed host, is busy on his own IDE (written in VB I believe) that is no doubt very good - but I wonder about its commercial viability because the market is so small?

2. Openness - all PRO-IV need to do to screw your IDE is to change the bootstrap definitions and *boom* you're behind the 8-ball. With the release of v5.0 and the extensions to the GUI and the GUI property settings, they 'forgot' to give out the bootstrap file definitions for objprop.pro. All of a sudden you're in a hard place - technically it's illegal to reverse engineer the code, so you can't keep the development tool fully compatible because it's not in PRO-IV's best interest to let you do that. If it were an Open specification, it would all be different, but there's been numerous discussions on this forum around Openness, and so far not a lot of movement from the centre.

3. Building it in Java - trying to replicate all the undocumented behaviours of the kernel would be a *huge* job, so you'd have to cut off at some point and say that you only support a subset of the total amount of PRO-IV kernel behaviour. This is going to put a number of potential customers off. Also since 4-5 years ago there are 2 versions of PRO-IV in the world - the PRO-IV one and the Glovia one - Lord only knows what subtle differences there are across the two kernel sets now. And finally it's probable that performance would be worse - Java will probably perform worse than the PRO-IV kernel in these circumstances as JVM's are written to be far more general than what's required (and therefore optimisable) within PRO-IV.

4. Why reinvent it in Java anyway? If you really could set up a 4GL for Java that did all the things that PRO-IV does, would you really want to rewrite PRO-IV? Better to write a new 4GL and build a decent converter, and allow access to all the things that Java can do better as well.

Having said all that, I still would like to see a competitor IDE for PRO-IV work, and I'd like to see some group of people build a 'sausage machine' that would give a sensible migration path out of PRO-IV into Java (and associated technologies). There's a large number of companies out there who would like to be able to move ahead faster than PRO-IV is likely to be able to (they don't have a multi-billion-dollar R&D budget, after all). It may be that the combination of high-bandwidth and JSF (Java Server Faces) may begin to offer such opportunities, but that remains to be seen.

Finally, I'd love to get involved in such a thing!

Cheers

Dan Shannon

[Tony Waszkiewicz]

hi Dan,

1) You're absolutely right about the size of the market. I agree that a "community" project would take ages and a commercial project would not be viable.

4) I thought you were always against converting PRO-IV? We have looked at a company that has converted another 4GL to C# and I think it is very feasible. Based on their approach I think around two to three man-years should be enough. Unlike the IDE I think this would be commercially viable but it would probably bust PRO-IV.

regards
Tony

[Richard Bassett]

The idea of creating a new, open-source 4GL that could also offer a viable migration path from ProIV is certainly interesting!

I must admit to a degree of scepticism about a 'communal' approach – most programming languages have had only one or two designers and most (although not all) open source projects have tended to recreate some already well-understood functionality rather than attempting to invent something new.

However, it would be very interesting to see if there is any concensus just within this forum! Perhaps even an outline of what people see as the requirements - ah yes, start with the requirements, I remember now

So, here are some thoughts and questions that occurred to me:

What is it that we would want to retain from the ProIV approach and "model"?

What open-source 4GLs already exist that we could learn from and build on?

What "kinds" of application do we want a new 4GL to be able to handle?
What "parts" of these applications do we want a new 4GL to be able to handle?

What architecture and technologies do we want to underpin resulting applications?
What partitioning across client, server and intermediate tiers is desirable?
What levels of security, performance, scalability and availability are sought?
What database interfaces are necessary?

Which "modern concepts" and "state-of-the-art features" do we want to incorporate?
What "severe limitations" do we want to leave behind?

What GUI "programming model" do we want exposed to programmers?

Since very few applications today can be implemented using only one tool it does seem an attractive idea to use an open and extensible IDE such as Eclipse to 'host' development of any new language.

[Dan Shannon]

Hi Tony

I always was against converting out of PRO-IV since it would have basically been unviable for a large application - unless someone's provided a sausage machine to do 90%+ of the code without humans getting in the way. Suppose there's only 500 functions (pretty small PRO-IV app) and each one only takes a day, and a person (all up) costs 200 quid a day, then you've spent the best part of 3 person-years and a fair slab of cash to get, basically, nothing new (and that's for a small app - take a more significant one and there could be 3-4 times as much code).

But the ground shifts all the time - and there's bound to be better tools coming, and at some point it's going to be worth it to you - and I'd be converting out of PRO-IV as soon as I had a sensible commercial reason for doing so.

Just one thing - isn't C# going to bind you to Windows and the Evil Empire? Are your existing Solaris (for example) clients going to get all excited about that?

Cheers

Dan Shannon

[Tony Waszkiewicz]

Hi Dan,

The company quoted used C# and they are committed to the Wintel platform (which has been a pretty good bet over the years). I was not saying that we would convert to C# or anything else (yet). We are in regular contact with this company and looking at what they have done is useful. They wanted to produce a tool that would 100% convert their product to make the testing process much simpler, i.e. should exactly replicate their test results from the old system.


Given that many of the underlying structures between C# and Java are similar I belive it should even be possible to be able to select either C# or Java as the target language of the said sausage machine. Of course that would add to the effort required to build it and I have given it no real thought.

As far as our existing customers are concerned their concern would be that any platform can perform. I understand it is quite feasible to have a rich C# front-end together with a Java back-end or even PRO-IV like Wall Street(?).

regards
Tony

[Richard Bassett]

Hi Tony, Hi Dan,

Even if one could largely automate it, isn't the major problem in converting from ProIV to Java or C# the fact that you are converting from a "high level" 4GL/RAD to lowish-level 3GLs (certainly lower than COBOL in their support for the "commercial application domain")?

What multiple of the number of "original lines" of ProIV code do you think will be needed to express the equivalent application in C#/Java? Surely this could have a massive impact on development productivity and costs going forward?

For example (at least as I understand it) in Java you can't even write a = a + b and get decimal arithmetic because there's no operator overloading (and you have to buy a 3rd party library to get decent decimal arithmetic anyway).

Also, do you feel it's realistic (even possible?) to convert screen and report specifications so they are maintainable in a Java or Windows IDE (ie. via a "painter" or "layout editor") – or would all the converted functionality have to end up as procedural code?

BTW. Worth noting in passing that I think .NET is not, in principle anyway, proprietary to Microsoft and people are working on independent and open-source support for the .NET "platform" (I think I read somewhere they are or will be adopted ECMA standards).

It certainly is possible to retain the server-side of a ProIV application and rewrite the client-side in another technology. For an application I worked on, the front end was rewritten in VB and it also has multiple Java-based Web user-interfaces. However, this was a simply huge amount of work. All the code was rewritten by hand and a whole new infrastructure was created to handle the client-server connections and messages. The cost was many millions of dollars.

[CSuarezdelReal]

Hi!

I am glad to see that it has started a very interesting discussion about the advantages and disadvantages of a new tool to deal with our daily job. I do agree that it is not an easy or short term initiative. But let me stress the main thinking that pushes me to publish my proposal:

Is there a single 4GL based on Java Technologies? (as for me, the market is still open on that issue). I was searching the Internet for several days, looking for something like that and could not find any close approach to what I am proposing.

A few days ago I read an article that tells that there are two ways to carry out a complex project, say an Operating System or a DBMS: The cathedral model and the bazaar model. The first one needs a very complex organization (as the one needed to build a cathedral) and a strictly formal way of working. That’s the way Microsoft or other major software vendors create their products. The bazaar model is a lot less complex, its organization is relaxed and the main engine for the project is the will the people that works on it has to provide the best of them to create the final product.

That is how Linux, Postgres and other open projects succeeded. Before Linux, nobody thought it would be possible to create a complex software product out of a fuzzy group of people that do their work on their own and the post the results to a central container that integrated very diverse ways of programming. But let me tell you something. If you program something that will be signed with your name, and that will be open to a lot of other programmers, you want to create the best code and the neatest solution to the problem so that the others do not disregard your code or correct it. Result, a high quality code. What about the same work done by two or more different programmers at the same time?. Linux has shown that that is not so common (perhaps less than 5% of the times) and the solution is to continuously release updates to the system so that the programmers can see what the others have done.

All in all, my point about that story is that, to my view, the “product” has a place in the market (not only for Pro IV developers) and second, it is possible to succeed with an open initiative.

As for the almost impossible task to convert all the Pro IV code into a new 4GL, I see the solution quite simple. Keep the code you currently have. Create the new programs using the new tool. Eventually you will get rid of the Pro IV programming. And if you do not get rid of that is because it is working well its way, or it is not needed. The colophon to this approach is, the new tool should create software that integrates quite well with the applications already developed in Pro IV.

Finally, what I would like to create?. A 4GL with SIMILAR functionality as Pro IV. A lot of implicit behavior (isn’t that what makes a 4GL?). Open source. Java as the procedural language to “logics”. Support to standard SQL. Able to deploy solutions as a multi-tier model. Native integration to XML Technologies. All of that using as much open components as possible (say Linux, Java, Prostgres, eclipse and so forth).

I guess that when Pro IV was first created, it took some interesting concepts from Lisp (after all Lisp was very popular in the research area in the 70´s). It uses nested lists (characteristics, very obvious in SuperLayer) and properties for them (including files and logics). It is said that Python is the new Lisp concept, revamped to not to fear the conventional procedural programmers. HTML and XML are new ways to present the spirit of Lisp, using tags instead of parenthesis. Have you noticed that it is straightforward to express a Pro IV program as an XML document?. I mean, XML is a buzzword now. Why do not take advantage of the quantity of open sources for XML and Python to create the next step of Pro IV?.

I have a lot of more ideas to share, but I would like to hear your comments.

Saludos,

[Richard Bassett]

Is there a single 4GL based on Java Technologies?

See http://www.cbronline...0256d480018c962
You certainly won't find the marketing folks calling anything a "4GL" any more – I think they feel it sounds dated and everything has to be "RAD" now

[The Bazaar approach] is how Linux, Postgres and other open projects succeeded.

Don't agree I'm afraid.

Before Linux, nobody thought it would be possible to create a complex software product out of a fuzzy group of people that do their work on their own and the post the results to a central container that integrated very diverse ways of programming.

It is not, IMHO, "possible to create a complex software product out of a fuzzy group of people that do their work on their own" – not unless a complete and clear design for the product already exists and the necessary work can be shared out sensibly on the basis of that design.

Linux was not a "new" software product. It reproduced the functionality of Unix which had been widely understood for years and for which multiple reference implementations were available. Thus there was an absolutely complete, detailed, concrete design already in place. The only novelty of Linux was that is was 'free' – for which we should all of course be grateful. Notice also that in the beginning and for a long time later, Linux was under the strict architectural control of one person.

PostgreSQL was based on code from Postgres and other work done at Berkeley and is built on years of previous research and code. AFAIAA, the functionality was already pretty much defined and the PostgreSQL project re-engineered the codebase to make a better, open-source product.

Code is not design. Lots of the successful communal open-source projects have involved coding and little or no design. You would have to establish and agree a comprehensive design for any new tool before anyone could consider coding. I suspect this is far MORE important for a geographically/temporally fragmented development group than it is in the "cathedral" case. The communal open-source approach can clearly work, and work well, for coding – but I've never seen any evidence that it works effectively/efficiently for design (I'd be happy to be better informed).

As for the almost impossible task to convert all the Pro IV code into a new 4GL, I see the solution quite simple. Keep the code you currently have. Create the new programs using the new tool.  Eventually you will get rid of the Pro IV programming.

Er.. but what exactly gets rid of the ProIV programs/programming then? Or is this based on the idea that some of your "new programs" involve progressively rewriting the ProIV programs rather than maintaining them

And if you do not get rid of that is because it is working well its way, or it is not needed. The colophon to this approach is, the new tool should create software that integrates quite well with the applications already developed in Pro IV.

In the long term though it doesn't make sense (for support or staffing or simplicity) to use two separate technologies for the same purposes within the same application. People probably wouldn't want to start using a new (and presumably advantageous) technology for the same part of their problem as an existing technology unless it's clear how to transition away from the older technology in a sensible timeframe. Otherwise you remain constrained by the older technology and (worse) by compatibility issues between the two technologies.

Unrestricted Java where ProIV has logic seems unlikely to be compatible with any 4GL's "implicit behaviour" (I expect that's not what you meant) but a Java subset or Java-like syntax could certainly work and might make a tool seem more "widely accessible".

I may be wrong (and it certainly never occurred to me to ask) but I don't imagine ProIV was influenced by Lisp at all. Lists don't seem to be a fundamental to the language in any way. Remember SuperLayer is "just a preprocessor " for ProIV that came along much later.
I was told more than once that ProIV started out purely as a report generator and evolved from there. I'd guess RPG is the most likely original influence (whether it actually was I have no idea).

I would also doubt the relevance of Lisp to most commercial programming or programmers

Edited by Richard Bassett, 12 September 2003 - 06:30 PM.

[CSuarezdelReal]

Thank you very much for your words Richard!

I was expecting a lot of comments like yours, because that would help me to properly understand the state of the current Pro IV community regarding new approaches, and whether mine is viable.

http://www.cbronline...0256d480018c962 is a good link. It goes deeper on terms I treat briefly. I might have problems trying to share my idea: I want an environment that can create a HIGH QUALITY APPLICATION… RAPIDLY!. That is something we are accustomed to achieve with Pro IV. Let’s look for that goal SOMEHOW, using the current and future technology.

You may know how hard was for IBM to debug their First Computer Languages and Operating Systems. Most of the times their products lacked quality and were delivered late. We have walked a long road since then, but even now gigants as Microsoft are delivering products with critical security holes as the one in Windows that put several companies on their knees when the blaster worm attacked a few weeks ago. Then and now, those companies where using a “cathedral” approach, given different circumstances.

I do not say one or other model is better, I just can say, a dispersed, not tightly organized, well directed groups of people with the same objective WITH THE PROPER GUIDANCE (with a leader, as Linus was) can succeed on getting great things done.

I have to stress, the cathedral and bazaar definition is borrowed, and you may find more about that in the Internet, that support what I said. It is not my intention to defend it or not. My point is, the bazaar does work, and we could give birth to a bazaar project here.

It is said rules are established to be broken. True, Linux is Unix (via Tannenbaum’s Minix) and Postgres is Berckley’s Ingres, they did not INVENTED the product but they INNOVATED it, most of the times a task even harder than Inventing. The Wright Brothers might have INVENTED a viable way to fly, but until there appeared the first commercial flight company (the INNOVATED), that was nothing but a cute way of spending free time or fight.

I am asking to INNOVATE, to make a Pro-IV-like RAD available for the mass (isn’t that the concept of Innovation?). I am asking to gather:

a) The Pro IV Model (simplicity and fast coding)
Java (for Logics and as the base language)
c) Postgres (to hold code and data)
d) XML (messages and interfaces)
e) Eclipse (IDE)
g) Linux

That requires design, but not as much as when INVENTING.

How do you replace 1,000 PC’s in you company?. All at once?. Or a few of them at a time?. What is more risky and hard to do?. If you replace a few functions at a time, suddenly you will find yourself working with Pro Java instead of Pro IV, just as you find sometime working with Windows XP for almost all of your users. There may be a few PC’s that do not have to be replaced, they just still work well with Windows 3.1 or 95. Same as functions.

But I was not proposing to MIGRATE a full system as Glovia from Pro IV to Pro Java (not at all!), which would be and overwhelming task!. I was asking to program NEW functionality using the “wanna-be” tool.

About using two technologies for the same purpose… aren’t we already doing that in a lot of systems?. Personally I used Netware and Windows NT Server at the same time, TCP/IP and IPX/SPX at the same time, SCO Unix and HP-UX at the same time. They do more or less the same, but we learned to deal with both of them at the same time. I agree, however, simplicity is best, and now I only use Windows 2000 Server, TCP/IP and AIX.

My point about Lisp may be irrelevant for the sake, I just wanted to trace a path from Pro IV to XML. Anyway, it is my point of view that XML took a lot of work done by Lisp research. And who can say XML is not a VERY commercial product?. Their bare core, the way they represent their essence, is the same. After all, Pro IV can build Pro IV code, Lisp can create Lisp code. XML can create XML code. Pro IV have characteristics, Lisp have parenthesis and XML have tags. Different ways to represent the same. My final point: We may leverage the existing XML open technology to INNOVATE a computer environment that mimics Pro IV, so that we do not have to start from scratch. I point out, again, a Pro IV function can be depicted easily as an XML document.

I am open to any comment or opinion.

[Richard Bassett]

Well.. I think the ProIV community is largely "conventional procedural programmers" (including me) but that it is open minded about new approaches. However, it is, in my experience, very pragmatic and would need to be thoroughly convinced that any new RAD tool was genuinely relevant and not just a "flight of fancy".

I am familiar with Eric Raymond's article on "The Cathedral and The Bazaar". One does have to remember that Raymond is a leading evangelist for the open-source movement, so while the article was certainly important and provocative it can hardly be considered objective!

My main point was that some reflection is merited on the circumstances under which "the bazaar" works effectively and those under which it may not. For example, how well does it work when trying to decide and specify WHAT should be built rather than actually building.

Incidentally, to me "innovation" is just a thing introduced as a novelty (or the act of introducing a thing as a novelty). I guess I view invention and innovation as similar things but innovation is less impressive. Sure the first commercial flight was a novelty but hardly on a par with the first aeroplane!

It seems to me your proposal is to create a new "language" isn't it? So some invention or at least inventive design is needed even if only to reconcile all the capabilities you want that language to have.

I thought your basic idea seemed clear – A modern 'free' RAD tool retaining the perceived advantages of ProIV. The devil is, as always, in the detail – specifying what that RAD tool "is" , what it looks like, how it works and how it could coexist with ProIV if that is important. What interests me, and motivated my first post, is to see whether there is any concensus on the detail and if so whether any common aims seem realistic or not!

Regarding what you've already suggested I'd say that, for me, you need to:

Say what "Pro-IV-like" actually means. (As there is in fact no documented ProIV "model" you need to explain what features you want to retain and maybe why - and which you want to lose).
Quantify what "high quality application" means for you - where are your specific aims?
Quantify what "rapidly" or "fast coding" means for you - again where are your specific aims?
Address some of the other questions in my first post

If you want worthwhile coexistence with ProIV then I'd also say:
Targeting only Java would be insufficient (you need to target .NET too, at least for the client side).
Targeting only PostgreSQL would be insufficient (you need Oracle and maybe SQL/Server too).
Targeting only Linux would be insufficient (you need commercial Unix (easy) and maybe MS servers too)

Storing code in the database may not be a great idea – most IDEs and "open" tools are based on the use of files.
Note ProIV's use of "bootstraps", although advantageous in some ways, has been and remains problematic.

As an example of an obvious but tough question:
It's all very well saying "replace a few functions at a time" but explain to me how, in practice, I could rewrite one ProIV function using some new Java-only tool and incorporate it into my existing ProIV application (we'll ignore the software distribution and dependency problems for now if you like!)

What am I doing in front of this computer at the weekend? Good question…

[CSuarezdelReal]

Hi Richard!

I enjoyed reading your last message...


My idea is to create a tool that takes the best of several already existing RAD’s, including Pro IV. In theory, would have as much features as Pro IV, plus new ones that I am asking the people here to suggest. As for Pro IV compatibility, I was not proposing to force it. I rather consider taking the knowledge of our community to create something better than what we have.

"WHAT to build", that is questions I would ask here. Inventing something could be a historic milestone, and it may give glory to the inventor, but less admired, though more practical is innovation. I think that Da Vinci was a great inventor, as well as Edison and Marconi, but Edison and Marconi did not stopped just inventing, they invented, and then innovated, making light lamps and radio, among other things, available for everybody. They were more practical and gave us a better quality of life.

I am no talking about a new language, rather a framework that takes care of the “assumed” running environment, so that we can focus on the problem to be solved. As you I want to see what the other people here thinks and if any effort aimed on a new tool is viable.

What is to my view the Pro IV model?... well I may forget important points, but let’s start:

1) Processing Blocks called “characteristics”
2) Fields involved within those blocks
3) Files processed per field
4) Automatic key mapping
5) Security per function, file and field
6) Automatic design of screens and reports
7) Modes of functions: Add, Change, Delete and Lookup
8) Intermediate code (“genned”).
9) Multiplatform

What I would like to change… again I may be missing some important restriction to overcome:

1) Force structured programming, in a large sense
2) Object oriented
3) Multi tier possibilities
4) Stronger GUI characteristics
5) Java as the language for logics
6) Bootstrap in a database

High Quality; well, quality may be hard to define, but you can feel it when you are in front of it: Give the right information to the right person at the right moment.

Rapid and fast coding would be, as I already mentioned, to create applications focusing on the problem to be solved, and letting not only the screen and report design to the tool, but other issues as well: database details as key mapping and what fields would be needed.

Java Technology, as J2EE is open, and than means, we could work with those tools “free”, not as .NET. Other technologies could be addressed later, but I would not ask to an open community to buy something to develop.

Same for Postgres and Linux, they are “free”. To my view Postgres is a lot much better than MySQL or other open databases, and personally I like that it is Object Oriented as well as relational.

I would think that if we are smart enough, we may start with those open standards and then move the resulting tool to work with proprietary software.

I would like to know what problems you find to the “bootstrap model”…

My idea, again, is not to compete directly “against” Pro IV… I would not “dare” to replace every single function of Pro IV. In fact I would like to give a “step” forward leveraging our experience with Pro IV to create a new tool. As for how to incorporate the new functions to old Pro IV applications, I would suggest seeing it at a “database” level and only use common data and may be a similar working environment.

May I suggest disregarding index files for any basic processing?. I would not care about Pro ISAM compatibility, which is why I was suggesting using Postgres as a repository for the code.

I invite to other people to share your thoughts!.

Regards,

[Kevin Bruss]

This may have been posted elsewhere, but Glovia (an ERP package) has what they refer to as an e-client product. Its a server side based software that allows the Genned functions to be seen on the web (must be Java) just like in the normal client. Total functionality of the menus, buttons, function keys, etc. were usable and visually
laid out identically the same. The only thing as a developer was you could not shell out; that was about it. Licensing is very expensive (by no. users) so my company never implemented it. But I got to see it in action at my other company and it looked great.

I'm pretty sure this feature is more of a 'custom' package not directly found on their web page (as is their multilingual support). If interested, their home page is http://www.glovia.com. (Tell them I sent you.. )