John, Firstly, the 3/4 GL differentiation is important to appreciate in this regard, and therefore, relevant. The Action Request System platform *IS* a 4GL and as such it is not fair to do direct comparisons to functionality or ways of working that we find in 3GL environments such as Java, C, VB or even .Net. ARS allows someone with no programming background whatsoever, to create working, usable applications within a matter of hours. No 3GL does that. ARS just sits in a different niche of the market.
Secondly, my open challenge still stands to any 3GL platform to develop a working functional and customisable client/server workflow application from scratch, in less time than with ARS, that (to name only a few) a) can run on Windows, Linux and Unix and be migrated between all these within a matter of minutes b) has a native and web front-end capable of Query-by-Example or advanced search criteria c) is capable of full customisable application and data permission structures d) is capable of handling more than 200K records in all tables (meaning integration to a mainstream RDBMS and not using ODBC) e) is integrateable to other systems using an open API amongst about 19 (or more) other mechanisms. Even Java can try with EJB's... Thirdly, Yes, having done a lot of scripting development outside of ARS using 3GL platforms such as COBOL, Java, VB etc, I too, have been frustrated by some of the development (and source control) limitations posed by ARS in the past since starting out with Ver 2 in late '96, but the platform has grown significantly since then especially with the bold move to the new eclipse-based DevStudio (Hats off to Doug and the team). Conversely to your statement, one could also argue: " I don't see why AR System developers should be placed into a box and told they must do things the way those in the 3GL world does it" There are a number of tools available to compare different copies of code (such as Remedy Migrator). We just have to be patient and give Doug and the boys more time to slicken up the new overlay and version control functionality. Lastly, To answer your question "can anyone think of a disadvantage with taking workflow from the schema and into scripts?: Having to debug large workflow systems, sometimes cold-faced, after things have gone wrong, is a huge and daunting task. Doing this with having the ARS "code" in db tables has turned out to be a heaven-sent thing for me. This is because a) you can run customised sql scripts in one place on the ARS "Code" to find out within seconds where the fault could be in the code or to see what code is related to what. Scripts won't give you that. b) you can run customised sql scripts in one place on the ARS "Code" to find form/workflow objects you should re-use within seconds. Scripts won't give you that. c) you can run customised sql scripts in one place on the ARS "Code" to document your system or specific portions of it. Scripts won't give you that same type of flexibility. Furthermore, scripts pose other disadvantages: d) a single backup command backs up all your data and all your code in one managed location. Storing scripts across multiple ssh connected servers will make it difficult to back up or replicate your system elsewhere e) ARS (with it's table based code storage) provides functionality to limit permissions to view or change code. Scripts stored on a filesystem pose a security vulnerability of being overwritten, deleted or infected by viruses as well as access to view it's contents by unintended individuals. f) Managing a code base where your code lies in scripts across multiple locations can be costly on time as opposed to have everything in one spot. I agree with you that we should keep on looking for better ways to do things, but ARS would not have come as far as it has done if it did not provide a huge positive netto balance of advantages as opposed to it's cost and disadvantages. To throw something out because we have newer different ways of doing the same thing would be like stopping traditional procreation activities because we have invented artificial insemination. The way ARS is designed around storing it's "code" may not be 100% perfect, but my vote is to keep the code in the tables. Best Regards, Theo -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of John Baker Sent: 12 January 2012 21:37 To: [email protected] Subject: Overlay and Applications Guillaume I do take onboard your points but I have to disagree: AR System provides no version control. If you believe it does, please tell me how I revert a form to its state at any point in time since AR System was installed, and no, taking hourly backups of my database isn't a useful step forward. I don't feel the 4/5/6GL discussion is relevant to my post (and it's not something I really recognise now-a-days). I'm talking about how to improve the platform, not the way in which it's used. And many problems in IT are not simply solved by some sticky tape, or a new cache, but a serious change in thinking. That's evident in MId Tier 6.3, and if the concept was pushed back to the AR System server level, the entire platform would benefit. I appreciate change is never easy, but as other posters have pointed out, there's a lot of attraction to having an easy to use platform that can also happily compete with other platforms. I've self-taught myself to write in a number of languages (yet I speak just one), and I don't see why AR System developers should be placed into a box and told they can only use the admin tool with limited functionality, no version control or useful development tools, or find a Java compiler and use another product. There's a lot of middle ground between those two poles. John _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
