Labels are labels, and they are a poor substitute for folders
as all your unread, read and archived mail is munged in together.
A real equivalent of folders would be saved searches
(eg. All unread messages with this label, All starred messages from this domain). That would work, fit nicely in to the overall
design, and promote one of googles strengths. I'd even suggest it, but funny thing about this beta test is there is no obvious way of providing feedback when I find bugs (__NEWLABEL__ anyone?)
Works fine if your key is coming from a system that guarentees uniqueness and a 1:1 relationship and is immutable and will always have the same format and that these constraints will never change in the future.
Unfortunatly, it is a real pain to refactor the db design when it turns out you were not as precient as you thought and the systems outside your database or outside your control evolve in an incompatible way.
'Popularity' is a totally unimportant benchmark. Unfortunately, I tend to find most MySQL users either:
don't know enough about databases to understand why they should be using a different tool
members of the 'I have a hammer, therefore this problem is a nail' sect
people making money from the first two groups
Finding someone using it and can give good technical reasons *why* they are using it is a rare find.
Feel free to substitute Access, Visual Basic, Perl, C, Java, C# or C++, Windows or Bose for MySQL if you like.
There is a standard - 8 spaces. It is what everything defaults to, with good reason.
That said, why use tabs at all? It is just as easy to tell your editor to insert spaces instead of tabs, as it is to set your tabstop to something non standard (and annoy everyone else trying to read your code who doesn't agree with your preferred shift width).
I am very surprised someone liked Python enough to base a language on it, but insists on using tabs for the whitespace. That seems the worst of both worlds.
This *is* Unicode. To deal with Unicode, participants need to agree on an encoding, such as UTF-8, UTF-16, ISO-8859-1, etc. In this case, they have chosen a 7bit clean encoding method that means no changes need to be made to the DNS infrastructure and still usable by people using applications without Unicode domain name support.
% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> ascii = 'www.xn--rksmrgs-5wao1o.se' >>> uni = ascii.decode('idna') >>> print uni.encode('latin1') # Or whatever your terminal uses www.r?ksm?rg?s.se >>> uni.encode('idna') 'www.xn--rksmrgs-5wao1o.se' > >> from encodings import idna >>> idna.nameprep(u'WWW.MICROS\N{LATIN CAPITAL LETTER O WITH DIAERESIS}FT.COM') u'www.micros\xf6ft.com' >> idna.nameprep(u'WWW.MICROS\N{LATIN SMALL LETTER O WITH DIAERESIS}FT.COM') u'www.micros\xf6ft.com'
And yes, Virginia, there is nothing stopping you registing Unicode domain names in.com,.net,.org etc. right now, if you know how to encode them yourself. To the DNS system and most registrars they are just perfectly valid ASCII domain names, with the decoding left to the applications and/or network libraries. Dealing with US keyboards and obsolete browsers is left as an excercise for the reader.
Labels are labels, and they are a poor substitute for folders as all your unread, read and archived mail is munged in together.
A real equivalent of folders would be saved searches (eg. All unread messages with this label, All starred messages from this domain). That would work, fit nicely in to the overall design, and promote one of googles strengths. I'd even suggest it, but funny thing about this beta test is there is no obvious way of providing feedback when I find bugs (__NEWLABEL__ anyone?)
Works fine if your key is coming from a system that guarentees uniqueness and a 1:1 relationship and is immutable and will always have the same format and that these constraints will never change in the future.
Unfortunatly, it is a real pain to refactor the db design when it turns out you were not as precient as you thought and the systems outside your database or outside your control evolve in an incompatible way.
- don't know enough about databases to understand why they should be using a different tool
- members of the 'I have a hammer, therefore this problem is a nail' sect
- people making money from the first two groups
Finding someone using it and can give good technical reasons *why* they are using it is a rare find. Feel free to substitute Access, Visual Basic, Perl, C, Java, C# or C++, Windows or Bose for MySQL if you like.There is a standard - 8 spaces. It is what everything defaults to, with good reason.
That said, why use tabs at all? It is just as easy to tell your editor to insert spaces instead of tabs, as it is to set your tabstop to something non standard (and annoy everyone else trying to read your code who doesn't agree with your preferred shift width).
I am very surprised someone liked Python enough to base a language on it, but insists on using tabs for the whitespace. That seems the worst of both worlds.
This *is* Unicode. To deal with Unicode, participants need to agree on an encoding, such as UTF-8, UTF-16, ISO-8859-1, etc. In this case, they have chosen a 7bit clean encoding method that means no changes need to be made to the DNS infrastructure and still usable by people using applications without Unicode domain name support.
An application that wants to support Unicode domains needs to implement RFC3490 (Internationalized Domain Names in Applications) and RFC3492 (Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)). Nameprep is sort of like an i18n version of lower(), used to compare domains unambiguously. IDNA defines the mechanism for encoding a Unicode domain into the ASCII clean representation. If people want to play, Python 2.3 has this out of the box:
(erk - Python's triple > prompt confuses SlashDot...)And yes, Virginia, there is nothing stopping you registing Unicode domain names in .com, .net, .org etc. right now, if you know how to encode them yourself. To the DNS system and most registrars they are just perfectly valid ASCII domain names, with the decoding left to the applications and/or network libraries. Dealing with US keyboards and obsolete browsers is left as an excercise for the reader.