Interesting thoughts...
_____/ On Fri 02 Dec 2005 18:01:01 GMT, [Douglas Daulton] wrote : \_____
I was a little confused about the WP API key requirements in WP 2.0 RC1. So
I had a chat with Matt about it. I now understand how it works with WP.com.
While I understand it, I think it may prove an administrative nightmare in
the long run. Not for me, but for the admins at WP.com. Mainly, I think
folks like me who run their own server, will end up creating a lot of dead
wp.com sites just to get an API key. So dead.wp.com will be just that ...
An empty ill-maintained site which will slowly clog up the works as wp.com
grows.
Void wp.com blogs should be cheap (in terms of space and traffic), but the
namespace is negatively affected (namely depleted), which makes wp.com
less desirable to potential subscribers.
I suspect that splog prove to be the far more detrimental artefact. As
Wordpress.com matures, it could (just /could/) become a victim of blo-
galanches. It only needs some scripting, thus time. Purging those invalid
blogs, which only serve SEO purposes, is harder. Blogs which function as
API key placeholders will most likely embed no content. Splogs are intend-
ed to look as much as possible like real blogs and they are often active,
not dormant.
So, I shared with Matt what I thought might be a more efficient way of doing
it. Basically, we learn from established pros like Amazon, Google and eBAY.
Create a new sub-domain called dev.wordpress.com (or something similar).
Have devs register there. Once registered, one dev gets a single API key.
If, for some reason, (tracking, stats, etc.), we need an individual API key
for every site we create, then have devs register new sites as part of their
account and then append some unique number or string to the end of the
existing API key. Viola! Unique, trackable API keys by domain or even
subdomain.
This would be an excellent solution, but only if you assume a
hacker/development community. If Average Joe's blog, which resides on a
separate domain, needed a key, the steps above would be daunting. Then
again, registering a blog just for an API key is adverse to common sense
too. I assume it is a temporary solution.
So in practice, it might looks something like this ...
1) I sign up at devs.wordpress.com and am asked if I also want a blog on
wp.com. In all cases, my requested user name is checked against the general
account list for *.wp.com. If it is available, I get it if not, I choose a
new one. If "I want a blog" is checked, then I am provisioned for
username.wp.com as well. If not, then I get no website, just an dev
account.
2) I fill out some info about myself and my dev abilities which might be
useful for folks looking for help on a project and could become an extension
to the dev marketplace that Matt kicked off a while back.
3) I am taken to a "Register Sites" page where I list the site(s) I
maintain.
4) Upon completion of the form and email confirmation of the account, I am
assigned a WP API key. And each site I register is given an
appended/extended key. The keys might look like this:
Username: monkeyman
Base API Key: monkeyman-1934567989909
Site Key 1: monkeyman-1934567989909-monkeyman.net
Site Key 2: monkeyman-1934567989909-monkeyman.com
Site Key 3: monkeyman-1934567989909-monkeyman.org
You probably need a 2-way verification process. This helps in prevention
of spam, which can exploit that openness and trust. Would it be putting
some code/key in the main directory of the blog to indicate ownership?
5) Every time I add a new site to my portfolio, I login to my WP dev account
and add it. Or, even cooler yet. On the new site, I enter my Base API Key
and it auto posts the new site to my account on dev.wp.com.
That would be ideal.
6) This could open up a whole new slew of cool, centralized WP-driven
services like statistics and performance analysis, SPAM Blacklists (like
Akismet), dev directory and ranking. Common tag libraries, etc. None of it
should squelch ideas and new project. Just the opposite, it should drive
them.
So there it is. Thoughts?
What you propose is using the seminal WordPress site as a root/authority
of all sites that are driven by it. You can create a network of WordPress
bound/associated sites, which I think is excellent. Statistics and analy-
sis, for example, can be optimised and tailored to the very nature of the
sites (which are all blogs). This has the advantages that Google Analyt-
ics, for instance, still lacks.
Roy
|
