രചയിതാവ്: സർ ടിം ബെർണേഴ്‌സ്-ലീ, യുആർഐകൾ, യുആർഎലുകൾ, എച്ച്ടിടിപി, എച്ച്ടിഎംഎൽ, വേൾഡ് വൈഡ് വെബ് എന്നിവയുടെ കണ്ടുപിടുത്തക്കാരനും ഡബ്ല്യു3സിയുടെ നിലവിലെ മേധാവിയുമാണ്. 1998-ൽ എഴുതിയ ലേഖനം

ഏത് URI ആണ് "കൂൾ" ആയി കണക്കാക്കുന്നത്?
മാറാത്ത ഒന്ന്.
URI-കൾ എങ്ങനെയാണ് മാറുന്നത്?
URI-കൾ മാറില്ല: ആളുകൾ അവ മാറ്റുന്നു.

സിദ്ധാന്തത്തിൽ, ആളുകൾക്ക് URI-കൾ മാറ്റാൻ (അല്ലെങ്കിൽ പ്രമാണങ്ങളെ പിന്തുണയ്ക്കുന്നത് നിർത്താൻ) ഒരു കാരണവുമില്ല, എന്നാൽ പ്രായോഗികമായി അവയിൽ ദശലക്ഷക്കണക്കിന് ഉണ്ട്.

സിദ്ധാന്തത്തിൽ, ഒരു ഡൊമെയ്‌ൻ നെയിംസ്‌പെയ്‌സിന്റെ നാമമാത്ര ഉടമ യഥാർത്ഥത്തിൽ ഡൊമെയ്‌ൻ നെയിംസ്‌പെയ്‌സിന്റെ ഉടമയാണ്, അതിനാൽ അതിനുള്ളിലെ എല്ലാ യുആർഐകളും. പാപ്പരത്തത്തിന് പുറമെ, ഒരു ഡൊമെയ്ൻ നാമത്തിന്റെ ഉടമയെ പേര് സൂക്ഷിക്കുന്നതിൽ നിന്ന് ഒന്നും തടയുന്നില്ല. സൈദ്ധാന്തികമായി, നിങ്ങളുടെ ഡൊമെയ്ൻ നാമത്തിന് കീഴിലുള്ള URI സ്‌പെയ്‌സ് പൂർണ്ണമായും നിങ്ങളുടെ നിയന്ത്രണത്തിലാണ്, അതിനാൽ നിങ്ങൾക്കത് നിങ്ങൾക്ക് ഇഷ്ടമുള്ളതുപോലെ സ്ഥിരതയുള്ളതാക്കാൻ കഴിയും. ഒരു ഡോക്യുമെന്റ് ഇൻറർനെറ്റിൽ നിന്ന് അപ്രത്യക്ഷമാകുന്നതിനുള്ള ഒരേയൊരു നല്ല കാരണം, ഡൊമെയ്ൻ നാമത്തിന്റെ ഉടമസ്ഥതയിലുള്ള കമ്പനി ബിസിനസ്സിൽ നിന്ന് പുറത്തായതാണ് അല്ലെങ്കിൽ സെർവർ പ്രവർത്തിപ്പിക്കാൻ ഇനി താങ്ങാനാവുന്നില്ല എന്നതാണ്. പിന്നെ എന്തിനാണ് ലോകത്ത് ഇത്രയധികം മിസ്സിംഗ് ലിങ്കുകൾ ഉള്ളത്? ഇതിൽ ചിലത് മുന്നൊരുക്കത്തിന്റെ അഭാവം മാത്രമാണ്. നിങ്ങൾ കേൾക്കാനിടയുള്ള ചില കാരണങ്ങൾ ഇതാ:

ഞങ്ങൾ സൈറ്റ് മികച്ചതാക്കാൻ പുനഃസംഘടിപ്പിച്ചു.

പഴയ യുആർഐകൾക്ക് ഇനി പ്രവർത്തിക്കാനാകില്ലെന്ന് നിങ്ങൾ കരുതുന്നുണ്ടോ? അങ്ങനെയാണെങ്കിൽ, നിങ്ങൾ അവരെ വളരെ മോശമായി തിരഞ്ഞെടുത്തു. അടുത്ത പുനർരൂപകൽപ്പനയ്ക്കായി പുതിയവ സൂക്ഷിക്കുന്നത് പരിഗണിക്കുക.

കാലഹരണപ്പെട്ടവ, രഹസ്യസ്വഭാവമുള്ളവ, ഇപ്പോഴും പ്രസക്തമായവ എന്നിവയുടെ ട്രാക്ക് സൂക്ഷിക്കാൻ കഴിയാത്ത വിധം ഞങ്ങളുടെ പക്കൽ ധാരാളം കാര്യങ്ങൾ ഉണ്ട്, അതിനാൽ എല്ലാം ഓഫ് ചെയ്യുന്നതാണ് നല്ലതെന്ന് ഞങ്ങൾ കരുതി.

എനിക്ക് സഹതപിക്കാനേ കഴിയൂ. ആർക്കൈവൽ മെറ്റീരിയലുകൾ പരസ്യമാക്കുന്നതിന് മുമ്പ് രഹസ്യാത്മകതയ്ക്കായി ഞങ്ങൾ ശ്രദ്ധാപൂർവ്വം പരിശോധിക്കേണ്ട ഒരു കാലഘട്ടത്തിലൂടെയാണ് W3C കടന്നുപോയത്. തീരുമാനം മുൻകൂട്ടി ചിന്തിക്കണം - ഓരോ ഡോക്യുമെന്റിലും നിങ്ങൾ സ്വീകാര്യമായ വായനക്കാരുടെ എണ്ണം, സൃഷ്ടിച്ച തീയതി, കാലഹരണപ്പെടൽ തീയതി എന്നിവ രേഖപ്പെടുത്തുന്നുവെന്ന് ഉറപ്പാക്കുക. ഈ മെറ്റാഡാറ്റ സംരക്ഷിക്കുക.

ശരി, ഞങ്ങൾക്ക് ഫയലുകൾ നീക്കേണ്ടതുണ്ടെന്ന് ഞങ്ങൾ കണ്ടെത്തി...

ഇത് ഏറ്റവും ദയനീയമായ ഒഴികഴിവുകളിൽ ഒന്നാണ്. ഒരു ഒബ്‌ജക്‌റ്റിന്റെ യുആർഐയും ഫയൽ സിസ്റ്റത്തിലെ അതിന്റെ യഥാർത്ഥ സ്ഥാനവും തമ്മിലുള്ള ബന്ധം നിയന്ത്രിക്കാൻ വെബ് സെർവറുകൾ നിങ്ങളെ അനുവദിക്കുമെന്ന് പലർക്കും അറിയില്ല. URI സ്‌പെയ്‌സിനെ ഒരു അമൂർത്ത ഇടമായി സങ്കൽപ്പിക്കുക. എന്നിട്ട് അത് സാക്ഷാത്കരിക്കാൻ നിങ്ങൾ ഉപയോഗിക്കുന്ന യാഥാർത്ഥ്യത്തിലേക്ക് ഒരു മാപ്പിംഗ് ഉണ്ടാക്കുക. തുടർന്ന് ഇത് വെബ് സെർവറിലേക്ക് റിപ്പോർട്ട് ചെയ്യുക. അത് ശരിയാക്കാൻ നിങ്ങൾക്ക് നിങ്ങളുടെ സ്വന്തം സെർവർ സ്നിപ്പറ്റ് പോലും എഴുതാം.

ജോൺ ഇപ്പോൾ ഈ ഫയൽ പരിപാലിക്കുന്നില്ല, ജെയിൻ ഇപ്പോൾ ചെയ്യുന്നു.

യുആർഐയിൽ ജോണിന്റെ പേര് ഉണ്ടായിരുന്നോ? അല്ല, ഫയൽ അവന്റെ ഡയറക്‌ടറിയിൽ മാത്രമായിരുന്നോ? ശരി, ശരി.

ഇതിന് മുമ്പ് ഞങ്ങൾ ഒരു CGI സ്ക്രിപ്റ്റ് ഉപയോഗിച്ചിരുന്നു, എന്നാൽ ഇപ്പോൾ ഞങ്ങൾ ഒരു ബൈനറി പ്രോഗ്രാം ഉപയോഗിക്കുന്നു.

സ്ക്രിപ്റ്റുകൾ സൃഷ്ടിച്ച പേജുകൾ "cgibin" അല്ലെങ്കിൽ "cgi" ഏരിയയിൽ സ്ഥിതിചെയ്യണം എന്ന ഒരു ഭ്രാന്തൻ ആശയം ഉണ്ട്. നിങ്ങളുടെ വെബ് സെർവർ എങ്ങനെ പ്രവർത്തിപ്പിക്കുന്നുവെന്നതിന്റെ മെക്കാനിക്‌സ് ഇത് തുറന്നുകാട്ടുന്നു. നിങ്ങൾ മെക്കാനിസം മാറ്റുന്നു (ഉള്ളടക്കം സംരക്ഷിക്കുമ്പോൾ പോലും), ക്ഷമിക്കണം - നിങ്ങളുടെ എല്ലാ യുആർഐകളും മാറുന്നു.

ഉദാഹരണത്തിന് നാഷണൽ സയൻസ് ഫൗണ്ടേഷൻ (NSF) എടുക്കുക:

NSF ഓൺലൈൻ പ്രമാണങ്ങൾ

http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl

ഡോക്യുമെന്റുകൾ കാണാൻ തുടങ്ങുന്ന ആദ്യ പേജ് കുറച്ച് വർഷങ്ങൾക്കുള്ളിൽ അതേപടി നിലനിൽക്കില്ല. cgi-bin, oldbrowse и pl - ഇതെല്ലാം ഞങ്ങൾ ഇപ്പോൾ എങ്ങനെ ചെയ്യുന്നു എന്നതിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ നൽകുന്നു. ഒരു ഡോക്യുമെന്റിനായി തിരയാൻ നിങ്ങൾ പേജ് ഉപയോഗിക്കുകയാണെങ്കിൽ, നിങ്ങൾക്ക് ലഭിക്കുന്ന ആദ്യ ഫലം ഒരുപോലെ മോശമാണ്:

ക്രിപ്‌റ്റോളജി, കോഡിംഗ് തിയറി എന്നിവയെക്കുറിച്ചുള്ള വർക്കിംഗ് ഗ്രൂപ്പിന്റെ റിപ്പോർട്ട്

http://www.nsf.gov/cgi-bin/getpub?nsf9814

പ്രമാണ സൂചിക പേജിനായി, html പ്രമാണം തന്നെ വളരെ മികച്ചതായി കാണപ്പെടുന്നുണ്ടെങ്കിലും:

http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm

പഴയ 1998-ലെ ഡോക്യുമെന്റ് ക്ലാസിഫിക്കേഷൻ സ്കീം പ്രാബല്യത്തിൽ ഉണ്ടെന്ന് ഭാവിയിലെ ഏതൊരു ആർക്കൈവൽ സേവനത്തിനും ഇവിടെ പബ്ബുകൾ/1998 തലക്കെട്ട് ഒരു നല്ല സൂചന നൽകും. 2098-ൽ ഡോക്യുമെന്റ് നമ്പറുകൾ വ്യത്യസ്തമായി കാണപ്പെടുമെങ്കിലും, ഈ URI ഇപ്പോഴും സാധുതയുള്ളതായിരിക്കുമെന്നും ആർക്കൈവ് പരിപാലിക്കുന്ന NSF അല്ലെങ്കിൽ മറ്റേതെങ്കിലും ഓർഗനൈസേഷനുമായി ഇടപെടില്ലെന്നും ഞാൻ കരുതുന്നു.

URL-കൾ സ്ഥിരതയുള്ളതായിരിക്കണമെന്ന് ഞാൻ കരുതിയിരുന്നില്ല - URN-കൾ ഉണ്ടായിരുന്നു.

URN സംവാദത്തിന്റെ ഏറ്റവും മോശമായ പാർശ്വഫലങ്ങളിൽ ഒന്നായിരിക്കാം ഇത്. കൂടുതൽ ശാശ്വതമായ നെയിംസ്‌പെയ്‌സിലേക്കുള്ള ഗവേഷണം കാരണം, "URN-കൾ അതെല്ലാം ശരിയാക്കും" എന്നതിനാൽ, തൂങ്ങിക്കിടക്കുന്ന ലിങ്കുകളെ കുറിച്ച് അവർ അശ്രദ്ധരായേക്കാം എന്ന് ചിലർ കരുതുന്നു. നിങ്ങൾ ഈ ആളുകളിൽ ഒരാളാണെങ്കിൽ, ഞാൻ നിങ്ങളെ നിരാശപ്പെടുത്തട്ടെ.

ഞാൻ കണ്ട മിക്ക URN സ്കീമുകളും ഒരു അതോറിറ്റി ഐഡന്റിഫയർ പോലെയാണ്, അതിന് ശേഷം നിങ്ങൾ തിരഞ്ഞെടുക്കുന്ന തീയതിയും ഒരു സ്‌ട്രിംഗും അല്ലെങ്കിൽ നിങ്ങൾ തിരഞ്ഞെടുക്കുന്ന ഒരു സ്‌ട്രിംഗും. ഇത് ഒരു HTTP URI-യോട് വളരെ സാമ്യമുള്ളതാണ്. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, നിങ്ങളുടെ സ്ഥാപനത്തിന് ദീർഘകാല URN-കൾ സൃഷ്ടിക്കാൻ കഴിയുമെന്ന് നിങ്ങൾ കരുതുന്നുവെങ്കിൽ, നിങ്ങളുടെ HTTP URI-കൾക്കായി അവ ഉപയോഗിച്ച് അത് ഇപ്പോൾ തെളിയിക്കുക. HTTP-യിൽ തന്നെ നിങ്ങളുടെ URI-യെ അസ്ഥിരമാക്കുന്ന ഒന്നും തന്നെയില്ല. നിങ്ങളുടെ സ്ഥാപനം മാത്രം. നിലവിലെ ഫയൽ നാമത്തിലേക്ക് ഡോക്യുമെന്റ് URN മാപ്പ് ചെയ്യുന്ന ഒരു ഡാറ്റാബേസ് സൃഷ്‌ടിക്കുക, കൂടാതെ ഫയലുകൾ യഥാർത്ഥത്തിൽ വീണ്ടെടുക്കാൻ വെബ് സെർവറിനെ അത് ഉപയോഗിക്കാൻ അനുവദിക്കുക.

നിങ്ങൾ ഈ ഘട്ടത്തിൽ എത്തിയിട്ടുണ്ടെങ്കിൽ, ചില സോഫ്‌റ്റ്‌വെയർ വികസിപ്പിക്കുന്നതിന് നിങ്ങൾക്ക് സമയവും പണവും കണക്ഷനുകളും ഇല്ലെങ്കിൽ, നിങ്ങൾക്ക് ഇനിപ്പറയുന്ന ഒഴികഴിവ് പ്രസ്താവിക്കാം:

ഞങ്ങൾ ആഗ്രഹിച്ചു, പക്ഷേ ഞങ്ങൾക്ക് ശരിയായ ഉപകരണങ്ങൾ ഇല്ല.

എന്നാൽ നിങ്ങൾക്ക് ഇതിൽ സഹതപിക്കാം. ഞാൻ പൂർണ്ണമായും സമ്മതിക്കുന്നു. നിങ്ങൾ ചെയ്യേണ്ടത്, സ്ഥിരമായ യുആർഐ തൽക്ഷണം പാഴ്‌സ് ചെയ്യാൻ വെബ് സെർവറിനെ നിർബന്ധിക്കുകയും നിങ്ങളുടെ നിലവിലെ ഭ്രാന്തൻ ഫയൽ സിസ്റ്റത്തിൽ നിലവിൽ എവിടെ സംഭരിച്ചിട്ടുണ്ടോ അവിടെയെല്ലാം ഫയൽ തിരികെ നൽകുകയും ചെയ്യുക എന്നതാണ്. നിങ്ങൾ എല്ലാ യുആർഐകളും ഒരു ഫയലിൽ ഒരു ചെക്ക് ആയി സംഭരിക്കാനും ഡാറ്റാബേസ് എല്ലായ്‌പ്പോഴും അപ് ടു ഡേറ്റ് ആയി സൂക്ഷിക്കാനും ആഗ്രഹിക്കുന്നു. ഒരേ ഡോക്യുമെന്റിന്റെ വ്യത്യസ്‌ത പതിപ്പുകളും വിവർത്തനങ്ങളും തമ്മിലുള്ള ബന്ധം സംരക്ഷിക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നു, കൂടാതെ ആകസ്‌മികമായ ഒരു പിശക് കാരണം ഫയൽ കേടായിട്ടില്ലെന്ന് ഉറപ്പാക്കാൻ ഒരു സ്വതന്ത്ര ചെക്ക്‌സം റെക്കോർഡ് നിലനിർത്തുകയും വേണം. വെബ് സെർവറുകൾ ഈ ഫീച്ചറുകളുള്ള ബോക്സിൽ നിന്ന് പുറത്തുവരില്ല. നിങ്ങൾക്ക് ഒരു പുതിയ പ്രമാണം സൃഷ്ടിക്കാൻ താൽപ്പര്യപ്പെടുമ്പോൾ, ഒരു URI വ്യക്തമാക്കാൻ നിങ്ങളുടെ എഡിറ്റർ നിങ്ങളോട് ആവശ്യപ്പെടുന്നു.

URI സ്‌പെയ്‌സിൽ ഉടമസ്ഥാവകാശം, ഡോക്യുമെന്റ് ആക്‌സസ്, ആർക്കൈവ് ലെവൽ സുരക്ഷ മുതലായവ മാറ്റാൻ നിങ്ങൾക്ക് കഴിയണം.

എല്ലാം വളരെ മോശമാണ്. എന്നാൽ ഞങ്ങൾ സാഹചര്യം ശരിയാക്കും. W3C-യിൽ, പതിപ്പുകൾ ട്രാക്ക് ചെയ്യുന്ന Jigedit (Jigsaw എഡിറ്റിംഗ് സെർവർ) പ്രവർത്തനക്ഷമത ഞങ്ങൾ ഉപയോഗിക്കുന്നു, കൂടാതെ ഞങ്ങൾ ഡോക്യുമെന്റ് സൃഷ്‌ടി സ്‌ക്രിപ്‌റ്റുകൾ പരീക്ഷിക്കുകയും ചെയ്യുന്നു. നിങ്ങൾ ഉപകരണങ്ങൾ, സെർവറുകൾ, ക്ലയന്റുകൾ എന്നിവ വികസിപ്പിക്കുകയാണെങ്കിൽ, ഈ പ്രശ്നം ശ്രദ്ധിക്കുക!

ഈ ഒഴികഴിവ് ഇതുൾപ്പെടെ നിരവധി W3C പേജുകൾക്കും ബാധകമാണ്: അതിനാൽ ഞാൻ പറയുന്നതുപോലെ ചെയ്യുക, ഞാൻ ചെയ്യുന്നതുപോലെയല്ല.

ഞാൻ എന്തിന് ശ്രദ്ധിക്കണം?

നിങ്ങളുടെ സെർവറിലെ യുആർഐ മാറ്റുമ്പോൾ, പഴയ യുആർഐയിലേക്ക് ആർക്കൊക്കെ ലിങ്കുകൾ ഉണ്ടായിരിക്കുമെന്ന് നിങ്ങൾക്ക് ഒരിക്കലും പറയാനാകില്ല. ഇവ സാധാരണ വെബ് പേജുകളിൽ നിന്നുള്ള ലിങ്കുകളാകാം. നിങ്ങളുടെ പേജ് ബുക്ക്മാർക്ക് ചെയ്യുക. ഒരു സുഹൃത്തിന് എഴുതിയ കത്തിന്റെ മാർജിനുകളിൽ URI ചുരുട്ടിയിരിക്കാം.

ആരെങ്കിലും ഒരു ലിങ്ക് പിന്തുടരുകയും അത് തകരാറിലാകുകയും ചെയ്യുമ്പോൾ, അവർക്ക് സാധാരണയായി സെർവർ ഉടമയിലുള്ള വിശ്വാസം നഷ്ടപ്പെടും. ലക്ഷ്യത്തിലെത്താൻ കഴിയാതെ മാനസികമായും ശാരീരികമായും അയാൾ നിരാശനാണ്.

തകർന്ന ലിങ്കുകളെക്കുറിച്ച് ധാരാളം ആളുകൾ നിരന്തരം പരാതിപ്പെടുന്നു, കേടുപാടുകൾ വ്യക്തമാണെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു. പ്രമാണം അപ്രത്യക്ഷമായ സെർവറിന്റെ മെയിന്റനർക്കുള്ള പ്രശസ്തി കേടുപാടുകൾ വ്യക്തമാണെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു.

അപ്പോൾ ഞാൻ എന്ത് ചെയ്യണം? URI ഡിസൈൻ

2 വർഷത്തിനുള്ളിൽ, 20 വർഷത്തിനുള്ളിൽ, 200 വർഷത്തിനുള്ളിൽ ഉപയോഗിക്കാവുന്ന യുആർഐകൾ അനുവദിക്കേണ്ടത് വെബ്മാസ്റ്ററുടെ ഉത്തരവാദിത്തമാണ്. ഇതിന് ചിന്തയും സംഘാടനവും നിശ്ചയദാർഢ്യവും ആവശ്യമാണ്.

അവയിലെ എന്തെങ്കിലും വിവരങ്ങൾ മാറുകയാണെങ്കിൽ URI-കൾ മാറുന്നു. നിങ്ങൾ അവ എങ്ങനെ രൂപകൽപ്പന ചെയ്യുന്നു എന്നത് വളരെ പ്രധാനമാണ്. (എന്താണ്, URI ഡിസൈൻ? എനിക്ക് URI ഡിസൈൻ ചെയ്യേണ്ടതുണ്ടോ? അതെ, നിങ്ങൾ അതിനെക്കുറിച്ച് ചിന്തിക്കണം). അടിസ്ഥാനപരമായി ഡിസൈൻ എന്നാൽ URI-യിലെ ഏതെങ്കിലും വിവരങ്ങൾ ഉപേക്ഷിക്കുക എന്നാണ് അർത്ഥമാക്കുന്നത്.

ഡോക്യുമെന്റ് സൃഷ്ടിച്ച തീയതി - യുആർഐ ഇഷ്യൂ ചെയ്ത തീയതി - ഒരിക്കലും മാറാത്ത ഒന്നാണ്. പഴയ സിസ്റ്റം ഉപയോഗിക്കുന്നതിൽ നിന്ന് പുതിയ സിസ്റ്റം ഉപയോഗിക്കുന്ന അന്വേഷണങ്ങളെ വേർതിരിക്കുന്നതിന് ഇത് വളരെ ഉപയോഗപ്രദമാണ്. URI ഉപയോഗിച്ച് തുടങ്ങാൻ പറ്റിയ സ്ഥലമാണിത്. ഒരു പ്രമാണം കാലഹരണപ്പെട്ടതാണെങ്കിൽ, ഭാവിയിൽ പ്രമാണം പ്രസക്തമാകുമെങ്കിലും, ഇതൊരു നല്ല തുടക്കമാണ്.

മനഃപൂർവ്വം "ഏറ്റവും പുതിയ" പതിപ്പായ ഒരു പേജ് മാത്രമാണ് അപവാദം, ഉദാഹരണത്തിന് മുഴുവൻ സ്ഥാപനത്തിനും അല്ലെങ്കിൽ അതിന്റെ വലിയ ഭാഗത്തിനും.

http://www.pathfinder.com/money/moneydaily/latest/

മണി മാസികയിലെ ഏറ്റവും പുതിയ മണി ഡെയ്‌ലി കോളമാണിത്. ഈ യു‌ആർ‌ഐയിൽ തീയതി ആവശ്യമില്ലാത്തതിന്റെ പ്രധാന കാരണം ലോഗിനെ മറികടക്കുന്ന യു‌ആർ‌ഐ സംഭരിക്കാൻ ഒരു കാരണവുമില്ല എന്നതാണ്. മണി ഇല്ലാതാകുന്നതോടെ മണി ഡെയ്‌ലി എന്ന ആശയം ഇല്ലാതാകും. നിങ്ങൾ ഉള്ളടക്കത്തിലേക്ക് ലിങ്ക് ചെയ്യാൻ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ആർക്കൈവുകളിൽ അതിലേക്ക് പ്രത്യേകം ലിങ്ക് ചെയ്യണം:

http://www.pathfinder.com/money/moneydaily/1998/981212.moneyonline.html

(നല്ലതായി തോന്നുന്നു. pathfinder.com-ന്റെ ജീവിതത്തിലുടനീളം "പണം" എന്നത് ഒരേ അർത്ഥമാക്കുമെന്ന് അനുമാനിക്കുന്നു. ഒരു ഡ്യൂപ്ലിക്കേറ്റ് "98" ഉം അനാവശ്യമായ ".html" ഉം ഉണ്ട്, അല്ലാത്തപക്ഷം ഒരു ശക്തമായ URI പോലെ തോന്നുന്നു.

എന്ത് മാറ്റിവെക്കണം

എല്ലാം! സൃഷ്‌ടിച്ച തീയതി കൂടാതെ, യുആർഐയിൽ എന്തെങ്കിലും വിവരങ്ങൾ ഇടുന്നത് ഒരു തരത്തിലല്ലെങ്കിൽ മറ്റൊരു തരത്തിൽ പ്രശ്‌നങ്ങൾ ചോദിക്കുന്നു.

• രചയിതാവിന്റെ പേര്. പുതിയ പതിപ്പുകൾ ലഭ്യമാകുമ്പോൾ കർത്തൃത്വം മാറിയേക്കാം. ആളുകൾ സംഘടനകൾ ഉപേക്ഷിച്ച് മറ്റുള്ളവർക്ക് കാര്യങ്ങൾ കൈമാറുന്നു.
• വിഷയം. ഇതു വളരെ കഠിനമാണ്. ഇത് എല്ലായ്പ്പോഴും ആദ്യം നന്നായി കാണപ്പെടുന്നു, പക്ഷേ അതിശയകരമാം വിധം വേഗത്തിൽ മാറുന്നു. ഞാൻ ഇതിനെക്കുറിച്ച് കൂടുതൽ ചുവടെ സംസാരിക്കും.
• നില. "പഴയ", "ഡ്രാഫ്റ്റ്" തുടങ്ങിയ ഡയറക്‌ടറികൾ, "ഏറ്റവും പുതിയത്", "കൂൾ" എന്നിവ പരാമർശിക്കേണ്ടതില്ല, എല്ലാ ഫയൽ സിസ്റ്റങ്ങളിലും ദൃശ്യമാകും. പ്രമാണങ്ങൾ നില മാറ്റുന്നു - അല്ലാത്തപക്ഷം ഡ്രാഫ്റ്റുകൾ സൃഷ്ടിക്കുന്നതിൽ അർത്ഥമില്ല. ഒരു പ്രമാണത്തിന്റെ ഏറ്റവും പുതിയ പതിപ്പിന് അതിന്റെ നില പരിഗണിക്കാതെ തന്നെ സ്ഥിരമായ ഒരു ഐഡന്റിഫയർ ആവശ്യമാണ്. പേരിന് പുറത്ത് സ്റ്റാറ്റസ് സൂക്ഷിക്കുക.
• പ്രവേശനം. W3C-യിൽ, ജീവനക്കാർക്കും അംഗങ്ങൾക്കും പൊതുജനങ്ങൾക്കുമായി ഞങ്ങൾ സൈറ്റിനെ വിഭാഗങ്ങളായി തിരിച്ചിട്ടുണ്ട്. ഇത് നന്നായി തോന്നുന്നു, പക്ഷേ തീർച്ചയായും, പ്രമാണങ്ങൾ സ്റ്റാഫിൽ നിന്നുള്ള ടീം ആശയങ്ങളായി ആരംഭിക്കുന്നു, അംഗങ്ങളുമായി ചർച്ചചെയ്യുന്നു, തുടർന്ന് പൊതുവിജ്ഞാനമായി മാറുന്നു. ഓരോ തവണയും വിശാലമായ ചർച്ചകൾക്കായി ഒരു പ്രമാണം തുറക്കുമ്പോൾ, അതിലേക്കുള്ള പഴയ ലിങ്കുകളെല്ലാം തകർന്നാൽ അത് ശരിക്കും ലജ്ജാകരമാണ്! ഇപ്പോൾ ഞങ്ങൾ ഒരു ലളിതമായ തീയതി കോഡിലേക്ക് പോകുന്നു.
• ഫയൽ വിപുലീകരണം. വളരെ സാധാരണമായ ഒരു സംഭവം. "cgi", ".html" പോലും ഭാവിയിൽ മാറും. 20 വർഷമായി നിങ്ങൾ ഈ പേജിനായി HTML ഉപയോഗിക്കുന്നില്ലായിരിക്കാം, എന്നാൽ അതിലേക്കുള്ള ഇന്നത്തെ ലിങ്കുകൾ ഇപ്പോഴും പ്രവർത്തിക്കും. W3C സൈറ്റിലെ കാനോനിക്കൽ ലിങ്കുകൾ വിപുലീകരണം ഉപയോഗിക്കുന്നില്ല (അത് എങ്ങനെ ചെയ്തു).
• സോഫ്റ്റ്വെയർ മെക്കാനിസങ്ങൾ. URI-യിൽ, "cgi", "exec" എന്നിവയും "ഞങ്ങൾ ഉപയോഗിക്കുന്ന സോഫ്റ്റ്‌വെയർ നോക്കുക" എന്ന് അലറുന്ന മറ്റ് പദങ്ങളും നോക്കുക. പേൾ CGI സ്ക്രിപ്റ്റുകൾ എഴുതാൻ ആരെങ്കിലും അവരുടെ ജീവിതം മുഴുവൻ ചെലവഴിക്കാൻ ആഗ്രഹിക്കുന്നുണ്ടോ? ഇല്ലേ? തുടർന്ന് .pl എക്സ്റ്റൻഷൻ നീക്കം ചെയ്യുക. ഇത് എങ്ങനെ ചെയ്യാമെന്നതിനെക്കുറിച്ചുള്ള സെർവർ മാനുവൽ വായിക്കുക.
• ഡിസ്കിന്റെ പേര്. വരിക! പക്ഷെ ഞാൻ ഇത് കണ്ടിട്ടുണ്ട്.

അതിനാൽ ഞങ്ങളുടെ സൈറ്റിൽ നിന്നുള്ള മികച്ച ഉദാഹരണം ലളിതമാണ്

http://www.w3.org/1998/12/01/chairs

... W3C ചെയർസ് മീറ്റിംഗിന്റെ മിനിറ്റുകളെക്കുറിച്ചുള്ള റിപ്പോർട്ട്.

വിഷയങ്ങളും വിഷയമനുസരിച്ചുള്ള വർഗ്ഗീകരണവും

ഈ അപകടത്തെക്കുറിച്ച് ഞാൻ കൂടുതൽ വിശദമായി പറയാം, കാരണം ഇത് ഒഴിവാക്കാൻ ഏറ്റവും ബുദ്ധിമുട്ടുള്ള കാര്യങ്ങളിൽ ഒന്നാണ്. സാധാരണഗതിയിൽ, നിങ്ങളുടെ ഡോക്യുമെന്റുകൾ അവർ ചെയ്യുന്ന ജോലി അനുസരിച്ച് തരം തിരിക്കുമ്പോൾ വിഷയങ്ങൾ URI-കളിൽ അവസാനിക്കും. എന്നാൽ ഈ തകർച്ച കാലക്രമേണ മാറും. പ്രദേശങ്ങളുടെ പേരുകൾ മാറും. W3C-യിൽ, വിഭാഗത്തിന്റെ യഥാർത്ഥ ഉള്ളടക്കം പ്രതിഫലിപ്പിക്കുന്നതിന് MarkUP-നെ Markup ആയും HTML-ലേക്ക് മാറ്റാൻ ഞങ്ങൾ ആഗ്രഹിച്ചു. കൂടാതെ, പലപ്പോഴും ഒരു ഫ്ലാറ്റ് നെയിംസ്പേസ് ഉണ്ട്. 100 വർഷത്തിനുള്ളിൽ, നിങ്ങൾക്ക് ഒന്നും വീണ്ടും ഉപയോഗിക്കാൻ താൽപ്പര്യമില്ലെന്ന് ഉറപ്പാണോ? ഞങ്ങളുടെ ഹ്രസ്വ ജീവിതത്തിൽ "ചരിത്രം", "സ്റ്റൈൽ ഷീറ്റുകൾ" എന്നിവ പുനരുപയോഗിക്കാൻ ഞങ്ങൾ ഇതിനകം ആഗ്രഹിച്ചു.

ഒരു വെബ്‌സൈറ്റ് ഓർഗനൈസുചെയ്യുന്നതിനുള്ള ഒരു പ്രലോഭനപരമായ മാർഗമാണിത് - കൂടാതെ മുഴുവൻ വെബും ഉൾപ്പെടെ എന്തും സംഘടിപ്പിക്കുന്നതിനുള്ള ഒരു യഥാർത്ഥ പ്രലോഭിപ്പിക്കുന്ന മാർഗമാണിത്. ഇതൊരു മികച്ച ഇടക്കാല പരിഹാരമാണ്, പക്ഷേ ദീർഘകാലാടിസ്ഥാനത്തിൽ ഗുരുതരമായ പോരായ്മകളുണ്ട്.

കാരണത്തിന്റെ ഒരു ഭാഗം അർത്ഥത്തിന്റെ തത്ത്വചിന്തയിലാണ്. ഒരു ഭാഷയിലെ ഓരോ പദവും ക്ലസ്റ്ററിങ്ങിനുള്ള സാധ്യതയുള്ള ലക്ഷ്യമാണ്, ഓരോ വ്യക്തിക്കും അതിന്റെ അർത്ഥത്തെക്കുറിച്ച് വ്യത്യസ്തമായ ആശയങ്ങൾ ഉണ്ടായിരിക്കാം. എന്റിറ്റികൾ തമ്മിലുള്ള ബന്ധങ്ങൾ ഒരു ട്രീ എന്നതിനേക്കാൾ ഒരു വെബ് പോലെയായതിനാൽ, വെബിനോട് യോജിക്കുന്നവർ പോലും ട്രീയുടെ മറ്റൊരു പ്രതിനിധാനം തിരഞ്ഞെടുത്തേക്കാം. ഒരു പൊതു പരിഹാരമെന്ന നിലയിൽ ശ്രേണിപരമായ വർഗ്ഗീകരണത്തിന്റെ അപകടങ്ങളെക്കുറിച്ചുള്ള എന്റെ (പലപ്പോഴും ആവർത്തിച്ചുള്ള) പൊതുവായ നിരീക്ഷണങ്ങളാണിവ.

വാസ്തവത്തിൽ, നിങ്ങൾ ഒരു യുആർഐയിൽ ഒരു വിഷയത്തിന്റെ പേര് ഉപയോഗിക്കുമ്പോൾ, നിങ്ങൾ സ്വയം ഏതെങ്കിലും തരത്തിലുള്ള വർഗ്ഗീകരണത്തിന് വിധേയമാകുന്നു. ഒരുപക്ഷേ ഭാവിയിൽ നിങ്ങൾ മറ്റൊരു ഓപ്ഷൻ തിരഞ്ഞെടുക്കും. അപ്പോൾ യുആർഐ ലംഘനത്തിന് വിധേയമാകും.

ഒരു യുആർഐയുടെ ഭാഗമായി ഒരു സബ്ജക്ട് ഏരിയ ഉപയോഗിക്കുന്നതിനുള്ള കാരണം, യുആർഐ സ്‌പെയ്‌സിന്റെ ഉപവിഭാഗങ്ങളുടെ ഉത്തരവാദിത്തം സാധാരണയായി ഏൽപ്പിക്കപ്പെടുന്നു, തുടർന്ന് നിങ്ങൾക്ക് ആ സബ്‌സ്‌പെയ്‌സിന്റെ ഉത്തരവാദിത്തമുള്ള ഓർഗനൈസേഷണൽ ബോഡി - ഡിപ്പാർട്ട്‌മെന്റ്, ഗ്രൂപ്പ് അല്ലെങ്കിൽ മറ്റെന്തെങ്കിലും - പേര് ആവശ്യമാണ്. ഇത് ഒരു ഓർഗനൈസേഷണൽ ഘടനയുമായി ബന്ധപ്പെട്ട ഒരു URI ആണ്. കൂടുതൽ (ഇടത്) URI ഒരു തീയതിയാൽ പരിരക്ഷിച്ചാൽ മാത്രമേ ഇത് സുരക്ഷിതമാകൂ: 1998/ചിത്രങ്ങൾ നിങ്ങളുടെ സെർവറിന് അർത്ഥമാക്കുന്നത് "1998-ൽ ഞങ്ങൾ ചിത്രങ്ങളോടൊപ്പം എന്താണ് ഉദ്ദേശിച്ചത്" എന്നതിലുപരി "1998-ൽ ഞങ്ങൾ ഇപ്പോൾ ചിത്രങ്ങൾ എന്ന് വിളിക്കുന്നത് എന്തായിരുന്നു."

ഡൊമെയ്ൻ നാമം മറക്കരുത്

ഇത് URI-യിലെ പാതയ്ക്ക് മാത്രമല്ല, സെർവർ നാമത്തിനും ബാധകമാണെന്ന് ഓർമ്മിക്കുക. വ്യത്യസ്ത കാര്യങ്ങൾക്കായി നിങ്ങൾക്ക് പ്രത്യേക സെർവറുകൾ ഉണ്ടെങ്കിൽ, നിരവധി ലിങ്കുകൾ നശിപ്പിക്കാതെ ഈ വിഭജനം മാറ്റാൻ കഴിയില്ലെന്ന് ഓർമ്മിക്കുക. ചില ക്ലാസിക് "നാം ഇന്ന് ഉപയോഗിക്കുന്ന സോഫ്‌റ്റ്‌വെയറിലേക്ക് നോക്കൂ" തെറ്റുകൾ "cgi.pathfinder.com", "secure", "lists.w3.org" എന്നീ ഡൊമെയ്‌ൻ നാമങ്ങളാണ്. സെർവർ അഡ്മിനിസ്ട്രേഷൻ എളുപ്പമാക്കുന്നതിനാണ് അവ രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്. ഒരു ഡൊമെയ്ൻ നിങ്ങളുടെ കമ്പനിയിലെ ഒരു ഡിവിഷനെ പ്രതിനിധീകരിക്കുന്നുണ്ടോ, ഒരു ഡോക്യുമെന്റ് സ്റ്റാറ്റസ്, ഒരു ആക്സസ് ലെവൽ, അല്ലെങ്കിൽ സെക്യൂരിറ്റി ലെവൽ എന്നിവ പരിഗണിക്കാതെ തന്നെ, ഒന്നിലധികം ഡോക്യുമെന്റ് തരങ്ങൾക്കായി ഒന്നിലധികം ഡൊമെയ്ൻ നാമങ്ങൾ ഉപയോഗിക്കുന്നതിന് മുമ്പ് വളരെ ശ്രദ്ധാലുവായിരിക്കുക. റീഡയറക്‌ഷനും പ്രോക്‌സിംഗും ഉപയോഗിച്ച് നിങ്ങൾക്ക് ദൃശ്യമാകുന്ന ഒരൊറ്റ വെബ് സെർവറിനുള്ളിൽ ഒന്നിലധികം വെബ് സെർവറുകൾ മറയ്‌ക്കാൻ കഴിയുമെന്ന് ഓർക്കുക.

ഓ, നിങ്ങളുടെ ഡൊമെയ്ൻ നാമത്തെക്കുറിച്ചും ചിന്തിക്കുക. നിങ്ങൾ ഉൽപ്പന്ന ലൈനുകൾ മാറ്റി സോപ്പ് നിർമ്മിക്കുന്നത് നിർത്തിയതിന് ശേഷം നിങ്ങളെ soap.com എന്ന് വിളിക്കാൻ താൽപ്പര്യമില്ല (ഇപ്പോൾ soap.com സ്വന്തമാക്കിയവരോട് ക്ഷമിക്കുക).

തീരുമാനം

ഒരു URI 2, 20, 200, അല്ലെങ്കിൽ 2000 വർഷത്തേക്ക് പോലും സൂക്ഷിക്കുക എന്നത് തോന്നുന്നത്ര എളുപ്പമല്ല. എന്നിരുന്നാലും, ഇൻറർനെറ്റിൽ ഉടനീളം, വെബ്‌മാസ്റ്റർമാർ തീരുമാനങ്ങൾ എടുക്കുന്നു, അത് ഭാവിയിൽ ഈ ടാസ്‌ക്ക് തങ്ങളെത്തന്നെ ബുദ്ധിമുട്ടാക്കുന്നു. മിക്കപ്പോഴും ഇത് കാരണം അവർ ടൂളുകൾ ഉപയോഗിക്കുന്നതുകൊണ്ടാണ്, ഇപ്പോൾ ഏറ്റവും മികച്ച സൈറ്റ് അവതരിപ്പിക്കുക എന്നതാണ് അവരുടെ ജോലി - മാത്രമല്ല എല്ലാം മാറുമ്പോൾ ലിങ്കുകൾക്ക് എന്ത് സംഭവിക്കുമെന്ന് ആരും വിലയിരുത്തിയിട്ടില്ല. എന്നിരുന്നാലും, ഇവിടെ പ്രധാന കാര്യം, പലതും പലതും മാറാൻ കഴിയും, നിങ്ങളുടെ URI-കൾക്ക് അതുപോലെ തന്നെ തുടരാനും കഴിയും. നിങ്ങൾ അവ എങ്ങനെ സൃഷ്ടിക്കുന്നു എന്ന് ചിന്തിക്കുമ്പോൾ മാത്രമേ ഇത് സാധ്യമാകൂ.

ഇതും കാണുക:

• ഇതേ വിഷയത്തിൽ ജേക്കബ് നീൽസന്റെ അപവാദം

കൂട്ടിച്ചേർക്കലുകൾ

ഫയൽ എക്സ്റ്റൻഷനുകൾ എങ്ങനെ നീക്കം ചെയ്യാം...

...നിലവിലെ ഫയൽ അധിഷ്ഠിത വെബ് സെർവറിലെ URI-ൽ നിന്നോ?

നിങ്ങൾ അപ്പാച്ചെ ഉപയോഗിക്കുകയാണെങ്കിൽ, ഉദാഹരണത്തിന്, ഉള്ളടക്കം ചർച്ച ചെയ്യുന്നതിനായി നിങ്ങൾക്കത് കോൺഫിഗർ ചെയ്യാം. ഫയൽ എക്സ്റ്റൻഷൻ (ഉദാ. .png) ഒരു ഫയലിലേക്ക് സംരക്ഷിക്കുക (ഉദാ. mydog.png), എന്നാൽ ഇത് കൂടാതെ നിങ്ങൾക്ക് ഒരു വെബ് റിസോഴ്സിലേക്ക് ലിങ്ക് ചെയ്യാൻ കഴിയും. അപ്പാച്ചെ ആ പേരിലുള്ള എല്ലാ ഫയലുകൾക്കും ഏതെങ്കിലും വിപുലീകരണത്തിനുമായി ഡയറക്‌ടറി പരിശോധിക്കുന്നു, കൂടാതെ സെറ്റിൽ നിന്ന് ഏറ്റവും മികച്ചത് തിരഞ്ഞെടുക്കാം (ഉദാഹരണത്തിന്, GIF, PNG). വ്യത്യസ്‌ത ഡയറക്‌ടറികളിൽ വ്യത്യസ്‌ത തരം ഫയലുകൾ ഇടേണ്ട ആവശ്യമില്ല, വാസ്തവത്തിൽ നിങ്ങൾ അങ്ങനെ ചെയ്‌താൽ ഉള്ളടക്ക പൊരുത്തപ്പെടുത്തൽ പ്രവർത്തിക്കില്ല.

• ഉള്ളടക്കം ചർച്ച ചെയ്യാൻ നിങ്ങളുടെ സെർവർ സജ്ജീകരിക്കുക
• വിപുലീകരണമില്ലാതെ എപ്പോഴും യുആർഐകളിലേക്ക് ലിങ്ക് ചെയ്യുക

വിപുലീകരണങ്ങളുള്ള ലിങ്കുകൾ തുടർന്നും പ്രവർത്തിക്കും, എന്നാൽ നിലവിലുള്ളതും ഭാവിയിൽ ലഭ്യമായതുമായ മികച്ച ഫോർമാറ്റ് തിരഞ്ഞെടുക്കുന്നതിൽ നിന്ന് നിങ്ങളുടെ സെർവറിനെ തടയും.

(സത്യത്തിൽ, mydog, mydog.png и mydog.gif - സാധുവായ വെബ് ഉറവിടങ്ങൾ, mydog ഒരു സാർവത്രിക ഉള്ളടക്ക തരം ഉറവിടമാണ്, കൂടാതെ mydog.png и mydog.gif - ഒരു നിർദ്ദിഷ്ട ഉള്ളടക്ക തരത്തിന്റെ ഉറവിടങ്ങൾ).

തീർച്ചയായും, നിങ്ങളുടേതായ വെബ് സെർവർ എഴുതുകയാണെങ്കിൽ, പരിധിയില്ലാത്ത ഡാറ്റാബേസ് വളർച്ചയെ സൂക്ഷിക്കുക എങ്കിലും, സ്ഥിരമായ ഐഡന്റിഫയറുകൾ അവയുടെ നിലവിലെ രൂപത്തിലേക്ക് ബന്ധിപ്പിക്കുന്നതിന് ഒരു ഡാറ്റാബേസ് ഉപയോഗിക്കുന്നത് നല്ലതാണ്.

ബോർഡ് ഓഫ് ഷെയിം - സ്റ്റോറി 1: ചാനൽ 7

1999-ൽ, പേജിൽ മഞ്ഞ് കാരണം സ്കൂൾ അടച്ചത് ഞാൻ ട്രാക്ക് ചെയ്തു http://www.whdh.com/stormforce/closings.shtml. ടിവി സ്ക്രീനിന്റെ താഴെ വിവരങ്ങൾ ദൃശ്യമാകുന്നതുവരെ കാത്തിരിക്കരുത്! എന്റെ ഹോം പേജിൽ നിന്ന് ഞാൻ അതിലേക്ക് ലിങ്ക് ചെയ്തു. 2000-ലെ ആദ്യത്തെ വലിയ മഞ്ഞ് കൊടുങ്കാറ്റ് വരുന്നു, ഞാൻ പേജ് പരിശോധിക്കുന്നു. അവിടെ എഴുതിയിരിക്കുന്നു:,

- ഇതുവരെ.
നിലവിൽ ഒന്നും അടച്ചിട്ടില്ല. കാലാവസ്ഥാ മുന്നറിയിപ്പുകൾ ഉണ്ടെങ്കിൽ ദയവായി മടങ്ങുക.

അത്ര ശക്തമായ ഒരു കൊടുങ്കാറ്റ് ആകാൻ കഴിയില്ല. തീയതി കാണാതെ പോയത് തമാശയാണ്. എന്നാൽ നിങ്ങൾ സൈറ്റിന്റെ പ്രധാന പേജിലേക്ക് പോകുകയാണെങ്കിൽ, ഒരു വലിയ ബട്ടൺ "അടച്ച സ്കൂളുകൾ" ഉണ്ടാകും, അത് പേജിലേക്ക് നയിക്കുന്നു http://www.whdh.com/stormforce/ അടച്ചുപൂട്ടിയ സ്കൂളുകളുടെ ഒരു നീണ്ട പട്ടികയുമായി.

ലിസ്റ്റ് ലഭിക്കുന്നതിനുള്ള സംവിധാനം അവർ മാറ്റിമറിച്ചിരിക്കാം - പക്ഷേ അവർക്ക് യുആർഐ മാറ്റേണ്ട ആവശ്യമില്ല.

ബോർഡ് ഓഫ് ഷെയിം - സ്റ്റോറി 2: Microsoft Netmeeting

ഇന്റർനെറ്റിൽ വർദ്ധിച്ചുവരുന്ന ആശ്രിതത്വത്തോടെ, നിർമ്മാതാവിന്റെ വെബ്‌സൈറ്റിലേക്കുള്ള ലിങ്കുകൾ ആപ്ലിക്കേഷനുകളിൽ ഉൾച്ചേർക്കാമെന്ന ഒരു ബുദ്ധിപരമായ ആശയം വന്നു. ഇത് വളരെയധികം ഉപയോഗിക്കുകയും ദുരുപയോഗം ചെയ്യുകയും ചെയ്തു, എന്നാൽ നിങ്ങൾക്ക് URL മാറ്റാൻ കഴിയില്ല. കഴിഞ്ഞ ദിവസം ഞാൻ വെബ്/ഫ്രീ സ്റ്റഫ് മെനുവിലെ ഹെൽപ്പ്/മൈക്രോസോഫ്റ്റിലെ Microsoft Netmeeting 2/സംഥിംഗ് ക്ലയന്റിൽ നിന്ന് ഒരു ലിങ്ക് പരീക്ഷിച്ചു, 404 പിശക് ലഭിച്ചു - സെർവറിൽ നിന്ന് പ്രതികരണമൊന്നും കണ്ടെത്തിയില്ല. ഒരുപക്ഷേ അത് ഇതിനകം പരിഹരിച്ചു ...

© 1998 ടിം ബിഎൽ

ചരിത്രപരമായ കുറിപ്പ്: ഇരുപതാം നൂറ്റാണ്ടിന്റെ അവസാനത്തിൽ, ഇത് എഴുതപ്പെട്ടപ്പോൾ, "കൂൾ" എന്നത് അംഗീകാരത്തിന്റെ ഒരു വിശേഷണമായിരുന്നു, പ്രത്യേകിച്ച് യുവാക്കൾക്കിടയിൽ, ഫാഷൻ, ഗുണമേന്മ അല്ലെങ്കിൽ അനുയോജ്യത എന്നിവയെ സൂചിപ്പിക്കുന്നു. തിടുക്കത്തിൽ, URI പാത പലപ്പോഴും ഉപയോഗപ്രദമായോ ഈടുനിൽക്കുന്നതിനോ പകരം "തണുപ്പിന്" വേണ്ടി തിരഞ്ഞെടുത്തു. ഈ പോസ്റ്റ് കൂൾ എന്ന തിരയലിന് പിന്നിലെ ഊർജ്ജം തിരിച്ചുവിടാനുള്ള ശ്രമമാണ്.

അവലംബം: www.habr.com