Re: namespace for users and groups

[David R. Baird]

On 22 Aug 2004 at 22:31, david nicol wrote:

> On Sun, 2004-08-22 at 18:04, David R. Baird wrote:
> > 
> > I'm not 100% sure of the Tree:: bit (although it is based on a tree 
> > structure), but I can't see where else it could fit in. 
> > 
> > d.
> 
> Are the arboreal aspects important to the use of the tool or are they
> implementation details?  Could you change it to use a hash or a 
> SQL server without altering the interface?  Ifyou did, would it make
> said arbitrary back-end appear treelike?

I think the treeness is quite important, because groups inherit the 
capabilities/permissions of their subgroups. So whenever you check if 
your own group is permitted to do something, you know that the tree-
like hierarchy of groups contained within your group is also being 
checked. 

The treeness isn't apparent when you do an authorization lookup (you 
just query against your own group), but it is apparent when you set 
up the groups. 

I think I was just a bit doubtful of having Tree and Group in the 
name at the same time, since they both describe some aspect of data 
structure. But they're both relevant, so I guess that's OK. If there 
were an Authz:: namespace, I'd probably go for Authz::Tree, so maybe 
I should go for Tree::Authz. 

By the way, I'd argue that there probably _should_ be an Authz:: 
namespace, just as there is an Authen:: namespace. They're different 
things. Although some of the Authen:: modules support authorization, 
it also makes sense that authorization can be abstracted out from 
authentication. 

This is more difficult than writing the damn thing! 

d.


> 
> 
> -- 
> david nicol
>   "Someday, everything's going to be different
>when I paint my masterpiece."



-- 
Dr. David R. Baird
Riverside Content Management Systems
[EMAIL PROTECTED]
http://www.riverside-cms.co.uk

Re: name for singlethreaded web server framework module (chatty)

[Nicholas Clark]

On Sat, Aug 21, 2004 at 06:52:27PM -0500, david nicol wrote:

> Better to be a team player and release
> 
> HTTP::Server::Singlethreaded
> 
> which would invoke the correct class of considerations for those whose
> initial referent for "Selecting" is not the Berkeley socket library.

Seems sensible enough (and I read that you've uploaded under that name)

> Does Perl have non-blocking file IO yet? I know Uri Guttman requested
> non-blocking file IO some time ago.  I've thought about serving larger
> static files with
> 
>open my $OutBound, "cat $filename|";
> 
> and incorporating these pipes into the multiplexion, but this approach
> (1) is not portable to places where cat(1) is not installed and (2)
> requires more complex multiplexion than is needed for The Task At Hand
> and is therefore deferred according to the best practices of Extreme
> Programming.

Presumably generating pipes to helper tasks can be done with a module on
CPAN? And is it really going to achieve faster non-blocking file IO on
anything other than Unix (or Unix-a-likes) where there will be cat?

Nicholas Clark

Re: META.yml generation and SIGNATURE problems

[Ken Williams]

Hi Kjetil,
If you use Module::Build instead of MakeMaker, then it's easy: just 
include "sign => 1" as part of the arguments to Module::Build->new().

If you don't want to use Module::Build, you can emulate what it does: 
build the distdir, go into the distdir directory, add SIGNATURE to the 
MANIFEST file, sign the directory, and then make a tarball from the 
distdir.

It's not likely that signing will ever be integrated into MakeMaker's 
dist process, so Module::Build might be a good way to go.

 -Ken
On Aug 19, 2004, at 7:01 PM, Kjetil Kjernsmo wrote:
Hi all!
I'm a relatively fresh CPAN author who wants to start signing his
modules. And I'm pretty confused about how to do it, and asking some
friends, they told me to go here. I I'm not subscribed, so please CC
any replies.
I first tried to sign my AxKit::App::TABOO, and the signing itself is
straightforward with Module::Signature's cpansign. I build the module
like I've always done, with make dist, using ExtUtils::MakeMaker, I
suppose. Everything looks fine, but then I notice that META.yml has
changed, and it invalidates the signature...
So, I figured, the build process must be split up in several steps.
Since it is make distdir that creates META.yml, then cpansign should be
run after that, but then, it copies everything to the new dir too, so
it is sort of too late to sign...? Uhm, well, I'm confused...
I think it would have been great if the signing was integrated in the
make dist process somehow, but in the meantime, is there a simple and
reliable way to do this...?
BTW, the latest version of Module::Signature doesn't install cleanly 
for
me. Is that because I'm confused, or does it have a similar problem?

Best,
Kjetil
--
Kjetil Kjernsmo
Astrophysicist/IT 
Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer
[EMAIL PROTECTED]  [EMAIL PROTECTED]  
[EMAIL PROTECTED]
Homepage: http://www.kjetil.kjernsmo.net/OpenPGP KeyID: 
6A6A0BBC

Namespace for EUI related modules

[Suresh Govindachar]

Hello,

I defined the concept of an Editable User Interface (EUI)
on www.sonic.net/~suresh/eui and illustrated it with
an extensive application
on www.vim.org/scripts/script.php?script_id=1052 .

I am now ready to modularize my work and deploy it on CPAN.

The design I have is as follows:

The essence of the work is the development of applications
that use a text editor (such as VIM) as their user
interface.  This involves:

   A) Development of the application modules to interface to an
  abstract editor (acting as the editable user interface)
   B) Development the glue that will take any specific editor
  and make it act as an abstract editable user interface
   C) Simple enhancement to the interface of specific editors

The actual deployment of the application will consist of
consist of code that first instantiates an abstract editable
user interface for a specific editor, and then uses this
instance as one of the agruments to instantiate the
application module.  This deployment code -- which makes
the application modules work with a given editor -- will not
be part of CPAN, but would be part of .org.

So the modules on CPAN would be:

  Result of development (A):

  EUI::TMS
  EUI::TMS::Configure
  EUI::TMS::Send
  EUI::TMS::Receive
  EUI::TMS::Organize
  EUI::TMS::Work

  Result of development (B):

  EUI::Vim
  EUI::Shell  (A shell is not a text editor but this
   glue will allow (A) to be run from the
   command line -- which can be useful
   during debuging and as such too.)

  Result of development (C):

  EUI::VIM  (adds some simple functions to the VIM
 class embedded inside the Vim editor)

So I would like to register the following ten namespaces:

  EUI
  EUI::TMS
  EUI::TMS::Configure
  EUI::TMS::Send
  EUI::TMS::Receive
  EUI::TMS::Organize
  EUI::TMS::Work
  EUI::Vim
  EUI::Shell
  EUI::VIM

In future there could be other modules:  EUI::,
EUI, EUI:: and EUI::.

So what say you? -- I welcome comments/feedback.

By the way, if you know of a script to fill out
https://pause.perl.org/pause/authenquery?ACTION=apply_mod
please point me to it.  If there is no such script, I will
be attempting to write one (using WWW::Mechanize?) -- I
trust there is no danger of me messing things up on PAUSE by
doing so.

Thanks,

--Suresh

Re: Let's eliminate the Module List

[Robert Rothenberg]

I'm ok with eliminating the list: I largely agree with the comments as to why 
it no longer servers the purpose it was intended for.

As for replacing it:
* search.cpan.org is better, but leaves a lot to be desired in terms of
  keywords.
* I'm not entirely against duplication of effort, since there are many ways
  to do things, and sometimes a duplicate module has a better way to do it.
* The categories for search.cpan.org need to be rethought, maybe even with
  subcategories.
  In some cases modules should be in multiple categories.
* I like the idea of some kind of official namespace annointing or reserving,
  provided it serves a clear purpose:
  - modules to be included in core or specialized distributions
  - minimum degree of quality control (minimum CPANTS rating?)
  This should proceed in definite stages, maybe with a kind of workflow
  system:
  1. module already exists on CPAN for minimum amount of time
  2. request made for namespace blessing
  3. "priests of namespace" verify that namespace has been discussed
 in relevant forums and makes sense with respect to some scheme
 which is publically available
  4. verify that module meets minimum standards (non-trivial tests,
 readme, changes, tests pass on variety of systems, if applicable,
 meta.yml, license, no glaring copyright or patent issues, etc.)
  5. verify that the module does not duplicate effort
  6. with problems resolved, module is approved with associated
 categories and keywords
  Likewise, there could be a scheme for "unblessing" a module:
  - quality falls below a certain level
  - copyright/patent issues emerge
  - author has fallen off the face of the earth
  - module has not been updated in X months but there are outstanding
issues/bugs
  - many bad ratings by users in forums and cpanratings
  It would be a lot of work to implement a workflow system (I wish I had the
  time), but once it's implemented, the approval work could be distributed
  among several trusted people.
  The nice thing about a workflow system is that authors can followup on
  requests, and users can use this to research information about a module.
  Yes, this goes beyond an official namespace list and becomes a kind of
  module underwriters kosher good housekeeping seal of approval.
  Note that if there is some kind of blessing scheme, it should include the
  usual disclaimers that we still do not guarantee it against damaging your
  data, employer, or marriage etc.
Well, that's my several cents.
Rob

Re: Let's eliminate the Module List

[Nicholas Clark]

On Mon, Aug 23, 2004 at 04:11:33PM -0400, Robert Rothenberg wrote:
>   It would be a lot of work to implement a workflow system (I wish I had the
>   time), but once it's implemented, the approval work could be 

Your honesty with "I wish I had the time" illustrates the problem here.
[and the following isn't personal, but for the list as a whole:]

Talk is cheap. Sadly none of this will get done unless someone with
sufficient desire to do this creates themselves the time and does it.

There is nothing stopping anyone on this list prototyping their own
improved substitute for search.cpan.org. (although it helps if you have
a public facing webserver if you want to show it to others).

Yet no-one does.

Until someone does, nothing will change. No-one on this list is preventing
anyone from trying this.

Nicholas Clark

Re: Let's eliminate the Module List

[Simon Cozens]

[EMAIL PROTECTED] (Nicholas Clark) writes:
> Until someone does, nothing will change. No-one on this list is preventing
> anyone from trying this.

I'm working on it. The only thing that sucks about search.cpan.org is the
search engine, which is a shame since that's the major part of it. Thankfully,
I have this really handy Perl search engine toolkit up my sleeve...

-- 
And it should be the law: If you use the word `paradigm' without knowing
what the dictionary says it means, you go to jail.  No exceptions.
-- David Jones

Re: Let's eliminate the Module List

[Andy Lester]

On Mon, Aug 23, 2004 at 10:43:38PM +0100, Nicholas Clark ([EMAIL PROTECTED]) wrote:
> Talk is cheap. Sadly none of this will get done unless someone with
> sufficient desire to do this creates themselves the time and does it.

I think that dropping 00*.html was a good first step.

> There is nothing stopping anyone on this list prototyping their own
> improved substitute for search.cpan.org. (although it helps if you have
> a public facing webserver if you want to show it to others).
> 
> Yet no-one does.

I'm working on it.  I've already pulled the minicpan (a la Randal's mini
mirror) and I'm working on the Template Toolkit-fu to make reasonable
pages.

If anyone's interested in helping out, let me know.

xoa

-- 
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

Re: Let's eliminate the Module List

[Mark Stosberg]

On Mon, Aug 23, 2004 at 10:43:38PM +0100, Nicholas Clark wrote:
> 
> There is nothing stopping anyone on this list prototyping their own
> improved substitute for search.cpan.org. (although it helps if you have
> a public facing webserver if you want to show it to others).
> 
> Yet no-one does.

Randy Kobes did:
http://kobesearch.cpan.org/

But apparently it's not sufficiently better or sufficiently well known
to come up in "future of CPAN" conversations much.

At least the code for it is easily available:
http://cpan-search.sourceforge.net/

It uses mod_perl and Template Toolkit.


Mark

--
 . . . . . . . . . . . . . . . . . . . . . . . . . . . 
   Mark StosbergPrincipal Developer  
   [EMAIL PROTECTED] Summersault, LLC 
   765-939-9301 ext 202 database driven websites
 . . . . . http://www.summersault.com/ . . . . . . . .

move to RT: Re: name for singlethreaded web server framework module (chatty)

[david nicol]

this discussion is getting into the details -- i guess I could
make a page for singlethreaded on Perlforge if it existed, or we
could move the discussion to rt, for instance

https://rt.cpan.org/Ticket/Display.html?id=7446

IMO it would be nice if RT provided an "announce" mailing list
for each queue.  It might have something like that already, with
the possiblity of receiving reports for new tickets created in
queues you have signed up for.

On Mon, 2004-08-23 at 11:33, Nicholas Clark wrote:

> Presumably generating pipes to helper tasks can be done with a module on
> CPAN? And is it really going to achieve faster non-blocking file IO on
> anything other than Unix (or Unix-a-likes) where there will be cat?
> 
> Nicholas Clark

version 0.03 now does partial reads on large files, keeping the
handles in a per-client array for reading from when the outbuffer
for that client gets small.  I guess version 0.04 will extend 
this to programs which will get opened into pipes, and do selects
on the handles to avoid blocking, since nonblocking is not portable.


-- 
david nicol
  "Someday, everything's going to be different
   when I paint my masterpiece."

Re: namespace for users and groups

[Sam Vilain]

David R. Baird wrote:
I think the treeness is quite important, because groups inherit the 
capabilities/permissions of their subgroups. So whenever you check if 
your own group is permitted to do something, you know that the tree-
like hierarchy of groups contained within your group is also being 
checked. 
 

"Group", by itself, infers no such treeness.  You may have chosen to 
model your groups and users by some close analogue of;

   
 +-+  +-+  ++
 | GrantableEntity |--|  Grant  |--| Entity |
 +++ 1  * +-+ *  1 ++
 /_\
  |
+---+   +-++
|   | * |  |
|* +-+ * * ++
+--|  Group  |-|  User  |
   +-+ ++

Unix Groups, for instance, do not bother with this, so "Group" doesn't 
mean "Heirarchy of Groups" in this case.

The problem with these such discussions is that such a wide variety of 
possible ACL structures are all used and called "ACLs" - though each can 
have a different arrangement of explicit or implied inheritance between 
security objects, and multiplicity of each relationship.  So, they have 
different properties, which is easy to see when they are expressed in 
UML, as above.

Some people even try to express one particular concrete form or describe 
a design-specific property, and call that structure the definition of 
the term.  In the end, as long as there is a virtual concept of 
controlling access, it can be called an ACL.  You could call Unix Groups 
an ACL mechanism, and it would not be incorrect.

UML is an excellent language with which to express the exact nature of 
the ACL that your module implements.  _*The Art of Objects: 
Object-Oriented Design and Architecture_, by *Yun-Tung Lau 
 
(isbn://0201711613/) uses ACL design as one of its worked examples.  
Highly recommended.

--
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

Re: Let's eliminate the Module List

[Randy W. Sims]

Andy Lester wrote:
On Mon, Aug 23, 2004 at 10:43:38PM +0100, Nicholas Clark ([EMAIL PROTECTED]) wrote:
There is nothing stopping anyone on this list prototyping their own
improved substitute for search.cpan.org. (although it helps if you have
a public facing webserver if you want to show it to others).
Yet no-one does.

I'm working on it.  I've already pulled the minicpan (a la Randal's mini
mirror) and I'm working on the Template Toolkit-fu to make reasonable
pages.
If anyone's interested in helping out, let me know.
Looks like you and Simon should collaborate. Is it possible or realistic 
for it to have pluggable search & browse engines. I still think 
sourceforge-like hierchical catagories (Topics) in META.yml would make 
for good light-weight search and improved by-catagory browsing (modules 
can list multiple catagories). There may be other usefull info in 
META.yml like OS Platform and requirements, etc that could be used in 
advanced searches. Also, some info might be pulled from cpanratings.

Web development is not my area, but I've been trying to remedy that. 
I've been trying to setup a local cpanratings to play with and hopefully 
do some work on, but it's going slow right now. When I do get up to 
speed, I'd be willing to do some work...

Randy.

Re: Which namespace for a build system?

[Randy W. Sims]

[ Actually, I'm going ahead and CC'ing the list because I'm going to 
suggest something that others will probably disagree with ;-) ]

Nadim Khemir wrote:

-Original Message-
Is this a build system for perl modules or a generic build 
system? Is it 
an application or a library? Is the documentation available; 
I'd like to 
learn more about it.

It' a generic build system aimed at replacing gmake, cons and the like. I'ts
a meta-build system, a nice name to tell that it is not complete :-). 
I'm going to suggest that it is reasonable for an "application" of this 
sort to have its own namespace. It has a very specific use, and it is 
not generally applicable to other perl apps.

I don't like the name PBS. Probably because, if you mention it anywhere 
in the U.S., people the of the "Public Broadcasting Corp", a publicly 
funded educational TV broadcasting network.

PBS is a set of modules that let you build a build system. Since it's
written in perl, you can add your own libraries and even have your own
syntax if you wish to but the "plain" syntax is perl and it looks rather
good and easy.
The best doc to start with is the presentation I gave at "perl nordic
workshop" the slides are on their site.
In the unix perpetual tradition, the documentation is the code. Seriously,
the documentation that is available is very old and very confusing. It was
my goal to re-document the system this summer but I simply didn't. As there
are only 2 or 3 users for the system and I know them, we haven't had the
necessity to document more (the system is easy to understand as it is rule
based). I want to release the system to see if there are other are
interrested and in that case I will write a proper documentation.
I can just about guarantee that it is not going to be used without some 
documentation. I suggest it is useless to post it without docs, and 
possibly a couple of samples.

PBS is  reseach project that turned wellbut I still want to do some research
(like iontegration between CM and build systems)
One advantage of PBS is that it is quite fun to use and build debugging is
one of the base for the program.
Hey, that's two ;-)

Re: Namespace for EUI related modules

[Randy W. Sims]

Suresh Govindachar wrote:
By the way, if you know of a script to fill out
https://pause.perl.org/pause/authenquery?ACTION=apply_mod
please point me to it.  If there is no such script, I will
be attempting to write one (using WWW::Mechanize?) -- I
trust there is no danger of me messing things up on PAUSE by
doing so.
Please don't do that. I don't see the need; you only fill it out once 
for a module. It will introduce the potential for abuse, flooding the 
system. IMO, It's a really bad idea.

Randy.

Re: Namespace for EUI related modules

[khemir nadim]

Hi,

"Suresh Govindachar" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hello,
>
> I defined the concept of an Editable User Interface (EUI)
> on www.sonic.net/~suresh/eui and illustrated it with
> an extensive application
> on www.vim.org/scripts/script.php?script_id=1052 .

Any other app you are aware of?

Cheers, Nadim.

Re: Which namespace for a build system?

[khemir nadim]

"Randy W. Sims" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I'm going to suggest that it is reasonable for an "application" of this
> sort to have its own namespace. It has a very specific use, and it is
> not generally applicable to other perl apps.
A build system is an app but a dependency system is not. Even if it was to
be classified as an app, I think we should have a root for build systems as
there are at least three or four modules that would fit there.

> I don't like the name PBS. Probably because, if you mention it anywhere
> in the U.S., people the of the "Public Broadcasting Corp", a publicly
> funded educational TV broadcasting network.
PBS is for Perl Build System, I thought about Perl Make System but it was
even worse. The leftish part of me like the idea of peoples money used to
educate them instead for entertaining them as in the Roman's time , Except
if your PBS is bad  of course.

> I can just about guarantee that it is not going to be used without some
> documentation. I suggest it is useless to post it without docs, and
> possibly a couple of samples.

Samples are not a problem and with the huge amount of perl modules not
documented or very poorly documented, it won't stand out ;-) The
documentation is high on my priority list. Just before a complete
refactoring to allow new types of optimizations (the third refactoring for
PBS)

> > One advantage of PBS is that it is quite fun to use and build debugging
is
> > one of the base for the program.

> Hey, that's two ;-)
Right. Let me know your opinion when you have had a look at the slides.

Cheers, Nadim.