I like the checksum idea. I think it would be fairly easy to implement by BMC. It would also then allow for accurate Modified Dates on objects.
Presently when you import a .def file and overwrite existing, even if a particular object has not changed the Modified Date is updated to the current date/time. A checksum might also provide the ability to track the Create Date as well as the Modified Date of objects. Stephen -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Axton Sent: Wednesday, August 15, 2007 10:54 AM To: arslist@ARSLIST.ORG Subject: Re: AR System Developer Studio Wishlists A checksum that accompanies the gguid (generated based on the object properties and gguid) for the object would be nice as well. This could be used by things like upgrade installers to generate a list of objects that have been changed but retained the original gguid. App installers could then be aware of which objects to update and which ones to include in a report of exceptions. This would probably work very well for things like application patches, but still miss the target for full application upgrades. <dreaming> It would be nice to see BMC get into the practice of providing patches for the applications on a regular basis, in an automated way (not the import def X, arx Y, then def Z). The application versions could then be tags at patch level A, B, C. etc. The patch process could be an executable or arf plugin that simply retrieves a list of available patches from a BMC patch server, generates a list of the patches, then gives you the option of whether or not you want to apply one or all of the available patches. No more upgrades, just staying current with the patches. </dreaming> Axton Grams On 8/15/07, Carey Matthew Black <[EMAIL PROTECTED]> wrote: > David has the idea... but I will add a bit more to it since there > appears to be some interest in the idea.... > > > When an object is first created it would get its own GGUID (Guaranteed > Global Unique ID) from the ARS server at that time and it would be > "unchangeable" while the object exists on the ARS server. (Sure maybe > you could do some funny stuff with a def/xml object file, but who > would want to? Anyway..) And just to be clear.. .the GGUID should be > part of the object and it would be retained if the object is moved > from ARS server 1 to ARS Server 2 during an object Import process. So > the value is only generated during _create_ time for the object. So a > "Save As..." would produce a new object with a new GGUID. But a "Save" > would not change the GGUID. > > > If every object has a GGUID then it would be simple for application > install verification to be automated to. ( Because it would become a > list of GGUID's and a process to verify that all of them exist on the > ARS server.) You could reaname the OOB object to "Didnot use-Foo" and > the application verification stuff would still work. (Extra, or > changed parts are ok. Missing parts are likely indications of > problems.) > > And if you add one more layer to that... where the packing > list/applications keep track of the "verification list" during object > create/deletes then the OOB's would have a standard list and any > customized OOB would have its own list. The lists could be compared > and all missing OOB objects could be identified, and all new objects > could be identified. Yes this stops short of a full Version control > system, but it really should. All I want is identification of objects > and not version control. However once identification is established > then version control becomes much easier to tackle too. > > If every object has a GGUID then Source control systems would be able > to deal with prod/dev/test systems in a sane way. And you could do > things like diff objects that were renamed on dev/test/prod because > the GGUID would tie them together. > > And I am sure there are other gains that can be made once you know > that your looking at an object that was _created_ from server X. > > The GGUID's could be used like "Request ID" are used for data. They > could be the pointers in the objects that point at each other. > (Containers would not need names, they could use shorter, better > indexes, less memory intensive values.) > > And just a bit of an idea about how the GGUID could be generated... > How about a combination for the Support Contract ID and the > Server key where the object was created. It could be encoded/encrypted > so that it looks like garbage to us, but could actually tell BMC quite > a bit about the source of the object if push came to shove. :) Heck it > could even include the date/time that the object was created. ( It has > always struck me as odd that objects do not have a Create date, but > data records do.) > > -- > Carey Matthew Black > Remedy Skilled Professional (RSP) > ARS = Action Request System(Remedy) > > Love, then teach > Solution = People + Process + Tools > Fast, Accurate, Cheap.... Pick two. > > > On 8/15/07, Shellman, David <[EMAIL PROTECTED]> wrote: > > Hugo, > > > > I don't think Carey is asking for the ability to have duplicate names. > > > > Change the name of an Active Link or Filter on development requires that > > you delete the original on production or you wind up with duplicates when > > you move to production with def file. > > > > Using unique GUID would automatically rename the Active Link or Filter and > > not cause it to be duplicated. > > > > Dave > > -------------------------- > > [EMAIL PROTECTED] (Wireless) > > > > ----- Original Message ----- > > From: Action Request System discussion list(ARSList) <arslist@ARSLIST.ORG> > > To: arslist@ARSLIST.ORG <arslist@ARSLIST.ORG> > > Sent: Wed Aug 15 05:08:38 2007 > > Subject: Re: AR System Developer Studio Wishlists > > > > ** Hi Carey, > > > > Quite, a list but I'll just pick one :) > > > > > > On 8/15/07, Carey Matthew Black <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > wrote: > > > > * STOP using names as the unique identifier for an ARS object. An > > internal GUID would go a long way to making the whole development > > process easier. ( Change a name and move it to production and it > > should stomp on the old name of the object. ) > > > > I'm not sure if I understand that. Would you like to have duplicate Active > > Links for example which differ in functionality and GUID? To me that would > > be development hell! > > > > Hugo > > ________________________________________________________________________ _______ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" > ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
