John, I don't agree in regressing the ARS platform into a 3 GL or 3.5 GL. Posts have been submitted in the past where the consensus is that ARS is at least 4 GL, bordering on 5 GL. The freedom is there for programmers to create applications in any language they like: Python, Java, .net, etc. Developers that want to program in 3 GL, go and do that in whatever you like, but don't try to square the Remedy ARS cercle. Whether your company approves or not applications developed in whatever language or platform is another problem. But for those that don't like ARS development: comrades, get out of it and choose something that fulfills and enriches you, or that at least that you will find interesting or gratifying to do for 8 hours per day.
ARS is rapid development, it has it advantages and limitations: that is the nature of it. You either like it and accept and live with it, or you don't and choose something else. About what the Remedy code/definitions is stored in the database vs. files, I guess there is only a handful of people in the whole world that can answer that question. The design decisions taken more than 20 years ago may not apply nowadays, or apply less. The question is what is the problem to solve. Is the problem to solve faster start-up times, then the pre-load segments come in handy. Is the problem the mid-tier cache, the 764 versions has the sync cache feature and other features that alleviate that, not entirely but alleviate that. On the other hand, putting the code in the database allows for queries to be done against the code, transactional integrity, backups, etc. So the question is what is the problem to be solved nowadays. if it is version control, BMC is incorporating version control capabilities in ARS. What I think you are advocating is that ARS becomes like service-now, and that is not going to happen. Customers are realizing that service-now is NOT the silver bullet they were promised, and some of the service-now customers are going back to BMC Remedy. I recommend you get familiar with service-now to see all the shortcomings they have, and how they compare with ARS (latest versions of both products of course) Guillaume ________________________________________ From: Action Request System discussion list(ARSList) [arslist@ARSLIST.ORG] on behalf of John Baker [jba...@javasystemsolutions.com] Sent: Thursday, January 12, 2012 3:55 AM To: arslist@ARSLIST.ORG Subject: Overlay and Applications Jose, I'm pleased you agree and don't. Let me tackle the don't: I'm not suggesting there shouldn't be a user interface/admin tool, and there is no reason why that can't remain. However, the current approach of trying to put workflow into a database isn't working because functionality that was available in the 1970s (according to the Wiki page, but 1990 is a more reasonble guess) proves difficult/impossible to implement in AR System. Storing as a script will allow merges in seconds, side by side easy to read diff between two sets of workflow, multiple branches and branches on branches, access over ssh, a pretty web interface and integration to bug tracking systems (JIRA), test driven development - the list goes on. All of which is available for free or with little effort if workflow is stored as scripts, not stored into a database table. The problem with the current model touches so many areas of AR System: When Mid Tier isn't required to store workflow in a memory cache and can simply point the browser at scripts, the "pre-cache" functionality will largely disappear and the product will become vastly less memory hungry and much quicker. Perhaps I should ask, can anyone think of a disadvantage with taking workflow from the schema and into scripts? 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"
