[THIN] Re: Developer Questions
- From: Angus Macdonald <Angus.Macdonald@xxxxxxxxxxxxxxxxxxx>
- To: thin@xxxxxxxxxxxxx
- Date: Wed, 19 Feb 2003 10:19:09 -0000
I agree, in an ideal world HKCU would be the place to go.
Unfortunately this vast monolithic app does occasionally cause enough
trouble in the user profile (it still loads but apps like word will crash
when printing, for example) to cause us to delete the profile. Private .ini
files are far more robust because only my own (impeccably written ;-) )
software accesses them. Should one of my .ini files become irretrievably
corrupted (it's unlikely with a text file - a single byte out of place in
user.dat will kill it but a text file will probably survive) I can delete it
without affecting other apps on the system.
Just my opinion for application in my environment. I'd prefer to use HKCU
all the time but it's just a shade too flaky a basket to keep all my eggs
in.
Best regards
Angus
-----Original Message-----
From: Braebaum, Neil [mailto:Neil.Braebaum@xxxxxxxxxxxxxxxxx]
Sent: 19 February 2003 10:06
To: 'thin@xxxxxxxxxxxxx'
Subject: [THIN] Re: Developer Questions
Comments inline...
> -----Original Message-----
> From: Angus Macdonald [mailto:Angus.Macdonald@xxxxxxxxxxxxxxxxxxx]
> Sent: 19 February 2003 09:57
> To: thin@xxxxxxxxxxxxx
> Subject: [THIN] Re: Developer Questions
>
> 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.
What does it do, though, that "corrupts" the profile hive?
And accepting that, it still doesn't detract from where these things
*should* normally be stored.
> INI files stored in an
> appropriate place save me (and my users) a lot of heartache.
They may do - but surely ini files are just as easily corruptable (and
likely for the same reasons) as HKCU or the data file that is stored to
represent it.
And in your scenario, perhaps you have the luxury of not having to maintain
some persistence in HKCU for the user(s) - but some people may have or need
this.
I guess the point is, ultimately, that some admins may have issues with
needing to occasionally blow away profiles for users - for various reasons.
However, regardless, the answer to the question as to where such settings
should *ideally* live, according to any standard - and to be fair, common
sense, the answer is generically HKCU - which to be fair, IIRC, was the
original question asked.
Neil
> -----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
Other related posts:
