From ianb at colorstudy.com Wed Mar 1 21:22:54 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Wed, 1 Mar 2006 14:22:54 -0600
Subject: [Catalog-sig] Adding trove categories
Message-ID: <5b79f7651a6dc1e604221be1f25a1eb0@colorstudy.com>
We want to add Cheese Shop categories for frameworks, so people can
register things.
These are the ones we (Kevin and I) would like:
Framework :: Paste
Framework :: TurboGears
Framework :: TurboGears :: Widgets
Framework :: TruboGears :: Applications
Topic :: Internet :: WWW/HTTP :: WSGI
Topic :: Internet :: WWW/HTTP :: WSGI :: Application
Topic :: Internet :: WWW/HTTP :: WSGI :: Server
Topic :: Internet :: WWW/HTTP :: WSGI :: Middleware
That's just the ones we want, and we have packages that could go in
there right now. I'm not that happy about putting WSGI under Topic ::
..., but it's not really a "Framework" either. Though putting it under
framework would be okay too.
Also, I think a link to this should go in the sidebar:
http://wiki.python.org/moin/CheeseShopDev
Some process for asking for new categories should be described on that
page. I think that process should be:
Python frameworks with plugins or packages that target the framework
can get their own category. The category should only be added *after*
such packages exist. Complimentary packages can link to each other
from their descriptions, they do not need a category to link them
together; only when packages are provided by different people does a
category need to be created. To ask for a category email
catalog-sig at python.org.
Also, if there's no response on catalog-sig, we should probably figure
out a backup person who someone on the list can forward the request to.
--
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
From richardjones at optushome.com.au Thu Mar 2 06:59:16 2006
From: richardjones at optushome.com.au (Richard Jones)
Date: Thu, 2 Mar 2006 16:59:16 +1100
Subject: [Catalog-sig] Adding trove categories
In-Reply-To: <5b79f7651a6dc1e604221be1f25a1eb0@colorstudy.com>
References: <5b79f7651a6dc1e604221be1f25a1eb0@colorstudy.com>
Message-ID: <200603021659.17116.richardjones@optushome.com.au>
On Thursday 02 March 2006 07:22, Ian Bicking wrote:
> We want to add Cheese Shop categories for frameworks, so people can
> register things.
>
> These are the ones we (Kevin and I) would like:
>
> Framework :: Paste
> Framework :: TurboGears
> Framework :: TurboGears :: Widgets
> Framework :: TruboGears :: Applications
> Topic :: Internet :: WWW/HTTP :: WSGI
> Topic :: Internet :: WWW/HTTP :: WSGI :: Application
> Topic :: Internet :: WWW/HTTP :: WSGI :: Server
> Topic :: Internet :: WWW/HTTP :: WSGI :: Middleware
Hurm. At the moment there's no top-level "Framework" grouping in the Trove
stuff. I'm not sure what will happen if one is added. I (or someone else who
possibly has more time) will need to test things out to make sure it won't
fall about laughing.
> That's just the ones we want, and we have packages that could go in
> there right now. I'm not that happy about putting WSGI under Topic ::
> ..., but it's not really a "Framework" either. Though putting it under
> framework would be okay too.
Er, I assume that means you'd prefer it to be under Topic, or do you not care.
I'd prefer that you make the call, to be honest.
Would "Topic :: Internet :: WWW/HTTP :: Framework :: ..." be too cubmersome?
Currently under "WWW/HTTP" we have:
Topic :: Internet :: WWW/HTTP :: Browsers
Topic :: Internet :: WWW/HTTP :: Dynamic Content
Topic :: Internet :: WWW/HTTP :: Dynamic Content :: CGI Tools/Libraries
Topic :: Internet :: WWW/HTTP :: Dynamic Content :: Message Boards
Topic :: Internet :: WWW/HTTP :: Dynamic Content :: News/Diary
Topic :: Internet :: WWW/HTTP :: Dynamic Content :: Page Counters
Topic :: Internet :: WWW/HTTP :: HTTP Servers
Topic :: Internet :: WWW/HTTP :: Indexing/Search
Topic :: Internet :: WWW/HTTP :: Site Management
Topic :: Internet :: WWW/HTTP :: Site Management :: Link Checking
Consider browsing - I'd think that people are more likely to go into the
WWW/HTTP topic to discover web stuff than a separate top-level Framework
grouping.
Richard
From ianb at colorstudy.com Thu Mar 2 21:54:23 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Thu, 2 Mar 2006 14:54:23 -0600
Subject: [Catalog-sig] Adding trove categories
In-Reply-To: <200603021659.17116.richardjones@optushome.com.au>
References: <5b79f7651a6dc1e604221be1f25a1eb0@colorstudy.com>
<200603021659.17116.richardjones@optushome.com.au>
Message-ID: <cc0126d45fee3d11068ba8d7425bb71b@colorstudy.com>
On Mar 1, 2006, at 11:59 PM, Richard Jones wrote:
> On Thursday 02 March 2006 07:22, Ian Bicking wrote:
>> We want to add Cheese Shop categories for frameworks, so people can
>> register things.
>>
>> These are the ones we (Kevin and I) would like:
>>
>> Framework :: Paste
>> Framework :: TurboGears
>> Framework :: TurboGears :: Widgets
>> Framework :: TruboGears :: Applications
>> Topic :: Internet :: WWW/HTTP :: WSGI
>> Topic :: Internet :: WWW/HTTP :: WSGI :: Application
>> Topic :: Internet :: WWW/HTTP :: WSGI :: Server
>> Topic :: Internet :: WWW/HTTP :: WSGI :: Middleware
>
> Hurm. At the moment there's no top-level "Framework" grouping in the
> Trove
> stuff. I'm not sure what will happen if one is added. I (or someone
> else who
> possibly has more time) will need to test things out to make sure it
> won't
> fall about laughing.
As I remember the trove categories were a pretty simple entry in the
database, just a flat list of strings.
>
>> That's just the ones we want, and we have packages that could go in
>> there right now. I'm not that happy about putting WSGI under Topic ::
>> ..., but it's not really a "Framework" either. Though putting it
>> under
>> framework would be okay too.
>
> Er, I assume that means you'd prefer it to be under Topic, or do you
> not care.
> I'd prefer that you make the call, to be honest.
>
> Would "Topic :: Internet :: WWW/HTTP :: Framework :: ..." be too
> cubmersome?
Yes, that would be too cumbersome; we just happen to be web frameworks.
Other frameworks might want a place in there too. "Framework" being a
classifier for actually-interesting-to-Python-users categories ;)
Right now the trove categories don't make much sense for Python
projects; lots of cruft, little granularity around things we actually
care about.
And "Topic :: Internet :: WWW/HTTP" is a super-lame category anyway ;)
It should be "Topic :: Web". But eh... really, the whole hierarchy and
taxonomy of packages is stupid. Which is why I would just like a
fairly flat list of "frameworks", which are Python projects for which
there exist packages that extend or utilize the framework.
> Currently under "WWW/HTTP" we have:
>
> Topic :: Internet :: WWW/HTTP :: Browsers
> Topic :: Internet :: WWW/HTTP :: Dynamic Content
> Topic :: Internet :: WWW/HTTP :: Dynamic Content :: CGI
> Tools/Libraries
> Topic :: Internet :: WWW/HTTP :: Dynamic Content :: Message Boards
> Topic :: Internet :: WWW/HTTP :: Dynamic Content :: News/Diary
> Topic :: Internet :: WWW/HTTP :: Dynamic Content :: Page Counters
> Topic :: Internet :: WWW/HTTP :: HTTP Servers
> Topic :: Internet :: WWW/HTTP :: Indexing/Search
> Topic :: Internet :: WWW/HTTP :: Site Management
> Topic :: Internet :: WWW/HTTP :: Site Management :: Link Checking
>
> Consider browsing - I'd think that people are more likely to go into
> the
> WWW/HTTP topic to discover web stuff than a separate top-level
> Framework
> grouping.
The top-level framework group is actually something I expect projects
will be linking directly into. So Paste will have a link to its
category, TurboGears to its, and so on; the XMLRPC interface offering
some additional opportunities. Or maybe with RSS extensions, e.g.,
putting a filtered aggregator on a website.
Mostly I don't want projects to have to implement their own package
indexes. If for no other reason than that it is a big waste of time
for those projects when we already have an index. But projects need a
way of providing a selective view of the index.
--
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
From pje at telecommunity.com Thu Mar 2 23:57:59 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 02 Mar 2006 17:57:59 -0500
Subject: [Catalog-sig] Adding trove categories
In-Reply-To: <cc0126d45fee3d11068ba8d7425bb71b@colorstudy.com>
References: <200603021659.17116.richardjones@optushome.com.au>
<5b79f7651a6dc1e604221be1f25a1eb0@colorstudy.com>
<200603021659.17116.richardjones@optushome.com.au>
Message-ID: <5.1.1.6.0.20060302175259.01df5428@mail.telecommunity.com>
At 02:54 PM 3/2/2006 -0600, Ian Bicking wrote:
>Right now the trove categories don't make much sense for Python
>projects; lots of cruft, little granularity around things we actually
>care about.
>
>And "Topic :: Internet :: WWW/HTTP" is a super-lame category anyway ;)
>It should be "Topic :: Web". But eh... really, the whole hierarchy and
>taxonomy of packages is stupid.
+1. Flat is better than nested, and the current categories are insanely
nested. 5 levels deep to get to the idea of "Message Boards"? Wow.
That having been said, I'm sure the trove stuff was adopted for a very good
reason, i.e., to avoid getting bogged down in taxonomy wars before there
was even a working product. :)
Now, however, that there are hundreds of projects already on a working
system, it might be a good idea to see what categories are actually getting
used, and consider collapsing them to a flatter hierarchy, or maybe even
just tags.
From richardjones at optushome.com.au Fri Mar 3 00:17:19 2006
From: richardjones at optushome.com.au (Richard Jones)
Date: Fri, 3 Mar 2006 10:17:19 +1100
Subject: [Catalog-sig] Adding trove categories
In-Reply-To: <5.1.1.6.0.20060302175259.01df5428@mail.telecommunity.com>
References: <200603021659.17116.richardjones@optushome.com.au>
<5.1.1.6.0.20060302175259.01df5428@mail.telecommunity.com>
Message-ID: <200603031017.20162.richardjones@optushome.com.au>
FYI, some revision ideas were rolled into this wiki page some time ago (mid
2004):
http://wiki.python.org/moin/RevisedPyPiCategories
Of course, that doesn't include Ian's recent "Framework" idea.
I'm busy at the moment, so can't really devote brain space to this problem.
Perhaps next week I will be able to. As always, I'm perfectly happy for
someone else to take on the problem as their own :)
Richard
From richardjones at optushome.com.au Fri Mar 3 00:24:58 2006
From: richardjones at optushome.com.au (Richard Jones)
Date: Fri, 3 Mar 2006 10:24:58 +1100
Subject: [Catalog-sig] Adding trove categories
In-Reply-To: <A2423959-4587-46E5-9CFD-701CFFC40C55@redivi.com>
References: <200603021659.17116.richardjones@optushome.com.au>
<5.1.1.6.0.20060302175259.01df5428@mail.telecommunity.com>
<A2423959-4587-46E5-9CFD-701CFFC40C55@redivi.com>
Message-ID: <200603031024.58248.richardjones@optushome.com.au>
On Friday 03 March 2006 10:14, you wrote:
> I'd go +1 for (freeform) tags.. the tags people want to use to
> describe their projects should shake out pretty quickly, and it
> prevents us from ever having to request a new topic whenever someone
> comes up with a new idea or web framework :)
No, free-form fields should be somewhere else. Propose a "keywords" field if
you like, but I believe the description field performs this job adequately.
I work for a company that runs conferences. We have approximately 7,500
proposals in across 10 conferences. They're all humanities-related, but in
slightly different fields. Regardless, we now have 25,000 unique "keywords"
that have been supplied from our free-form keywords field. Not so useful.
Richard
From bob at redivi.com Fri Mar 3 00:14:13 2006
From: bob at redivi.com (Bob Ippolito)
Date: Thu, 2 Mar 2006 15:14:13 -0800
Subject: [Catalog-sig] Adding trove categories
In-Reply-To: <5.1.1.6.0.20060302175259.01df5428@mail.telecommunity.com>
References: <200603021659.17116.richardjones@optushome.com.au>
<5b79f7651a6dc1e604221be1f25a1eb0@colorstudy.com>
<200603021659.17116.richardjones@optushome.com.au>
<5.1.1.6.0.20060302175259.01df5428@mail.telecommunity.com>
Message-ID: <A2423959-4587-46E5-9CFD-701CFFC40C55@redivi.com>
On Mar 2, 2006, at 2:57 PM, Phillip J. Eby wrote:
> At 02:54 PM 3/2/2006 -0600, Ian Bicking wrote:
>> Right now the trove categories don't make much sense for Python
>> projects; lots of cruft, little granularity around things we actually
>> care about.
>>
>> And "Topic :: Internet :: WWW/HTTP" is a super-lame category
>> anyway ;)
>> It should be "Topic :: Web". But eh... really, the whole
>> hierarchy and
>> taxonomy of packages is stupid.
>
> +1. Flat is better than nested, and the current categories are
> insanely
> nested. 5 levels deep to get to the idea of "Message Boards"? Wow.
>
> That having been said, I'm sure the trove stuff was adopted for a
> very good
> reason, i.e., to avoid getting bogged down in taxonomy wars before
> there
> was even a working product. :)
>
> Now, however, that there are hundreds of projects already on a working
> system, it might be a good idea to see what categories are actually
> getting
> used, and consider collapsing them to a flatter hierarchy, or maybe
> even
> just tags.
I'd go +1 for (freeform) tags.. the tags people want to use to
describe their projects should shake out pretty quickly, and it
prevents us from ever having to request a new topic whenever someone
comes up with a new idea or web framework :)
-bob
From bob at redivi.com Fri Mar 3 00:32:29 2006
From: bob at redivi.com (Bob Ippolito)
Date: Thu, 2 Mar 2006 15:32:29 -0800
Subject: [Catalog-sig] Adding trove categories
In-Reply-To: <200603031024.58248.richardjones@optushome.com.au>
References: <200603021659.17116.richardjones@optushome.com.au>
<5.1.1.6.0.20060302175259.01df5428@mail.telecommunity.com>
<A2423959-4587-46E5-9CFD-701CFFC40C55@redivi.com>
<200603031024.58248.richardjones@optushome.com.au>
Message-ID: <8726C021-49E9-40BA-A97E-B3C9B6CC646F@redivi.com>
On Mar 2, 2006, at 3:24 PM, Richard Jones wrote:
> On Friday 03 March 2006 10:14, you wrote:
>> I'd go +1 for (freeform) tags.. the tags people want to use to
>> describe their projects should shake out pretty quickly, and it
>> prevents us from ever having to request a new topic whenever someone
>> comes up with a new idea or web framework :)
>
> No, free-form fields should be somewhere else. Propose a "keywords"
> field if
> you like, but I believe the description field performs this job
> adequately.
>
> I work for a company that runs conferences. We have approximately
> 7,500
> proposals in across 10 conferences. They're all humanities-related,
> but in
> slightly different fields. Regardless, we now have 25,000 unique
> "keywords"
> that have been supplied from our free-form keywords field. Not so
> useful.
So what? If you're browsing, only show the N most popular ones.
-bob
From ianb at colorstudy.com Fri Mar 3 23:38:41 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Fri, 03 Mar 2006 16:38:41 -0600
Subject: [Catalog-sig] Adding trove categories
In-Reply-To: <200603031024.58248.richardjones@optushome.com.au>
References: <200603021659.17116.richardjones@optushome.com.au> <5.1.1.6.0.20060302175259.01df5428@mail.telecommunity.com> <A2423959-4587-46E5-9CFD-701CFFC40C55@redivi.com>
<200603031024.58248.richardjones@optushome.com.au>
Message-ID: <4408C571.7040500@colorstudy.com>
Richard Jones wrote:
> On Friday 03 March 2006 10:14, you wrote:
>
>>I'd go +1 for (freeform) tags.. the tags people want to use to
>>describe their projects should shake out pretty quickly, and it
>>prevents us from ever having to request a new topic whenever someone
>>comes up with a new idea or web framework :)
>
>
> No, free-form fields should be somewhere else. Propose a "keywords" field if
> you like, but I believe the description field performs this job adequately.
There is a keywords field. This would work okay if there was better
abilities to query and browse that field. I don't remember how it is
stored in the database.
But anyway, assuming we are doing that, how should we open up
participation? The lack of a representative database dump makes it hard
for other people to work on it on their local machines. And of course
Subversion access for some people.
--
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
From lac at strakt.com Sat Mar 4 16:47:13 2006
From: lac at strakt.com (Laura Creighton)
Date: Sat, 04 Mar 2006 16:47:13 +0100
Subject: [Catalog-sig] Adding trove categories
In-Reply-To: Message from Ian Bicking <ianb@colorstudy.com> of "Thu,
02 Mar 2006 14:54:23 CST."
<cc0126d45fee3d11068ba8d7425bb71b@colorstudy.com>
References: <5b79f7651a6dc1e604221be1f25a1eb0@colorstudy.com>
<200603021659.17116.richardjones@optushome.com.au>
<cc0126d45fee3d11068ba8d7425bb71b@colorstudy.com>
Message-ID: <200603041547.k24FlDgd011355@theraft.strakt.com>
>> Topic :: Internet :: WWW/HTTP :: HTTP Servers
>> Topic :: Internet :: WWW/HTTP :: Indexing/Search
>> Topic :: Internet :: WWW/HTTP :: Site Management
>> Topic :: Internet :: WWW/HTTP :: Site Management :: Link Checking
If at all possible, you do not want a hierarchy. What you want is a
way to attatch meta-data to the project and search for intersections
of relevancies.
So -- CAPS (our main product) is a framework. It is also a workflow system.
You can connect it to the internet, but you do not have to. There is
a WWW client if you want one, we have others that aren't webbish at
all.
The more versatile you are, the harder time you will have fitting into
a pre-existing heirarchy. Which may be the whole reason you wrote the
thing in the first place -- you judged the functionality of existing
offerings inadequate precisely because they were limited by somebody's
heirarchical expectations, and you refused to be boxed in.
Laura
From tim at pollenation.net Sat Mar 11 12:22:47 2006
From: tim at pollenation.net (Tim Parkin)
Date: Sat, 11 Mar 2006 11:22:47 +0000
Subject: [Catalog-sig] feedback received from python.org trac
Message-ID: <4412B307.1070309@pollenation.net>
This was posted on the psf.pollenation.net trac..
Just forwarding on..
---------------------------------------------------
Password reset needs improvement for Cheese Shop.
If a registered user changes or closes an email accounts, then that user
cannot get into the package submission site ever again ever, unless he
reregisters. But that is the problem. The user's previously submitted
package will exist as is for ever and ever or until someone deletes it.
The problem is : When entering a user name to reset the password an
email is sent to the old email which is closed. The email is bounced,
returned, living only until some automated system destroys it but never
to be received by anyone.
If a registered user enters his current email address (the new one), to
reset the password, then the username is not recognized as a match to
the username and the entry invalid.
Either way the user is forced to re-register.
However the user cannot resubmit the same package, nor can he access
his previously registered package because his original registration
belongs to a ghost.
The managers of my webspace offer an option to submit a new email
address after entering a login name and password. What an idea. Works
for me.
If you are wondering how I thought of this needed improvement, the
answer is that this problem is happening to me right now.
And, if someone ever decides to make such an improvement, I would
appreciate an email sent to tech at inqvista.com it's in the inqVista
package, listed on the Cheese Shop site. Also valid is
inq1ltd at verizon.net. Otherwise my package will live forever as is. And,
I will have to re-work, re-build, re-write, re-submit, redo, re-install,
re-construct, re-compose, re-compile, re-name and re-register, just for
starters. And, I hope not.
Re-Regards, jim derose (inq1ltd at verizon.net)
From martin at v.loewis.de Sat Mar 11 14:15:31 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 11 Mar 2006 14:15:31 +0100
Subject: [Catalog-sig] feedback received from python.org trac
In-Reply-To: <4412B307.1070309@pollenation.net>
References: <4412B307.1070309@pollenation.net>
Message-ID: <4412CD73.8010703@v.loewis.de>
Dear Jim,
I'm not sure I completely sure I understand your problem.
> If a registered user enters his current email address (the new one), to
> reset the password, then the username is not recognized as a match to
> the username and the entry invalid.
>
> Either way the user is forced to re-register.
If the user remembers the Cheeseshop password, he can just change the
email address. Login to the page, go to "Your details", edit the
field "Email address", and press "Update details".
> The managers of my webspace offer an option to submit a new email
> address after entering a login name and password. What an idea. Works
> for me.
Right: after entering a login name and password. The same works for
Cheeseshop.
> And, if someone ever decides to make such an improvement
I still wonder what improvement you are looking for.
Regards,
Martin
From ianb at colorstudy.com Sat Mar 11 22:09:08 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Sat, 11 Mar 2006 15:09:08 -0600
Subject: [Catalog-sig] feedback received from python.org trac
In-Reply-To: <4412B307.1070309@pollenation.net>
References: <4412B307.1070309@pollenation.net>
Message-ID: <44133C74.3030800@colorstudy.com>
Tim Parkin wrote:
> This was posted on the psf.pollenation.net trac..
>
> Just forwarding on..
>
> ---------------------------------------------------
> Password reset needs improvement for Cheese Shop.
>
> If a registered user changes or closes an email accounts, then that user
> cannot get into the package submission site ever again ever, unless he
> reregisters. But that is the problem. The user's previously submitted
> package will exist as is for ever and ever or until someone deletes it.
>
> The problem is : When entering a user name to reset the password an
> email is sent to the old email which is closed. The email is bounced,
> returned, living only until some automated system destroys it but never
> to be received by anyone.
There's no way to resolve this. The only way is for the person to
contact a human and figure it out. Or they can check ~/.pypirc, which
has a plaintext password. Maybe there needs to be a contact form or
something on the forgotten password page.
--
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
From martin at v.loewis.de Sun Mar 12 01:08:58 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 12 Mar 2006 01:08:58 +0100
Subject: [Catalog-sig] feedback received from python.org trac
In-Reply-To: <200603111401.13267.inq1ltd@verizon.net>
References: <4412B307.1070309@pollenation.net> <4412CD73.8010703@v.loewis.de>
<200603111401.13267.inq1ltd@verizon.net>
Message-ID: <4413669A.6010503@v.loewis.de>
jim_on_linux wrote:
> The question is, Now what? What does this user
> do?
You gave your web provider (or somebody) as an example:
what do they do if you have forgotten your password,
*and* your email address has changed?
There is no way to automatically verify that you are
still the same person. If anybody could change anybody's
password and email address, we would not need to use
passwords in the first place.
Ian Bicking points out that you can look into the file
.pypirc, if you still have that, perhaps it has cached
the password, in which case it would be stored as clear
text. If you only ever interacted with the Cheeseshop
with a web browser, then it won't have the password
stored.
In that case, you should follow the "Get Help" on
the lower-left side of
http://cheeseshop.python.org/pypi
which brings you to
http://sourceforge.net/tracker/?group_id=66150&atid=513504
and request a change of email address. State your real
name, your account name, and your old and new email
address.
Regards,
Martin
From inq1ltd at verizon.net Sun Mar 12 22:31:24 2006
From: inq1ltd at verizon.net (jim_on_linux)
Date: Sun, 12 Mar 2006 16:31:24 -0500
Subject: [Catalog-sig] feedback received from python.org trac
In-Reply-To: <4412CD73.8010703@v.loewis.de>
References: <4412B307.1070309@pollenation.net> <4412CD73.8010703@v.loewis.de>
Message-ID: <0IW1007J09POJY80@vms046.mailsrvcs.net>
Dear Martin,
On Saturday 11 March 2006 08:15, Martin v. L?wis
wrote:
> Dear Jim,
>.............
>................
> I still wonder what improvement you are looking
> for.
If this type of event is a regular occurrence,
then I suggest something like the following.
When registering, I would require a third
identifier in addition to name and password.
The third identifier:
Offer a pop-up menu with many choices. Instruct
the user to pick at least four choices from this
menu. But, pick only one that the user would, or
could, easily answer.
Then, In the case where someone may forget either
password, login identifier, or have an email
address change, then a click on the button,
"Cannot login?"
would call the following form:
---------------------------------------------------------------
Enter the email address that you used when
registering with this system: ...................
Enter Your current email address: ...............
Both email addresses above must be entered.
Answer only two of the following questions.
Enter login id: .............
Enter Password: ........................
(Below are questions that could have been picked
from a menu of many by the user at registration,
and only one of which would be answered or
error.)
My son's first car, make and
year: ...................
My mothers's maiden name , first and last
name: .............
The city my mother was born in.
My favorite movie: .................
My oldest sister's birthday, month and
year: .............
The city my father was born in: ...........
------------------------------------------------------------
(And many others that could be suggested.)
A valid email and login gets an email sent to
user.
A correct login ID and answered question is a
valid login.
And a valid password and answered question is a
valid login.
If the email addresses above don't match, then, no
email is sent but the user can change the email
after entering the system.
In all cases the user can then change any of the
parameters, with two of three identifiers, valid
email, password or login, answered question.
Keeping track of passwords can be a pain, but
picking a third way of entering a system from
one's life's experience (a little harder to
forget than a password) may be a additional way
to keep some of this stuff in order.
Regards,
jim
From exarkun at divmod.com Sun Mar 12 22:36:43 2006
From: exarkun at divmod.com (Jean-Paul Calderone)
Date: Sun, 12 Mar 2006 16:36:43 -0500
Subject: [Catalog-sig] feedback received from python.org trac
In-Reply-To: <0IW1007J09POJY80@vms046.mailsrvcs.net>
Message-ID: <20060312213643.6122.349544126.divmod.quotient.15584@ohm>
On Sun, 12 Mar 2006 16:31:24 -0500, jim_on_linux <inq1ltd at verizon.net> wrote:
>Dear Martin,
>
>On Saturday 11 March 2006 08:15, Martin v. L?wis
>wrote:
>
>> Dear Jim,
>>.............
>>................
>> I still wonder what improvement you are looking
>> for.
>
>If this type of event is a regular occurrence,
>then I suggest something like the following.
>
> [snip - "Secret question" system description]
>
>Keeping track of passwords can be a pain, but
>picking a third way of entering a system from
>one's life's experience (a little harder to
>forget than a password) may be a additional way
>to keep some of this stuff in order.
>
I hate these systems. Did I provide real information because I was fed up with them and didn't care about security? Did I make up something and if I did did I write it down someplace? Which question did I provide an answer to? What do I do when I forget the answer to _this_ round of questions?
If you can't remember your password, write it down. At least then you are limiting your exposure to people with physical access to your terminal, instead of opening yourself up to attacks from anyone who knows how to use google.
Or better yet, just keep your email address in the system up to date. There are a slew of free email services which will give you an address that lasts practically forever: get one and use it.
Jean-Paul
From martin at v.loewis.de Sun Mar 12 23:07:23 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 12 Mar 2006 23:07:23 +0100
Subject: [Catalog-sig] feedback received from python.org trac
In-Reply-To: <0IW1007J09POJY80@vms046.mailsrvcs.net>
References: <4412B307.1070309@pollenation.net> <4412CD73.8010703@v.loewis.de>
<0IW1007J09POJY80@vms046.mailsrvcs.net>
Message-ID: <44149B9B.4070400@v.loewis.de>
jim_on_linux wrote:
> If this type of event is a regular occurrence,
> then I suggest something like the following.
It's not a regular occurrence. Most users apparently
found one or the other way to deal with such systems.
For example, one could use the same password for a
number of such systems, e.g. your favourite movie,
or your mother's maiden name.
Regards,
Martin
From inq1ltd at verizon.net Mon Mar 13 04:16:38 2006
From: inq1ltd at verizon.net (jim_on_linux)
Date: Sun, 12 Mar 2006 22:16:38 -0500
Subject: [Catalog-sig] feedback received from python.org trac
In-Reply-To: <44149B9B.4070400@v.loewis.de>
References: <4412B307.1070309@pollenation.net>
<0IW1007J09POJY80@vms046.mailsrvcs.net> <44149B9B.4070400@v.loewis.de>
Message-ID: <200603122216.38232.inq1ltd@verizon.net>
On Sunday 12 March 2006 17:07, Martin v. L?wis
wrote:
> It's not a regular occurrence. Most users
> apparently found one or the other way to deal
> with such systems. For example, one could use
> the same password for a number of such systems,
Dear Martin,
If this is not a regular event I agree leave it
alone.
However I checked the .pypirc file and found that
the user name and password that I am using is
valid. And, after trying trying again a few
minutes ago I'm still having the same problem.
"Authentication Failed. Do you want to retry?"
The problem is not that I forgot my user name or
password.
I will try your suggestion in the morning.
http://cheeseshop.python.org/pypi
http://sourceforge.net/tracker/?group_id=66150&atid=513504
Thanks,
Jim
From matt at thenashgroup.net Tue Mar 21 19:13:19 2006
From: matt at thenashgroup.net (Matt Carpenter)
Date: Tue, 21 Mar 2006 10:13:19 -0800
Subject: [Catalog-sig] Satellite Imaging Engineer Opportunity in Southern
California
Message-ID: <20060321181029.FCOE17006.fed1rmmtao02.cox.net@Mat>
My name is Matt Carpenter and I manage a recruiting company in San Diego
California. One of my most impressive clients in Southern California is
looking for a Satellite Systems Engineer. The position requires and advanced
understanding of satellite imaging and a proven track record of innovation.
The job highlights are below and my motivation is a 12 on a scale from 1-10!
I was wondering if you might know any qualified candidates you could refer
to me?
Please contact me or have them contact me ASAP at matt at thenashgroup.net Or
reply to my e-mail.
Experience should include writing plans and test procedures for large-scale
engineering systems incorporating requirement analysis and high level design
documentation. 6-10 years experience in large development projects; or
satellite ground station projects. Experience with satellite remote sensing
or imaging systems development preferred. Proven experience using formal
system engineering methodologies for requirements, analysis, design,
integration and testing.
University degree in Applied Sciences / Engineering or Computer Science.
Generic/extensible programming techniques in Python or other dynamic
languages. A working knowledge of GNU Command-line tools (sed, awk, xargs,
grep, .. etc).
Thanks in advance,
Matt Carpenter
The Nash Group
619.851.2614
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/catalog-sig/attachments/20060321/882bc43f/attachment.htm
From dangoor at gmail.com Thu Mar 23 21:25:39 2006
From: dangoor at gmail.com (Kevin Dangoor)
Date: Thu, 23 Mar 2006 15:25:39 -0500
Subject: [Catalog-sig] Adding trove categories
In-Reply-To: <5b79f7651a6dc1e604221be1f25a1eb0@colorstudy.com>
References: <5b79f7651a6dc1e604221be1f25a1eb0@colorstudy.com>
Message-ID: <3f085ecd0603231225kd7225c6l3b4b308cb5c5a68e@mail.gmail.com>
On 3/1/06, Ian Bicking <ianb at colorstudy.com> wrote:
> We want to add Cheese Shop categories for frameworks, so people can
> register things.
>
> These are the ones we (Kevin and I) would like:
>
> Framework :: Paste
> Framework :: TurboGears
> Framework :: TurboGears :: Widgets
> Framework :: TruboGears :: Applications
> Topic :: Internet :: WWW/HTTP :: WSGI
> Topic :: Internet :: WWW/HTTP :: WSGI :: Application
> Topic :: Internet :: WWW/HTTP :: WSGI :: Server
> Topic :: Internet :: WWW/HTTP :: WSGI :: Middleware
Still no word on this. I've poked around and found the XML-RPC
interface and how the query mechanism works. Maybe I'll resort to
using keywords or something in the description to be able to find
these.
Kevin
From ianb at colorstudy.com Thu Mar 23 22:29:32 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Thu, 23 Mar 2006 15:29:32 -0600
Subject: [Catalog-sig] Adding trove categories
In-Reply-To: <3f085ecd0603231225kd7225c6l3b4b308cb5c5a68e@mail.gmail.com>
References: <5b79f7651a6dc1e604221be1f25a1eb0@colorstudy.com>
<3f085ecd0603231225kd7225c6l3b4b308cb5c5a68e@mail.gmail.com>
Message-ID: <4423133C.4050009@colorstudy.com>
Kevin Dangoor wrote:
> On 3/1/06, Ian Bicking <ianb at colorstudy.com> wrote:
>
>>We want to add Cheese Shop categories for frameworks, so people can
>>register things.
>>
>>These are the ones we (Kevin and I) would like:
>>
>>Framework :: Paste
>>Framework :: TurboGears
>>Framework :: TurboGears :: Widgets
>>Framework :: TruboGears :: Applications
>>Topic :: Internet :: WWW/HTTP :: WSGI
>>Topic :: Internet :: WWW/HTTP :: WSGI :: Application
>>Topic :: Internet :: WWW/HTTP :: WSGI :: Server
>>Topic :: Internet :: WWW/HTTP :: WSGI :: Middleware
>
>
> Still no word on this. I've poked around and found the XML-RPC
> interface and how the query mechanism works. Maybe I'll resort to
> using keywords or something in the description to be able to find
> these.
I actually think this is a good idea anyway. Keywords are freetext and
people can come up with their own taxonomies fairly freely. E.g.,
turbogears+toolbox (all toolbox things), or turbogears+toolbox+sqlobject
(all toolbox things that use SQLObject), or toolbox (any framework's
toolbox?)
It would also be nice if you could do
http://cheeseshop.python.org/pypi/tags/turbogears+toolbox and get a
listing, del.icio.us-style, but that can be implemented over XML-RPC for
now. The XML-RPC interface could use some additions too... which really
brings us back to the question of developer access to the codebase, or
more specifically to a representative data set for use in testing?
--
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
From dangoor at gmail.com Thu Mar 23 22:36:39 2006
From: dangoor at gmail.com (Kevin Dangoor)
Date: Thu, 23 Mar 2006 16:36:39 -0500
Subject: [Catalog-sig] Adding trove categories
In-Reply-To: <4423133C.4050009@colorstudy.com>
References: <5b79f7651a6dc1e604221be1f25a1eb0@colorstudy.com>
<3f085ecd0603231225kd7225c6l3b4b308cb5c5a68e@mail.gmail.com>
<4423133C.4050009@colorstudy.com>
Message-ID: <3f085ecd0603231336t6b297630l8b26ff930f315c24@mail.gmail.com>
On 3/23/06, Ian Bicking <ianb at colorstudy.com> wrote:
> It would also be nice if you could do
> http://cheeseshop.python.org/pypi/tags/turbogears+toolbox and get a
> listing, del.icio.us-style, but that can be implemented over XML-RPC for
> now. The XML-RPC interface could use some additions too... which really
> brings us back to the question of developer access to the codebase, or
> more specifically to a representative data set for use in testing?
Even beyond just testing, it would be nice to be able to put a little
more information up at TurboGears.org without having to run individual
queries for the relevant packages. At least the XML-RPC interface
that's there now gives me a good start though.
Kevin