Re: namespace for users and groups
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)
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
Namespace for EUI related modules
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 text-editor.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::APP, EUI::APP::Task, EUI::Type and EUI::EDITOR. 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
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
[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
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)
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
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 http://www.amazon.com/exec/obidos/search-handle-url/index=booksfield-author=Yun-Tung%20Lau/102-5857950-6496945 (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
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?
[ 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 ;-)
