If you've found this page then you've come up against IE6's privacy features. Namely that cookies are getting blocked and you need them not to be. Perhaps you need frames in your site, perhaps you're into affiliate marketing, but either way the cookies need to make it to your valuable surfer's computer!
At first Google search I was not impressed. If you want to pay around US$100 you can get software to do it for you. There was no way I was going to pay. For starters, I believe almost everything on the web should be for free, and secondly I knew in the back of my mind that I could get my head around an XML schema for less than $100.
So what do we want? A minimal P3P file that just works! When do we want it? Now! Let's face it - we just want our damn cookies to be written to a machine running IE6. I'm not saying privacy isn't important but the firefox/mozilla implementation works just fine for the majority.
So after a bit more searching around I found p3pbook. It's the accompanying website to what looks to be the definitive book on this stuff. They've got lots of examples and this is the most straight forward site I've found on the matter.
If you don't want to wade through the W3C Spec, this example document from the P3PBook shows you all the items of the schema. If you're serious about writing your privacy policy in perfect detail then you will have to check the offical W3C spec to understand the definition of each schema option.
Useful links
http://www.oreillynet.com/pub/a/javascript/2002/10/04/p3p.html
If you've found your post-XPSP2 net performance to have degraded...
Have a look here.
I strongly recommend getting Avast, Ad-Aware SE Personal, and SpywareBlaster to ensure that your "4226" events are actually caused by a legit programme. This tip is particularly useful to BitTorrent users who find that their client is a bit too greedy with the bandwidth.
I strongly recommend getting Avast, Ad-Aware SE Personal, and SpywareBlaster to ensure that your "4226" events are actually caused by a legit programme. This tip is particularly useful to BitTorrent users who find that their client is a bit too greedy with the bandwidth.
.NET posts
From now on, all .NET related posts can be found on my new devlicio.us blog, which can be found here.
Head over and read the main feed - there are some great articles up already.
Head over and read the main feed - there are some great articles up already.
Filtering RSS feeds
The other day I had the idea that being able to filter high-volume RSS feeds would be very useful. I started developing a solution, but tonight I realised I hadn't checked if anyone else had the same idea. Googled and, yes, many others had. Most of them provided simple keyword filters (inclusive) which is, frankly, crap when you put that function in context. Take, for example, MSDN Blogs which generates at least 100 posts per day (less on the weekend). This is the conglomerated feed of all MS tech blogs. To apply a keyword filter to this is useless, since the whole reason I read it is to keep up to date with the Microsoft world. Filtering by such a precise method will cause many interesting topics to go unseen. Same with something like slashdot. In other words, keyword filtering won't cut it with blog browsing.
Filters like date range, author, and tag work well these types of feeds because they are broad. And that's why I chose Feed Rinse because they provide the above, a nice interface, and tiered membership so if you're really serious about feed filtering you can pay for the privilege. Shame I didn't think of it first but at least I now have decent filtered feeds available and I barely had to lift a finger!
Filters like date range, author, and tag work well these types of feeds because they are broad. And that's why I chose Feed Rinse because they provide the above, a nice interface, and tiered membership so if you're really serious about feed filtering you can pay for the privilege. Shame I didn't think of it first but at least I now have decent filtered feeds available and I barely had to lift a finger!
.NET 2.0 get properties vs method calls
When an object is required to provide some simple true/false information about itself one may use a method or a property to return a boolean value.
The question is which is preferable to use? Or does it even matter. I'm sure there are solid design reasons for going either way.
e.g. bool-returning method - IsBlah() - Vs a [possibly readonly] property - IsBlah.
Each will provide its return value depending on the internal state of the object. The syntax will differ, as well as the accessibility (properties can have mutators). What else is different?
One major difference is that in C# a property with both get and set accessors can be inadvertently assigned to via a small typo:
if (obj.State = serverState)...
when you mean,
if (obj.State == serverState)
Obviously this can be avoided by only providing a get accessor, however this can't always be done because some properties need mutators too. Another fix would be to enforce a coding style where the comparison value always appears on the LHS of the comparison - not stable though, as it depends on the developer.
Bill Wagner at SRT Solutions suggests that there are no hard-and-fast rules, but that some simple guidelines may be followed in order to make the decision. This checklist can be found here. Some good points he makes in favour of properties is that they can be serialised, which is definitely becoming more and more important as web services gain popularity. In the context of .NET this also affects objects sent over a Remoting boundary.
Personaly, I prefer to use properties whenever possible as they fit well with the concept that they are exposing an attribute of the object. I definitely agree with Bill in that they should be simple, settable in any order, and should not call outside the object to determine their value. I think it is wise to use private methods to calculate properties based on external data, and then cache that result for when it is required via the property. This can be done when the object is created.
As always, it depends on the particular requirements for the object. If the attribute in question can be safely calculated from internal state at any time in the object's lifetime, then a property is the way to go. If the attribute can only be calculated after the constructor has finished, or if the attribute depends on external data, a calculation method and caching solution, or a re-design/refactoring would be preferable.
The question is which is preferable to use? Or does it even matter. I'm sure there are solid design reasons for going either way.
e.g. bool-returning method - IsBlah() - Vs a [possibly readonly] property - IsBlah.
Each will provide its return value depending on the internal state of the object. The syntax will differ, as well as the accessibility (properties can have mutators). What else is different?
One major difference is that in C# a property with both get and set accessors can be inadvertently assigned to via a small typo:
if (obj.State = serverState)...
when you mean,
if (obj.State == serverState)
Obviously this can be avoided by only providing a get accessor, however this can't always be done because some properties need mutators too. Another fix would be to enforce a coding style where the comparison value always appears on the LHS of the comparison - not stable though, as it depends on the developer.
Bill Wagner at SRT Solutions suggests that there are no hard-and-fast rules, but that some simple guidelines may be followed in order to make the decision. This checklist can be found here. Some good points he makes in favour of properties is that they can be serialised, which is definitely becoming more and more important as web services gain popularity. In the context of .NET this also affects objects sent over a Remoting boundary.
Personaly, I prefer to use properties whenever possible as they fit well with the concept that they are exposing an attribute of the object. I definitely agree with Bill in that they should be simple, settable in any order, and should not call outside the object to determine their value. I think it is wise to use private methods to calculate properties based on external data, and then cache that result for when it is required via the property. This can be done when the object is created.
As always, it depends on the particular requirements for the object. If the attribute in question can be safely calculated from internal state at any time in the object's lifetime, then a property is the way to go. If the attribute can only be calculated after the constructor has finished, or if the attribute depends on external data, a calculation method and caching solution, or a re-design/refactoring would be preferable.
References
Properties vs. Methods @ SRT Solutions
Subscribe to:
Posts (Atom)