I would still be using HKCU *if* I didn't have to regularly remove users profiles as a result of the actions of a badly behaved app we are tied to. INI files stored in an appropriate place save me (and my users) a lot of heartache. -----Original Message----- From: Braebaum, Neil [mailto:Neil.Braebaum@xxxxxxxxxxxxxxxxx] Sent: 19 February 2003 09:51 To: 'thin@xxxxxxxxxxxxx' Subject: [THIN] Re: Developer Questions Comments inline... > -----Original Message----- > From: Alexander Danilychev [mailto:teknica@xxxxxxxxxxx] > Sent: 19 February 2003 08:53 > To: thin@xxxxxxxxxxxxx > Subject: [THIN] Re: Developer Questions > > Hi, > > Working with Registry to store app. settings can be hindered > by some systems > with elevated security settings. HKCU *should* *always* be readable and writable by the current user, and as what we are discussing is storing per-user application settings, it *is* the correct place, by any standards - given that we're not talking about huge chunks of data - and if we were, HKCU would be the place where configuration settings *pointing* to the huge chunk of data should live. > In some cases you will not > be able to write > or even read portions of Registry if your app did not pass an > audit by IT > security. Not for HKCU - unless there's something quite wrong. > Another issue is synchronization, which is > partially handled by > roaming profiles. Which would seem to be the appropriate method, if you want per-user application settings to be persistent. > This issue with HIVEs is old and will basically depend on > customization > preferences, security concerns and multi-server synchronization. This is exactly why roaming profiles exist. Let's not reinvent the wheel, people. > INI files are easy use and in most cases are OK for > home-grown development. > Besides all similar issues with the Registry, this solution > is even less > secure. Consider encrypting data when dumping your cobfig changes. > > One thing to consider - Active Directory. If handled with care it is > superior to Registry or INI files when scalability and > centralized secure > storage are desired. Do you mean for storing per-user information? Or application information? Either way, you are talking about quite considerable, in-depth customisations, which have far greater implications than merely placing the data in the default place. The profile / registry / HKCU is the *normal* place. Considering other propositions is valid, if the normal scenario isn't tenable - but otherwise merely looks like complication for complication's sake. I say this as somebody who's been doing the directory extension for applications needs, and extending the schema for bespoke applications. It shouldn't be taken lightly, and should be done with *thorough* investigation - not least of which *should* be the question - *where* *should* this data live, and *why*. Neil *********************************************************************** This e-mail and its attachments are intended for the above named recipient(s) only and are confidential and may be privileged. If they have come to you in error you must take no action based on them, nor must you copy or disclose them or any part of their contents to any person or organisation; please notify the sender immediately and delete this e-mail and its attachments from your computer system. Please note that Internet communications are not necessarily secure and may be changed, intercepted or corrupted. We advise that you understand and observe this lack of security when e-mailing us and we will not accept any liability for any such changes, interceptions or corruptions. Although we have taken steps to ensure that this e-mail and its attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. Copyright in this e-mail and attachments created by us belongs to Littlewoods. Littlewoods takes steps to prohibit the transmission of offensive, obscene or discriminatory material. If this message contains inappropriate material please forward the e-mail intact to postmaster@xxxxxxxxxxxxxxxxx and it will be investigated. Statements and opinions contained in this e-mail may not necessarily represent those of Littlewoods. Please note that e-mail communication may be monitored. Registered office: Littlewoods Retail Limited, Sir John Moores Building, 100 Old Hall Street, Liverpool, L70 1AB Registered no: 421258 http://www.littlewoods.com *********************************************************************** ********************************************************* This Week's Sponsor - Neoware Now through March 31, 2003 Neoware is offering a Capio 500/Eon Proven 2100 for $299! Click the link below: http://www.neoware.com/promocp4a/thinnetban.html ********************************************************** For Archives, to Unsubscribe, Subscribe or set Digest or Vacation mode use the below link: http://thethin.net/citrixlist.cfm ********************************************************* This Week's Sponsor - Neoware Now through March 31, 2003 Neoware is offering a Capio 500/Eon Proven 2100 for $299! Click the link below: http://www.neoware.com/promocp4a/thinnetban.html ********************************************************** For Archives, to Unsubscribe, Subscribe or set Digest or Vacation mode use the below link: http://thethin.net/citrixlist.cfm