Journal Articles
| Browse in : |
All
> Journals
> CVu
> 271
(11)
All > Topics > Programming (877) Any of these categories - All of these categories |
Note: when you create a new publication type, the articles module will automatically use the templates user-display-[publicationtype].xt and user-summary-[publicationtype].xt. If those templates do not exist when you try to preview or display a new article, you'll get this warning :-) Please place your own templates in themes/yourtheme/modules/articles . The templates will get the extension .xt there.
Title: Using ACCU Membership for Unique IDs
Author: Martin Moene
Date: 09 March 2015 20:56:04 +00:00 or Mon, 09 March 2015 20:56:04 +00:00
Summary: Silas S. Brown considers the case for identity.
Body:
Java package names, SGML/XML schema names and similar things are often expected to include the developer’s domain name to ensure uniqueness. While this in itself certainly doesn’t provide any real security (others can falsely use your domain name simply by typing it), and it doesn’t even guarantee uniqueness over time (if in future you transfer ownership of your domain to someone else, then your old code will be using names you no longer own), but in conjuction with other measures it does seem reasonable – that is, if you happen to have a domain name handy.
You could use a subdomain that you obtained on one of those ‘free dynamic DNS’ services, but your continued ownership of this will depend on the whim of that company. But it might be easier, and also more reliable, to simply use the domain of a long-established organisation of which you are a member, and add in your membership number or user ID to make sure it’s unique. For example if I were to say
package org.accu.m94137.appName;
(94137 being my ACCU membership number), that shouldn’t collide with anything by mistake. Notice that the package name does not have to be a real domain: ACCU don’t have to set their DNS server to actually resolve m94137.accu.org to an IP address, nor to set up a machine at that IP to handle any particular query that says it’s for m94137.accu.org; it’s only for uniqueness.
If the ACCU committee could state officially that members are entitled to use their membership numbers on accu.org when they need domain-based unique IDs, that would be extra reassurance that ACCU won’t be using these subdomains for some other purpose later, and would confer a small extra benefit to members at negligible cost to the ACCU. But even if they don’t officially commit to this, I think the chances of collision are very slight.
Notes:
More fields may be available via dynamicdata ..