Feedback & Contributions

Posted by Mike Ormerod on 31-Mar-2011 10:12

We've had a few emails directly asking whether we want feedback & comments on the code and if people can conribute code to the project.

The answer to all those questions is an emphatic YES!!  We want to try and gather as much feedback as possible, and if you have code to contibute that will be awesome.

Like all problems, we fully realize there are multiple answers and you may agree or disagree with the approaches taken in some of the supplied code, if so tell us!

All we ask is that instead of emailing us directly, you use these forums, so everyone can participate.  There are no right or wrong answers here, it's all just a matter of opinion, so let us know yours.

For those of you that have given us direct feedback, thanks, it's much appreciated.

Mike

All Replies

Posted by Admin on 21-Apr-2011 13:32

Hi Mike,

now  that I've finally got my account back (thanks again) and found at last  some time to download the project I went directly to the error handling  part as I was re-writing that part on my jdk clone (found out that  implementing JMS without core components is not very easy) and I had the  chance to put some thinking on that subject the other days.


I've also used 'named' exceptions as it was a Java clone but at start  all exceptions were inheriting directly from AppError, trying to fix the  difference in ReturnValue and GetMessage and also because I wanted to  be able to chain exceptions I've added a core exception class... which  I've found you already had


I did dropped all those add/remove messages since I think it should be  only one message per exception, the cause (inner exception) is there to  be able to chain them in a stack and added the printStackTrace to simply  dump it on standard output.

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.  I've also decided to drop all exception chain on destructor, I know the  GC is already there but I'm an old guy... I like to clean up myself as  much as possible.


I did not had the time to get through much code to see how you actually  use that exception mechanism but I've found many places where AppError  is thrown, could be something you added later and not fully  implemented... the choice of having an error title and different  constructors for specific 'named' exceptions it can be a question of  style


Anyway, having a core exception object and chain exceptions together is a  good idea... like in, never delete an error that you catch just to  throw a specific 'named' one, always chain the cause in the new  exception you throw.


I would like to have some real contribution on that but due to the  bitter taste after the posse.net experiment I hardly find myself  contributing to a closed project... were there any thoughts on going  open with this, like hosting it in an independent open-source  collaboration platform to really give the community the freedom to  contribute?


I think Apache license is something that we can work on, maybe we can  simply fork that on sourceforge while keeping the license... think I  might get banned or doomed for ever for doing such a bad thing?

Regards,

Marian

Posted by Mike Ormerod on 21-Apr-2011 13:48

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

Posted by Thomas Mercer-Hursh on 21-Apr-2011 14:20

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.

Posted by Peter Judge on 21-Apr-2011 20:30

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.

Posted by Peter Judge on 21-Apr-2011 20:50

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

Posted by Admin on 21-Apr-2011 23:44

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.

Posted by Peter Judge on 22-Apr-2011 07:50

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

Posted by Admin on 22-Apr-2011 08:20

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...

Posted by Peter Judge on 22-Apr-2011 08:25

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

Posted by Admin on 22-Apr-2011 08:35

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.

Posted by Peter Judge on 22-Apr-2011 08:45

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

Posted by Mike Ormerod on 22-Apr-2011 09:19

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.

Posted by Admin on 22-Apr-2011 09:25

Posted by Admin on 22-Apr-2011 09:28

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...

Posted by Admin on 22-Apr-2011 09:32

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

Posted by Admin on 22-Apr-2011 09:33

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.

Posted by Admin on 22-Apr-2011 09:45

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

Posted by Peter Judge on 22-Apr-2011 09:49

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

Posted by Thomas Mercer-Hursh on 22-Apr-2011 13:50

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.

Posted by Thomas Mercer-Hursh on 22-Apr-2011 13:52

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

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

Posted by Peter Judge on 22-Apr-2011 14:00

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

Posted by Thomas Mercer-Hursh on 22-Apr-2011 14:13

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.

Posted by Mike Ormerod on 22-Apr-2011 14:19

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.

Posted by Thomas Mercer-Hursh on 22-Apr-2011 14:27

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?

Posted by Peter Judge on 22-Apr-2011 14:40

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

Posted by Peter Judge on 22-Apr-2011 14:40

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

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

Posted by Thomas Mercer-Hursh on 22-Apr-2011 15:47

Wouldn't that be O3ERI then?

Posted by Thomas Mercer-Hursh on 22-Apr-2011 15:48

So far, it seems more like agree to argue!

Posted by Admin on 22-Apr-2011 17:15

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.

Posted by Thomas Mercer-Hursh on 22-Apr-2011 17:39

Catalog works.

This thread is closed