Feedback & Contributions

Hi Marian

Firstly, I'm glad we managed to sort the account and get you back :-)

We absolutely want to try and make this as open as possible so that people can contribute, and we also want to make it easy, which I understand given past experiences hasn't always been the case.  We're still trying to figure out the best approach to facilitate that, so if anyone has any smart ideas then please comment.  One thought would be to host the code in a public SVN repository so it can be downloaded directly into OE Architect, or maybe use something like Mercurial so people can work independently and then sync up.  Certainly the internation isn't to ban or doom anyone to a dark place for wanting to contribute, just the opposite, we'd like to create an ability for people to contribute free & easily.  The more contributors the merrier!!

Mike

I'd like to suggest that there are really two separate possible focuses for sharing here.  One of these is AutoEdge itself, i.e., a unified body of code which can be used as a demo or pedagogical tool or source of inspiration about what to do (or not to do ).  The other is possible general purpose components which could be used in lots of different contexts in the spirit of the OERA Open Source Initiative ( http://www.oehive.org/OERAOSI ). E.g., if Marian wanted to build on what he saw in AutoEdge to create something of broader and greater applicability, what one would really like to do is to get that into its own open source project where people could debate the merits of a general purpose component and identify those components so that they could easily be adopted for use in their own work.  If a good such component were developed, then one might want to retrofit AutoEdge to use it, both to improve AutoEdge and illustrate the use of the component.

Actually having open source improvement of AutoEdge is possible, but much more difficult than creating a component library of open source components.  Indeed, there is nothing wrong in a library of open source components of having more than one version of the same thing for people to choose from.  One only wants to do that if there is some difference of purpose or packaging, but it is quite legitimate.

E.g., if Marian wanted to build on what he saw in AutoEdge to create something of broader and greater applicability,

He or anyone else are welcome to do that, or use it to build something of smaller and more focused scope, or simply use parts of it in their application. It would be fantastic for any additions, modifications and fixes to feed back into AETF and the OOABL-based OERA implementation it stands on (O3RI as some here call it), where others could benefit from them.

what one would really like to do is to get that into its own open source project where people could debate the merits of

a general purpose component and identify those components so that they could easily be adopted for use in their own work.

Um, that's kinda the entire purpose of this community and code.

I can only reiterate enthusiastically what Mike O said earlier

... we'd like to create an ability for people to contribute free & easily. The more contributors the merrier!!

We're still working on the mechanisms for contributions, but in my view, we clearly need to do something better than archives attached to forum postings. We've batted around the idea of using a DVCS like Mercurial* or Git; or a more conventional system like SVN; or something else.

Although, if zip files are what people find most comfortable to use, then so be it. I will say that it makes merging just a tad tricky.

We're also really interested in ideas of how we can make it easier for you - as a developer - to digest parts of AETF/O3RI - whether that's per layer (ie horizontally) or more vertically (like how does a data request work). UML diagrams are certainly a part of it, but not everyone's comfortable in that medium and many prefer to dig into the code first and read the doc later, so the question extends into how can we make code navigation easier (working sets in Architect? Smaller projects? Something else?). There's also the question of what kinds of docs are useful - straight references? What-were-we-thinking docs? Videos? Webex-y kinds of things? Just the AutoDox2 code documentation?

-- peter

\* there's a great tutorial on Mercurial at http://hginit.com/ . Really opened my eyes.

Using the bundled facility for multiple messages for error message

formatting might be tempting but one might think it's breaking a bit the

separation of concerns principle... from what I see the log functionality is

also bundled in the exception object itself, probably it's a known

'issue'... more like a quick fix and it's already on the todo list but I

just though worth mentioning.

Just in general terms, certain aspects were/are implemented in a "just enough" sense because the intent for the initial release(s) was not to have a complete application and stack (that would have taken a little while longer, and we already probably stretched the definition of "soon" plenty far enough ). So yes, things like exception handling and logging are only partly complete.

Certainly I would like to see the logging/displaying/printing of errors be completely removed from the ApplicationError itself. Similarly I think there may be a need for an ExceptionManager of some form; but that's where you (all of you) come in: is it a good idea or bad? Or only for some applications? And how to do it?

And I certainly appreciate the input you're already providing.

-- peter

Obviously what I'm more interested in is the core part, something that could lead to a software development kit - http://openjdk.java.net/

Releasing something as open-source and let others integrate that in their own projects is definitively a start but you might ask (well PSC not directly Mike or Peter) if there is a need for a software development kit and if PSC should come up and provide one with or without community involvement. If the answer is yes then imho you should limit the scope and break that in core and additional services components instead of packing everything as a whole, previous experiences with ADM (1, 2) and Dynamics might help

As for getting some community involvement this is something that can be difficult, still there are a number of peoples that do have that open-source philosophy and often contribute back to project that they find useful... still, PSC is probably in the best position to attract such contributors... Thomas initiative on OEHive for an OSI group is a notable one but I think he can confirm it didn't get the attention he expected

Anyway, something like openjdk require a lot more involvement from PSC than simply releasing a sample application that happens to have core components bundled within... it might sound bad especially since there are a lot of good code and concepts in there but if those remains stuck in the 'demo application' itself it's quite difficult to take them out of the picture.

should come up and provide one with or without community involvement. If the

answer is yes then imho you should limit the scope and break that in core and

additional services components instead of packing everything as a whole,

previous experiences with ADM (1, 2) and Dynamics might help

Packaging is one aspect of this, to be sure. But the intent is that each component can stand alone: there may be downward dependencies (if you take the AVM/ABL as the bottom), but I don't think that's unusual. If the components can't stand alone, or there are cross-dependencies, then that's a bug and needs to be fixed.

You should be able to take the OpenEdge.Lang.* and OpenEdge.Core.* packages and use them without requiring the AETF application code or even the OpenEdge.CommonInfrastructure.* code.

Anyway, something like openjdk require a lot more involvement from PSC than

simply releasing a sample application that happens to have core components

bundled within... it might sound bad especially since there are a lot of good

code and concepts in there but if those remains stuck in the 'demo

application' itself it's quite difficult to take them out of the picture.

Maybe the installer should be renamed, but you can install each part individually from that installer - you don't have to have the whole stack: just select the components (OERA layer, really) you want. Or should each part be installable individually, via its own packaging mechanism?

So instead of

AETF_Installer which contains choosable components for the application, O3RI Presentation Layer, Business Components, etc

There would be

AETF_Installer Application

O3RI_Presentation_Layer_Installer

O3RI_Business_Components_Installer

Etc

Does that make sense? Would that be more useful?

-- peter

Maybe the installer should be renamed, but you can install each part individually from that installer - you don't have to have the whole stack: just select the components (OERA layer, really) you want. Or should each part be installable individually, via its own packaging mechanism?

I thing a single installer where you choose the packages as components is preferable. Otherwise you might end up in a nightmare of product and version dependencies...

I thing a single installer where you choose the packages as components is

preferable. Otherwise you might end up in a nightmare of product and version

dependencies...

Certainly part of the reason for there being a single installer is for that reason.

However, I wonder whether it'd be worthwhile renaming it to something like "OERA Samples & References Apps Installer" and have various components in that (AETF application, O3RI stuff, etc).

I'm already planning on adding a 'source only' option to the installer (which would basically put the bits on disk and nothing more, as opposed to installing an AppServer and DB like it does now).

-- peter

I'm already planning on adding a 'source only' option to the installer (which would basically put the bits on disk and nothing more, as opposed to installing an AppServer and DB like it does now).

Good idea.

And make the installer source/project available as well. Installation is always a hot topic.

And make the installer source/project available as well. Installation is

always a hot topic.

>

I thought it already was, but will do.

Hope your Pascal skills are up-to-date

-- peter

pjudge wrote:
And make the installer source/project available as well. Installation is
always a hot topic.
>
I thought it already was, but will do.
Hope your Pascal skills are up-to-date 
-- peter

We actually use a free tool for building the installer, Inno Setup (http://www.jrsoftware.org/isinfo.php) which if memory serves me right was something that Marian put me onto many, many, many years ago!!  It's a very cool tool and has most of the features of something like InstallShield.

well, it is a great tool and one might say it proves that Pascal is not dead just yet

don't worry Mike, you can always build DLL's and call them if you like that more than fooling around with some kind of Pascal scripting...

We actually use a free tool for building the installer, Inno Setup (http://www.jrsoftware.org/isinfo.php) which if memory serves me right was something that Marian put me onto many, many, many years ago!!  It's a very cool tool and has most of the features of something like InstallShield.

Sounds interesting.

I think especially the OpenEdge related bits of the AETF installer are interesting. Starting from reliably finding put where OE is installed, versions and of course setting up DB and AppServer in the .properties files

marianedu schrieb:
 well, it is a great tool and one might say it proves that Pascal is not dead just yet 
don't worry Mike, you can always build DLL's and call them if you like that more than fooling around with some kind of Pascal scripting...

Well, I went to university before Java became the standard there. So I'm used to Modulo 2 and Pascal. Not sure, If I still have a compiler anywhere.

http://www.bloodshed.net/devpascal.html

bloodshed have this as well, I'm more fun of dev-c++... my one and only IDE for small C based projects

mikefe wrote:
marianedu schrieb:
 well, it is a great tool and one might say it proves that Pascal is not dead just yet 
don't worry Mike, you can always build DLL's and call them if you like that more than fooling around with some kind of Pascal scripting...
Well, I went to university before Java became the standard there. So I'm used to Modulo 2 and Pascal. Not sure, If I still have a compiler anywhere.

Pascal is the language that InnoSetup uses for advanced scripting; it's not necessary to know it though - a lot of the install can be build with a UI from a tool like www.InnoIDE.org  . It's really nice; Windows-only but other than that a treat to use.

-- peter

I still maintain that there are separate purposes here.  I haven't had a chance to look at the latest incarnation yet, but I'm going to bet that the chances are very high that there will be many aspects of the architecture with which I will disagree.  Moreover, it would be surprising if it were really a complete model for production code; hasn't been yet.  I think it is a fine notion to evolve it, but I think there is also a need for production ready components.  In particular, those components need to not assume the whole rest of the architecture or no one will ever use them.  One needs to let people mix and match for their local needs and preferences.  Moreover, a component buried in AutoEdge is not visible.  One needs to be able to go to the "library" and look through the security components or whatever to see what is close to what one needs.

It may have gotten the attention I expected, but not the attention I hoped!

But, yes, one needs to go directly to the component.

I haven't had a

chance to look at the latest incarnation yet, but I'm going to bet that the

chances are very high that there will be many aspects of the architecture

with which I will disagree.

Of that there's no doubt. Having all-inclusive agreement of all details is not what this project is about.

In particular, those components need to not assume the

whole rest of the architecture or no one will ever use them. One needs to

let people mix and match for their local needs and preferences.

I have stated elsewhere that this is one of our goals, and that the code is structured to meet that goal. There's a high degree of modularity and loose coupling IMO, precisely because we didn't want any illegitimate dependencies.

Take a scratch around the code this weekend; I think you'll be pleasantly surprised.

One needs to be able to go to

the "library" and look through the security components or whatever to see

what is close to what one needs.

How would you define this "library"?

-- peter

By library, I mean that one does want to have to approach all of AETF and grub around to see what kind of component it might have that does X.  One wants to go to a website, look in the X category, read descriptions of alternate X implementations, and download one or two to look at.

tamhas wrote:
I still maintain that there are separate purposes here.  I haven't had a chance to look at the latest incarnation yet, but I'm going to bet that the chances are very high that there will be many aspects of the architecture with which I will disagree.  Moreover, it would be surprising if it were really a complete model for production code; hasn't been yet.  I think it is a fine notion to evolve it, but I think there is also a need for production ready components.  In particular, those components need to not assume the whole rest of the architecture or no one will ever use them.  One needs to let people mix and match for their local needs and preferences.  Moreover, a component buried in AutoEdge is not visible.  One needs to be able to go to the "library" and look through the security components or whatever to see what is close to what one needs.

As Peter says we'll never please everyone, and that's not the aim, Comments, feedback & criticism based upon looking at the body of work I fully expect and understand, part of the project is to stimulate discussion,  but I do find it a tad trite that even before looking at the stuff your glass is half-empty.

If there were more philosophical argreement up front, I might be more optimistic.  But, really, the issue is that there is diversity of opinion in the ABL community.  Whatever PSC does, no matter how well thought through, is not going to match the needs and wants of the entire ABL community.  The resistence to ADM is good historical evidence for that.  But, one of the big flaws of ADM is that it was all or nothing.  What is needed is an easy way for a person to take an individual component, modify it if desired, and use it in their own application without having to adopt a whole new architecture.  Better yet, because there is that diversity of needs and desires, one should have multiple choices for each component whenever there is a diversity of role that one might want.  A big integrated example has its point, but so does a component library.  The big integrated example can't have a diversity of approaches.  The library can.

BTW, why O3RI instead of OERI?

BTW, why O3RI instead of OERI?

OOOERI (to distinguish it from the OERI used underneath the original AutoEdge, or AutoEdge|TheDealer in the Factory's terms

-- peter

If there were more philosophical argreement up front, I might be more

Is "argreement" a shortened form of agree to disagree?

Wouldn't that be O3ERI then?

So far, it seems more like agree to argue!

How would you define this "library"?

I would guess he's more talking about a catalog of components.

Library can easiely be confusing with a method of packaging stuff.

Catalog works.