What's Coming!

Couple of thoughts... In your interview, you mentioned the Quick Reference Guide. From the sound of it I thought this was something very new and didn't realize that it was something I had seen a month or so ago so I went looking for it. I did find it eventually ... not too easily. At first I was going to suggest that you post a message here with each new contribution, but I guess maybe you did, but the connection slipped my mind. It would be nice to have an overall page for the library that showed new additions in reverse chronological order so that one could flip through what was recent without having to have heard about somewhere or just to verify that the "new" thing was what one thought it was.

While I think this stuff that you are doing to reach down to make things more accessible for the people new to this stuff is great and essential, one of the things I have some concern about is the other direction. By this I mean getting to the point where there is some kind of reference which people can go to that provides concrete direction for production quality implementations. AutoEdge is a very lovely demo, but the architectural models in it aren't really suitable for production systems, so I'd like to see whitepapers and sample code, even perhaps something at the level of AutoEdge or a bit more which really grappled with the issues which matter in production enterprise systems and provided at least some themes and variations guidance to people who were trying to move in those directions.

Yes, I know that when one gets down to a specific application that there is no universal answer and sites need to go through the issues and make their decisions, but I don't think that prevents us from giving them some models to look at, especially if they are annotated with what design choices were made and what alternates were considered. The level of documentation with AutoEdge is one of its really positive features, but even there I would like to see a sort of 19th hole analysis that points out design choices which one would make differently if starting again and notes aspects that are recognized to be weak so that people don't take them as a finished product and go try to build an ERP on that model.

Apropos of which, I would like to see the OO versions be not just a translation of what is there now, but a sort of second generation ... a fresh thought on the topic incorporating both the best of the OO principles and lessons learned from past experience.

As for the success of this forum, definite congratulations are in order. Aside from the length that the forums have existed, there are some quite striking differences in the pattern of usage. The OERA forum has 190 views per thread, 10.8 views per message, and 17.6 messages per thread. The ADM2 forum has 7.8 views per thread, 3.1 views per message, and 2.5 messages per thread.

So, it appears that the OERA forum has a lot of lurkers and tends to get into long-winded discussions!

The material on a class-based implementation of OERA will indeed not just be a translation of the earlier procedure-based materials, but will present some alternative ways of some of the key parts of the design work, in some cases related to and in some cases unrelated to the specific support for classes in ABL. So it should provide various kinds of fresh information -- soon!

Let me throw out an idea here. John, you have done a lot of work in providing whitepapers to help people get the ideas necessary for OERA. This is a very valuable contribution. Likewise, the AutoEdge team has put forth an incredible demo application to illustrate these principles and gone beyond mere implementation to document many aspects of the design. The virtue of these contributions is all the greater because PSC hasn't always had a good track record in providing architectural guidance.

But ... you knew there had to be a "but" coming, didn't you ... there is a certain problem in the materials to date which I would describe this way. On the one hand, code samples and even the whole AutoEdge application are presented as illustrations, samples, i.e., something that shows in a concrete form how an idea is done and this is often accompanied by an overt disclaimer that this is not intended to be finished, production ready code. Despite this, there is a tendency among some people to take these materials as a model for their production systems, at least in some cases apparently without the kind of critical review which I am sure you would council they engage in in order to create a real production quality framework or model. In a way, this isn't surprising because the models they have are all they have, i.e., there is no beginner's set and advanced set or any real guidance on the difference between the simple models used for illustrating principles and what they might need for a real production system.

This makes me think that there might be two additional ingredients that you might want to consider throwing into these plans for the next round of work.

One of these ideas is to think about what you might do to help point people toward the complexities of a production system, i.e., at the same time as you think about coming up with some even more elementary materials, also work on coming up with some advanced materials. Particularly in the first round, these don't have to be fully worked out sets of production ready code ... which, after all, might well vary from context to context. It could be nothing more than a systematic discussion of issues that one should consider in designing a production ready system. E.g., relative to the data access layer a discussion about data base transaction scope, logical transaction scope, remote data sources, assembling complex objects, what logic goes in what layer, what about triggers, etc., etc.

The other idea is to put together a sort of peer review panel of people who are actually out in the field wrestling with these issues and to get their input at various points along the line in developing any of these new materials ... not just the advanced ones, but the basic ones too. By starting with a complex concept and simplifying it for the purpose of illustration and education, you might find that the simple version was already more robust and certainly that it transitioned into a more complex and production ready model in a more graceful fashion. You might well find, with the right panelists, that the advanced pieces almost wrote themselves because the panel would provide the catalog of issues and the pros and cons of different approaches which one might want to consider.

It is possible that you would need sub-panels for dealing with .p versus .cls implementations, but I certainly think the two groups would have a majority of requirements in common, even if the techniques for solving them were different.

We're out here and we want to help. Use us.

We're out here and we want to help. Use us.

Obviously community is a big thing for us, hence PSDN and from my perspective hence OE Principles and the forum. Now if anyone attended last years exchange, we ran a poster fair stand which showed something I termed the OpenEdge Community Process, which had 4 key steps:

1 - OpenEdge Principles guidance published on PSDN

2 - OE Community Participation and Consumption of material via PSDN

3 - Community exposes scenarios, challenges the work and puts forwards needs etc, via forum and feedback

4 - OE Principles Team + Community provide solutions to scenarios & needs

5 - Goto Step 1

I think it's fair to say that over the past few months we've all probably gone through steps 1-3, and I think the point you raise in your response is step 4.

So I have a question (or 2), how would you (as a community, not just Thomas) envisage something like this working? Obviously in the past Progress had initiatives such as POSSE, which at the time I was a consumer of as a partner, and without wishing to denigrate the work that was done, there are probably some lessons to learn from that.

Would it be feasible to come up with collaborative community based design and implementation(s) for more 'real production' environments that are applicable to more than just one persons particular issue? What about peoples differing approaches and mindsets on specific topics, Domain vs. Table for example. Can we have a utopia where we have plug & play Reference Components that can be put together like a jigsaw to build, dare I say it, an architectural framework? Most people probably remember the Smart Object Marketplace, I don't recall seeing many contributions, and yes I was as guilty as the next person!

This is an important topic as it was always envisaged (in my mind at least) that the community, not just PSC, would contribute in moving OE Principles as an initiative forwards, so I'm interested on everyone's thoughts, even those lurkers who Thomas so rightly points out in an earlier posting, are out there somewhere, so feel free to come and join the discussion and have a say. There are no right or wrongs here!! So don't be shy.

Hopefully, that doesn't mean "not including

Thomas"! Yes and no. If PSDN

were set up like OE Hive, then one could create a new node or

project, publish some initial material, gather feedback, submit

revisions, potentially subversion the content for branches and

resolutions, lather, rinse, repeat and treat some of these

materials like open source projects. But, PSDN isn't really

structured that way since the best that one gets with any new

submission is a new document version or a new code share entry. I

think this presents a couple of problems relative to the kind of

interaction which I would like to see. 1. Any one version tends to

come across as an "authoritative" statement because it isn't

embedded in any feedback process. For many people, of course, this

is just fine because all they want to do is to consume these

documents ... although they certainly might be interested in

hearing that there was an update. 2. For someone who wants to do

more than consume, however, the only real channel for feedback is

the forums. I think there is a limit to how effective a feedback

mechanism this is. If someone raises a question about something in

a document or code and doesn't get much of an answer, then the

exchange tends to stop rather than moving on to the next question.

I have certainly seem this happen in the AutoEdge discussion where

I know there are many points which have never been raised because

an initial feeler died out. Besides, the discussion is separate

from the document ... there is nothing with or in the document to

suggest that a person should question it. There is also a haphazard

aspect, i.e., I have raised a couple specific points that have

occurred to me in reading, but I certainly haven't brought forward

every point, nor have I attempted to engage in any systematic

review other than following my own current interests. Just by

nature of the beast, I am much more likely to question something

concrete, like AutoEdge, because there is real code to dispute,

than I am some whitepaper, especially if I start off reading the

whitepaper with some core differences of orientation. That kind of

thing rarely comes to the surface in the current process. 3. Even

if this mechanism worked, the cycle time looks like it would be

very long. 4. One of the ideas which I am trying to suggest here is

that the input should be obtained before the first publication.

I think this

is a problem with layers ... layers that are increasingly hard to

achieve, but that doesn't mean that one shouldn't start. The first

layer, I think, is in exposing the problem. By this I mean that, if

one is going to write about how to address data access, for

example, then one should be starting with a problem statement of

the issues which are going to be involved in solving that problem

in a real-world production environment. Different people with

different experience bases will have different emphasis on what is

in that problem statement, but that variation is an inherent part

of the statement. E.g., some environments will have a need for

dealing with a real time data stream. If one does have that

problem, it is a very significant issue, but if one doesn't, then

it isn't, but we can all recognize that this can be an issue and

even recognize that, even if we are not facing the issue today,

that we might be in the future. The second layer, I think, comes in

assembling techniques to address the issues raised by the first

layer. This is unlikely to be definitive, i.e., there will be

choices of techniques and they will address different parts of the

universe of problems. If one has a particular problem, then one is

going to have to use a technique that addresses it, but if there

are multiple techniques to address a problem, one has a choice.

With a free exchange of ideas, one is likely to find that some of

these techniques emerge as preferred because they have good

coverage and a flexible in addressing a larger range of

requirements, but that won't invalidate other options which might

be picked by some individuals on the basis of simplicity (but

adequacy) or because of special requirements. The third layer is

actual code. Given that I don't expect the second layer to ever

fully resolve, one obviously wouldn't expect this layer to fully

resolve either, especially since it will add additional sources of

variation such as stylistic preferences and a preference for .p and

.cls solutions. Of course, the ideal way to handle that would be to

have a model-driven generator from which one could select various

options in the transforms to arrive at the version of choice. Now,

to be sure, this is an extremely lofty goal and not something we

are going to accomplish fully any time soon, if ever. But, I don't

think that this means that one can't include aspects of this

context in more modest efforts. I think this is especially the case

since our context here is ABL and so we know that the application

domain is going to be dominated by enterprise transaction

processing systems and that domain context will tend to imply some

strong patterns on the requirements.

So I have a question (or 2), how would you (as a

community, not just Thomas) envisage something like

this working? Obviously in the past Progress had

initiatives such as POSSE, which at the time I was a

consumer of as a partner, and without wishing to

denigrate the work that was done, there are probably

some lessons to learn from that.

I think one of the problems here is that 4GL (ABL) has a "limited" audience, since the tools are not as "easily available" as Java/C+/C/.Net. A company that develops ABL-logic has no real benefit sharing their intellectual property, since, if it would have any value, it would be sold. Futhermore most ABL-applications use very specific tools/frameworks. You will see a similar issue with old Visual Basic: there is no open source visual basic framework as far as I know. You do see this stuff for Java, C+, etc. maybe because its more portable...

Now for the POSSE: this was basically a dump-and-good-luck from Progress. It was very hard to get a feature to be adopted in the mainstream branch. And since people still had to recover from SmartObjects, the time wasn't right for just another framework. And we, the developers, were right, since the Dynamics got torn down piece by piece: first POSSE, next statements about rather improving the core language than a framework, etc. PSC is right about that of course

So your challange would be to:

- lower the bar for developers to contribute

- use an existing open source site (Sourceforge) and don't create a private area

- make yourself visible on Sourceforge by making it one of the most active projects

- create a core framework with pluggable parts, which can be used by itself

- focus on the following parts:

+ cross database platform database access

+ using the Progress database from Java

+ middle tier

+ caching

+ access control, logging, audit trail

+ user interface (seperate sub projects for .Net (WPF), Java, HTML, ABL)

+ only use OOABL and write .p wrappers if you need to

- create an atmosphere of openess and sponsering, not ownership.

For the last point it would be better if some characteristic PSC employees would drive the project instead of "the PSC company". Make it personal, identifiable.

Good luck!

- create small

The material on a class-based implementation of OERA

will indeed not just be a translation of the earlier

procedure-based materials, but will present some

alternative ways of some of the key parts of the

design work, in some cases related to and in some

cases unrelated to the specific support for classes

in ABL. So it should provide various kinds of fresh

information -- soon!

It would be nice if the core technology would be OOABL and you would only provide .p/.i wrappers for easier integration. Sure, this would exclude applications running on pre-10.1, but you might ask yourself if that's the target audience.

I think pretty much everyone

agrees that POSSE was a failed experiment. It pretended to be open

source, but in reality was still mainstream core development of PSC

product. It can't be both and it failed even to really involve the

community for input except in a very limited way. It is a model for

a number of things that didn't work. And yes, a part of that is

the core framework which it was about. Or, use a more full-featured,

Progress-specific site like OE Hive! Again, I

think one needs to make distinctions here in the type of project. A

whitepaper on OERA best practice is likely to be something that PSC

wants to have be an actual PSC publication and therefore something

on which they ultimately have ownership and responsibility. MDA

tools, on the other hand seems like an area where open source is

the way to go. There is no simple hard line here. E.g., at this

point AutoEdge is a PSC demo application so ultimately they have to

stand behind what it says, but that doesn't mean that one couldn't

have OpenAutoEdge which was a project to extend and improve on that

base.

While your argument about IP is a frequent one, it is

also one that runs counter to the whole open source

movement, which is clearly a factor in the modern

computing world. Not only are there quite a few

people who are happy to share what they create for

the sheer joy of it (plus possible advertising

value),

... but there are very few in the PSC community who actually do, which I was referring to.

Well, I don't know about that ... visited OE Hive, PEG, PSDN code share, v9stuff, v10stuff, etc. lately?

Well, I don't know about that ... visited OE Hive,

PEG, PSDN code share, v9stuff, v10stuff, etc. lately?

but that's the very small group of enthusiastic people you will see over and over again (the PEG is a forum of course). But you're right about PSDN CodeShare: I missed that one.

Anyway I think I kind of deduced from Mike's reply:

Can we have a utopia where we have plug & play Reference Components that can be put together like a

jigsaw to build, dare I say it, an architectural framework? Most people probably remember the Smart Object Marketplace, I don't recall seeing many contributions,

and yes I was as guilty as the next person!

that he was a bit unsure how to proceed and how to make the material a success. But like you say, when it's reference material, PSC should be responsible for it. I can't imagine that you're able to design a ProDataSet in the ABL-labguage without having a clear view of how it should be used and which problems it solves.

There

is a certain amount of overlap from those that are the most anxious

to get their stuff out there, but there is a lot of material which

is unique to each site. Check out http://www.oehive.org/whitepages

for a longer list, although still far from complete. FWIW, one of

the purposes in the OE Hive is to try to get all of this stuff

together in one place eventually, where it will be easier to find.

And PEG has utilities and whitepaper download pages in addition to

the forum.

that he was a bit unsure how to proceed and how to

make the material a success. But like you say, when

it's reference material, PSC should be responsible

for it. I can't imagine that you're able to design a

ProDataSet in the ABL-labguage without having a clear

view of how it should be used and which problems it

solves.

Ok, so firstly, I agree that what 'we' (PSC) put out as Reference Material, we should be responsible for, but don't forget there will also be material that isn't reference material per se, but simply more general 'how-to' materials, such as the Enhancing the GUI work for example (http://www.psdn.com/library/kbcategory.jspa?categoryID=299).

So my utopia question was in some ways more aimed at how feasible is it to be able to get to a position where certain 'Reference Components' are provided by us, for instance, and some by the community, and at the same time making sure that no matter where the pieces originate, that they could plug & play together to form a bigger whole. For example, we could design a base set of classes for an OO Reference Implementation of the OERA, and then use Interfaces as place holders for other components such as an Authorization Manager. Could I expect someone in the community to then take our base classes plus the Authorization Interface, and provide an implementation for a particular security model? Then maybe someone else provides an implementation for a different security model, and these are then be posted back and made available. If someone then had an authorization need that was met by one of these components, that person would have a certain level of comfort that it will work because it simply implements a published interface. (Ok just because it implements the interface doesn't mean it does anything useful inside, but you get the idea!)

So in some ways the question isn't about how to proceed, its more about levels of co-operation and collaboration. Thomas's point about OpenAutoEdge is an interesting one. If you look in code share we have some entries entitled "AutoEdge After Market" which are contributions to extend or change AutoEdge behavior. So please anyone feel free to extend, enhance, etc..

What I'm wondering is, if this is a model that could be truly expanded, because as we know just from the forums, there is a time commitment to anything like this, and no disrespect to anyone who's posts, but typically we see the same names crop up time and time again. (Now don't take umbridge and stop posting !!)

What level of involvement should I (speaking from an OE Principles perspective now) expect from you, my customers, audience, partners? Could we have a true OE Community Process, similar to the JCP, where specs are jointly created, the work is then produced, by a mix of internal and external folks? Past experience maybe says no, I fully appreciate that you have to keep the money coming in the door, everyone has day jobs, and again as I said in my earlier post, I was as guilty as anyone in the past.

Not that we're looking for work, we have plenty to keep us going But if I look back to my original vision statement for OE Principles :

"OpenEdge Principles providing guidance in creating the worlds best business applications with OpenEdge through proven design, practices and community involvement", it's making sure we have the right balance of 'community involvement'.

But once again, thanks for the feedback and do keep it coming.

While it would be lovely to think of creating some consortium of PSC people and people from the "real world" to create all kinds of wonderful materials, I think that, at best, that is something that we need to work up to. Among other things, industry models for that sort of thing tend to involve multiple large companies with people in each company which are paid for being a part of that consortium while in this world many of the strongest contributors in the world of users are individual consultants or people from very small companies who just can't afford to commit large systematic blocks of time to this kind of effort on a regular basis.

I think that one of the things this tells us is that we need structures which allow people to chip in on topics which interest them particularly, without necessarily committing them to overall involvement or anything long term or comprehensive. Now, I recognize that this is not the formula for getting commitment, but I think it is necessary in the Progress context.

Mind you, I would also like to see some commitment from the large APs into this effort since they are likely to have some meaningful experience, but perhaps they already have seat at the table through Directions, which us small fry don't have. Still, I would like to see something more intimate and interactive from them.

So, apropos of needing to work our way into this, I think that there are also different types or levels of material. To start with we have a list of things that you, Mike, have outlined above. This material is on PSC's production schedule as stuff that needs to happen, whether or not we come up with any form of community involvement. At the other extreme we have some vague notion of OpenAutoEdge or, perhaps more properly, the Open OERA Platform (OOP!), which is a family of intercoordinated components suitable as the base for production OERA systems.

The short term stuff is probably going to be useful and valuable even if you stick to the old methods of producing it and we only lodge our complaints after it is published. It could be better with community involvement. OOP is something that definitely ought to arise out of the community and which will take a fair amount of structuring to become a productive environment. It almost certainly should be open source.

Between these two there are a bunch of other projects and products which are undefined or vaguely defined and which fall between these extremes, i.e., some of them could happen adequately done the old way, but others would be significantly enhanced by community involvement and in some cases the very definition of what was to be done could come from community involvement.

So, on the walk before running theory, let's focus first on the stuff you have announced and let's decide provisionally that these are all projects where it is going to be assumed that someone from PSC will be taking the lead in the actual production work. What might you do for community involvement?

One of the first questions here is "how open?" Are we talking about something which might take place on a PSDN forum for any and all to read and reply or does PSC feel a need to play things a bit closer to the chest?

One of the issues here is that a PSDN forum may not be ideal for this kind of interaction because one is going to be wanting to share work product and that would seem to imply PSC people being willing to post early drafts in a public place. We all know that Mr. Bascom would approve, but I can appreciate that a lot of PSC staffers might find this a bit nervousmaking. The alternative would seem to identify a group of interested volunteers, sign NDAs if necessary or, at the least, agree that the material will be kept to the group until ready for publication, and then work through things with that group. I would try not to get too draconian about the restrictions, though.

A comment that I might insert in here relative to the NDAs is that I think one of the needs in the program of developing new materials is that it needs to become more proactive. My idea of the right way of doing things is that one would have had at least three or four substantive pieces dealing with OO underway during the 10.1A beta, i.e., at least as soon as there was something to play with and probably before.

So, let's suppose you post something on PSDN about a particular idea and ask for volunteers, you have some interaction and perhaps make some specific requests of people you know that might have input, including both other people in PSC, including people from the consulting organization, and people from partners who don't normally contribute on PSDN. I think one could have as many as 10-12 people identified in a group like this, knowing full well that some will contribute a lot and some only a little.

Then I would circulate a piece about the goals and intents of the work and look for feedback on what needs to be included. This should turn into a discussion. Most or all of this might be e-mail, but there might also be a role for a conference call, although the geographic diversity makes that a scheduling challenge. There should be an effort to reach a consensus on the goals, although for this early stuff one would probably have to assume that the lead PSC person would have veto power, most commonly exercised over things which were perceived to have too great a scope.

If this is something which starts off with a primary PSC author identified, then I would expect that person to take the synthesis of goals and start work on the paper or code. I would expect that during this process there might be a place for communications attempting to clarify a goal or to discuss some alternatives. The more open ended the goal, the more I would expect this discussion to occur. In a project developing some model code, I would expect it to be nearly continuous. With code, there might also be volunteers to develop some of the code.

At some point this results in a draft. At that point I would expect a concentrated review by the group with encouragement to be as critical as necessary. Of course, a wise author will have communicated enough during the development process not to have any surprises at this stage. That leads to a revision and publication.

For some kinds of topics there are likely to be issues where there will not be consensus. In those cases I would suggest either trying to include alternate opinions in the main document or possibly a "minority report" as an attachment.

One of the keys here will be giving the participants a real feeling of involvement and participation. If they get to say some things and then it seems to have no impact on anything, as if no one even noticed, then they are unlikely to repeat. Conversely, with participation, the material could be easier to produce and we would get more better and more results.

The first step beyond this process could be also opening the doors for authors to develop materials which then receive the PSC imprimatur and join the library, not just code share.

As for the whole OpenAutoEdge thing, I think there are really three different goals to be considered:

1. Enhance the existing AutoEdge application so that it provides a better model for production OERA applications;

2. Create an OO version of the AutoEdge application; and

3. Create a reference framework of components suitable for building production OERA applications (OOP).

1 might be accomplished in the process of doing 2 and and initial version of 3 might be a side effect of 2 as well and pieces of it might be the first thing to become available out of this effort.

The first step in this direction needs to be a documented goal.

>> I can't imagine that you're able to design a

>> ProDataSet in the ABL-labguage without having a

>> clear

>> view of how it should be used and which problems

>> it solves.

When I read my quote once more, it's a bit negative.... which was not what I meant.

So my utopia question was in some ways more aimed at

how feasible is it to be able to get to a position

where certain 'Reference Components' are provided by

us, for instance, and some by the community, and at

the same time making sure that no matter where the

pieces originate, that they could plug & play

together to form a bigger whole.

We have something similar with Microsoft: they provide "application blocks" like caching, data access, etc, see http://msdn.microsoft.com/practices/guidetype/AppBlocks/. One of the problems with this is that you have to drag in other application blocks when you want to use one. Probably because the designers don't want to re-invent the wheel. So in reality it will be hard to create fully isolated blocks without any assumptions.

So even a plug & play architecture doesn't mean that you can plugin anything...

I think it's PSC responsibility to address the tough design decissions for a loosely coupled architecture:

- should one use a data driven architecture or a model driven and why

- how can one create database portable ABL-code

- how do you deal with error handling & validation

- how do you deal with batching in real life

- what do we do with ABL-triggers

- etc.

It will be a challange to write something that is generic enough to be used by anyone, but detailed enough to address real life complexities.

Could I expect someone

in the community to then take our base classes plus

the Authorization Interface, and provide an

implementation for a particular security model?

Perhaps when you give the developer an ego-boost by mentioning the creator of the component Open source projects have problem owners and members. That might be the difficult part here: find the proper balance in being able to update code and trusting the updater.

but

typically we see the same names crop up time and time

again. (Now don't take umbridge and stop posting !!)

That's what I meant as well. And we do not post/read for the same reasons. I find it fun reading what's going on in ABL, I'm no ABL-developer anymore...

But we experience the same thing: very few PSC-names pop up in the forums...

Could we have a true

OE Community Process, similar to the JCP, where specs

I think you have tried that with POSSE. People need results now. What would help is more feedback from PSC. That's what motivates "folks".

But if I look back to my original

vision statement for OE Principles :

"OpenEdge Principles providing guidance in creating

the worlds best business applications with OpenEdge

through proven design, practices and community

involvement", it's making sure we have the right

balance of 'community involvement'.

And the "proven design" part is the one that we're questioning every now and than...

Keep up the good work, invest in collaboration!

While it certainly would be delightful to

get to the point that we had a library of re-usable components for

people to draw upon, I think that the most important ingredient is

actually the thought processes and considerations which would go

into making such components. In fact, I think that we have to

proceed with the idea that there was a strong likelihood that

people would take any such components and customize them. E.g.,

someone has an existing security mechanism which has evolved over

20 years to handle the authorization issues in a particular

application and they are going to start migrating to an OERA

architecture ... well, they are likely to take the

security component and then modify it to fit the data structures in

their existing mechanism. There is nothing wrong with this unless

that system is trying to interoperate with another system and the

two are not loosely coupled (and in a SOA, we would expect them to

be loose). But, no, I don't want PSC to be the one defining the

goals. Frankly, that is how we got ADM. I think the goals more than

any other part need to come from the community because it is the

community that knows hands on about the requirements of production

systems. BTW, I should also note that in any one specific area, one

is likely to have one or two persons who will take a leadership

role in defining the problem and the backbone of the solution. They

will take that role because they are interested and experienced in

the topic, they have thought about the problem, and they are the

ones with the passion and expertise. This doesn't need to be the

PSC person in every case ... in fact, it might turn out that it was

rarely the PSC person because in most cases the PSC person won't

have the experience base.

More PSC staff feedback on PSDN is certainly a positive thing, but

I don't think it deals with the topic here. Getting substantial

community input is going to require more than just posting on a

forum.

>>I think one of the problems here is that 4GL (ABL) has a "limited" audience, since the >>tools are not as "easily available" as Java/C++/C/.Net.

Shouldn't the OE platform be more accessible for students, schools and interested IT professionals ? Broaden the "audience" , build a larger community ....

I am referring to what MS is doing with their Express Editions, for example ...

Something like a free ABL development kit ...

Jurgen Van Bouchaute.

No. Let's grow on our strength, not try to copy the techniques of those marketing to entirely different purposes. Whether or not PSC decides to offer free development kits, ABL isn't going to become the new Java. It would be nice for those who are already working in ABL and are stuck at employers who are on old version because they could keep their skills current, but it isn't going to lure in the masses.

No. ...

In your opinion

I'm not saying that I am opposed to PSC doing it, but rather that one is dreaming to think that a free development kit is going to make ABL the next Java. If a free kit were offered, I am pretty sure there would be an up front rush from existing developers whose jobs keep them on old versions as well as shops working on old versions who just want to check out what's there in case they manage to modernize. A few others would get sent out and most would turn into shelfware. End of rush.

On the other hand, if we build up the community, increase the resources, create open source projects, etc. we might build up things somewhat, but even then it is long, long, term before we make any mark on popularity. We just aren't in the running and we shouldn't be thinking that we should be trying to be. We've got a good thing going and its goodness doesn't depend on the mass market even knowing what we are.

I'm not agreeing or disagreeing, I just thought the 'No.' was a little abrupt in reaction to someone else's opinion, and that maybe you'd really wanted to start by saying, 'In my opinion......'

When is it ever anything but my opinion?

I think this is an excellent idea. Do what MS did and "get em while they are young". then they carry the technology into their work place with them.

Warning - A little hobby horse of mine

If Progress could get its engine running in a JVM or the .NET CLR then it would ""much"" easier to share in an "Express" format .... I personally think its a little heavy at the moment because I'd see the PSC Express needing:

• ABL Runtime

• Eclipse

• At least Workgroup DB

• AppServer (lets say up to 20 agents)

• Sonic (say single CPU version)

• ProxyGen support

With that you can do a lot of nifty stuff but its a lot to install. Also, with .NET I can build something in "Express" and run it anywhere with the .NET runtime. I can't as easily do that with Progress unless I write something that will run without a DB connection in WebClient.

Can we take this discussion off to a different thread so that we don't lose site of the topic in this one?

A Class based implementation of the OERA - This

should be relatively self explanatory.

>

....

Architecture Made Simple (working title) - Firstly,

yes it's a working title so fully expect the final

name to change. We've spent quite a bit of time over

the past few months putting out material that, to be

honest, is probably more towards to medium to

advanced level of things, rather than beginner level.

So having worked through some of the hard stuff, we

figured we should try and put together a more

beginner level series of work that walks you through

from concepts and techniques people are familiar

with and more then likely using on a daily basis

today, and gently introduce OERA concepts and ideas

without you really noticing! It sounds like a neat

trick, and going by what I've seen of the material

so far, this is great stuff and one certainly to

look forwards to. Expect to see this sometime in

the Spring.

I think this is great and I really think we need more "dummies" or "Starter" guides. Let me give a couple of examples:

1. I think some of the BEST papers I ever read were the 4 white papers originally written to give guidance for the ProDataSets. They gave a quick intro but by the end of paper 4 you had a great grasp of what it was all about

2. Auditing. I have to say this is something I have really struggled with. I've printed all the doco out from the manuals and PPT slides etc. I have to say I find it a little confusing and, in case, contradictory. There was one really good, if too short, paper called "A quick start guide" (I think). That showed how to get going really quickly. What it lacked was a part II, III and IV (or IIII on my clock, but I digress). I've finally got it down now (I think) but its taken me a week of reading. Also, there isn't any "performance metrics" - even if they were on sports or the ATM demo - that would have been a big help.

3. LDAP - This appears to be a great getting started guide for this (I have not tried it yet though).

4. There are a lot of people still on V9 (like me). What I'm trying to get is the "whats new V9 to 10.1B) guide. There are a LOT of "whats new guides" in between.

5. Anthony talked about "try it out" when talking about AutoEdge and the architecture. This is great but ""time"" isn't always available. I think you guys are missing out of a fantastic tool here. ProLint. I would have liked to have seen some "ProLint" rules that we could run on our apps to show us parts that would need upgrading. E.g. You have a form with direct "for each" support it ... UPDATE: You need to n-tier you app. Please refer to the following web links for examples etc

Anyway, I strongly look forward to the Spring series on "Arch made simple".

Thanks for the good work all

Murray

Of course, ProLint is not a PSC

product. You should put suggestions into the issue tracker at

http://www.oehive.org/prolint . You will note that there has been

some thought in this direction, but it isn't easy.

Actually - I'd prefer a Wiki ....

A wiki for what?

If for the version differences, my point is that one person is considering moving from 9.1C to 10.1B, another from 10.1A to 10.1B and a third from 10.0 to 10.1A. Putting all that in documents ... and wikis are still documents ... means a lot of collecting the right pieces and then reading them. With a database driven solution, each person could ask what database changes are there between version A and version B and get a compact answer.

Not to mention needing a demo machine with Sonic,

IIS, and current Progress to install it on. I think

it is great that the code is available separately,

but it would be nice to have at the very least a good

video showing it being used, if not a way to use it

remotely.

This was/is an interesting challenge and one we did give a fair amount of consideration too. Could we create Virtual Machine images and let people down load those? But they would be big downloads, and how would we stand on licensing as each vm would include a copy of XP? We also considered something like MS did with their Office 2007 Live trial where you can access a remote VM, but you can imagine that takes some setting up and wouldn't be a trivial exercise.

So I think we took a pragmatic approach and there are recordings, in fact quite a few. One gives an overall demo or guided tour (http://www.psdn.com/library/entry.jspa?externalID=1697&categoryID=298) , the others concentrate on specific topic areas (http://www.psdn.com/library/entry.jspa?externalID=1701&categoryID=298). So are you saying those recordings have missed something?

No, I'm saying that I didn't know the recordings were there. I haven't looked at them.

No, I'm saying that I didn't know the recordings were

there. I haven't looked at them.

Shame on you

Well, all I can say is that I have a workstation with all the necessary stuff on it, so I can run the real thing ... so who needs a video?

Shame on you

Is it?

If you were a progress newbie, would you know these resources where there?

Mike, I would like to make a very specific plea with respect to this idea of public input ... get some of us out here involved in the process of defining the standards and conventions for OO OERA as were pointed at in this morning's webinar entitled OERA Update: Class-based Implementation.

Mike, I would like to make a very specific plea with

respect to this idea of public input ... get some of

us out here involved in the process of defining the

standards and conventions for OO OERA as were pointed

at in this morning's webinar entitled OERA Update:

Class-based Implementation.

Right, ok. I've been thinking about this, and how we best approach a more community involved process. So my first question, is how many of you, including the lurkers, would be interested in being involved in a more community driven project within OE Principles? No disrespect to Thomas, but for something like this to work it need to be more than just a lone voice.

As for what would be involved and what the project maybe, well once I get an idea of who may at least be interested, I can post one or two of the project ideas we've had and see where we go. Obviously I think we'd need to start small with a clearly defined goal and set of deliverables. If it works then maybe we can look to expand. If someone has an alternative idea of a project we could maybe look at that as a future possibility. My main aim initially would be to see if this could work, without people having to over commit or getting their fingers burnt (especially me !!). Let's be clear, this is an initiative within OE Principles, not a huge PSC driven initiative, just me (and maybe others depending how it goes) trying something new with you our community.

So, now's your chance, if you'd like to be involved say so. If your too shy to post , email me directly (mike.ormerod@progress.com).

I await your responses !!

Mike

I'd be interested, especially if PSC was a sponsor and contributor, rather than the director.

I'd be interested, especially if PSC was a sponsor

and contributor, rather than the director.

Thanks John. As I said, just to be clear, this is an OE Principles initiative, not a PSC wide initiative. I want to start small and see how we go first. This is Mike slightly putting his neck out to see how far we can run with this. If it works out, and I sincerely hope it does, no promises, but maybe we could expand.

As for responsibilities, we can figure those out when we have a list of interested people.

But, once again thanks !

I agree that we need more than one voice ... even if the one voice is mine!

But, I also don't think that one needs to think in terms of eveyone doing exactly the same thing either. Some people will be interested in one part and have a lot to say about that piece and maybe say nothing on other pieces. Others will speak up frequently. Nothing wrong with that.

I think to really get an idea of what people would or would not be willing and interested in doing, though, it is going to have to be a more concrete proposal. The topic may be key in getting people interested or not. The process is likely to matter. Plus, there should be some recruiting of people who don't visit these forums in a visible way, such as people in APs who are actively working in the area.

Deleted double-post caused by PSDN strangeness.

Right, ok. I've been thinking about this, and how we best approach a more community involved process. So my first question, is how many of you, including the lurkers, would be interested in being involved in a more community driven project within OE Principles?

I'd suggest you just do it. Create a working area, post a project to it, and go for it. It's better to start with something rather than toss out some theoretical question with no real concrete substance to hang it's hook on and hope people'll "get" what you're talking about and respond.

As for what to do - I'd suggest starting with a small single table round-trip implementation of the OERA which works for both an appserver and client-based implementations. From there you can build other small examples to demonstrate maintaining multiple tables, and other concepts you've been talking about.

Another thought would be to pull some sample code out of AutoEdge and discuss it in more detail.

If things are done right, people'll be able to take these examples and roll their own in their applications.

One possibility, since there has already been some discussion about it, would be to focus on the data access layer, that being something whose needs are better understood and more general than other layers, pull up the existing AE code, discuss what needs to be different about it to support a production environment, and them aim at defining the requirements for an OO version.

One possibility, since there has already been some discussion about it, would be to focus on the data access layer, that being something whose needs are better understood and more general than other layers

That certainly sounds like an idea to me - identify the various cases one is likely to encounter, code a solution to those cases, then come up with an integrated example which pulls all the other cases into one structure.

The problem-specific examples would show the specifics of dealing with their respective cases in easy-to-understand pieces, and the integrated case would show how to pull it all together.

Getting to a new set of code is certainly the eventual goal, but I think a great deal of value can be obtained long before we get to candidate production code. In fact, it is possible that there is enough diversity of purpose that one needs more than one set of code ... there is certainly enough diversity of opinion for that!

But, we would have accomplished a lot even if all we had was a couple of documents, one of which documented all the things that one might need to think about in deciding on a design, i.e., a definition of the problem space; and the other a consideration of the alternative approaches to solving those problems. Then, with or without specific sample code, a person can go through the first document and find all the issues which pertain to their case and then go through the second and see both what appeals and what aspects address their particular pattern.

For example, one of the possible requirements would deal with distributed deployment and thus the need to deal with data access for an entity which might either have a local DB as a source or it might have a remote XML as a source. Then, the solutions side would have patterns which responded to this requirement. Someone who had this need would pick up and emphasize those patterns, but someone who didn't might ignore that part.

I think one of the very positive aspects of AutoEdge is that it is substantial enough and considered enough to provide a reasonable focus for this kind of discussion. Before this we have mostly just had little fragments and a smattering of really trivial examples. AutoEdge may need work before it is one of the candidates for a model of a production ready system, but at least it is well structured enough to provide a good focus for discussion.

Well, all of that too.

My thought is that this is to come up with code that's as much an educational demonstration of problems and solutions as it is getting production code.

Smaller problem spaces can be easily identified and solved in stand-alone examples, and if someone wants to do more extensive docs on them they can do that.

More involved / messier problems would require a specs doc to detail what's what, and so would the resulting code.

Properly done, the smaller example cases should be easily foldable into a a more comprehensive solution or set of solutions.

I think that the possible solutions document probably needs to be accompanied by sample code, which fits into your educational use category.

I'd like to keep the ultimate focus on a whole set, e.g., data access, and on production ready, because I think that keeps us from thinking in terms of little code snippets which need to be different if they are part of a real system. There is too much of this sort of snippet in existing docs.

I think that the possible solutions document probably

needs to be accompanied by sample code, which fits

into your educational use category.

Sounds good to me.

I'd like to keep the ultimate focus on a whole set,

e.g., data access, and on production ready, because I

think that keeps us from thinking in terms of little

code snippets which need to be different if they are

part of a real system. There is too much of this

sort of snippet in existing docs.

Agreed again. I'm not suggesting that the examples be what passes for examples elsewhere (like http://tinyurl.com/39xs9j), but something which solves a particular problem, follows good development practices and form, it's form and any built-in assumptions are clearly documented, so the general developer off the street can easily "get" what's going on.

I agree that I think we should start with words before we start with code. We need to scope the problem, and design a solution, then look to code. It sounds like 'Industrial Strength' Data Access is a suggested starting project?

I agree that I think we should start with words

before we start with code.

Why limit yourself?

Whatever code that's developed has to survive maintenance anyway, so one can do a spec, write some code, update the spec, change the code, etc.

or

write the code, write the spec, see where the code doesn't measure up, update the code, etc. etc.

We need to scope the

problem, and design a solution, then look to code.

Whatever way this is addressed it has to be maintainable, so starting with code or a spec shouldn't really matter.

Even defining the problem would be an iterative process.

It sounds like 'Industrial Strength' Data Access is

a suggested starting project?

It's as good a starting point as anywhere else.

I agree that the words precede the code, but that they also can develop in parallel after a starting period. I would see us starting with a discussion which provides the baseline of the needs document, some of it triggered by issues in AutoEdge. Probably, we almost immediately start accumulating possible solution elements as well. Myself, I would hold back a bit from doing much code on the solution elements, but if there are people who express themselves best in code, then so be it. I would like both the needs and the solutions to percolate for a while before we started really looking for complete components.

I propose using OE Hive to host this effort. We can create a project and different contributors can create book pages and link them into the roots of the two documents. Initially I would include code as a part of the book page and then we can start a repository when we get far enough to have decided what should be in it.