Re: Namespace for EUI related modules
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: Let's eliminate the Module List
[EMAIL PROTECTED] (Randy W. Sims) writes: Looks like you and Simon should collaborate. We've been chatting. Is it possible or realistic for it to have pluggable search browse engines. I think so. There are three things at issue, all of which can and should be implemented distinctly: 1) Viewing the contents of packages 2) Browsing by category 3) Searching I have no desire to work on 1), since I think search.cpan.org does this very well. (Andy agrees with this idea.) I have no idea to work on 2), since I think that all browsing is a subset of searching - for instance, browsing by keyword is just doing a search for a particular keyword; browsing all modules is just doing a search for type:module, and so on. (Andy... well, tolerates this idea. ;) 3) is the thing I want to work on, and Andy wants to work on 2), so my plan for the time being is to index all the CPAN module metadata and link search results to the current search.cpan.org pages for displaying a given module. Then Andy can come along and turn canned searches into a browse interface on top of that. I still think sourceforge-like hierchical catagories (Topics) in META.yml would make for good light-weight search and improved by-catagory browsing I disagree quite violently with this, but I'm not going to implement searching and indexing in a way that precludes it. I think that the world moved from browse to search some time in the mid 90s (hell, we're even being encouraged to search rather than browse email these days) and that this is because browsing is useful if your search engine isn't good enough. Even so, I recognise that everyone who comes to working on CPAN metadata has their own conceptual axe to grind, so I'll just index whatever the heck is in META.yml and let everone else sort out the details. -- Using Outlook is like running barefoot through a hot ward snogging all the patients - Peter da Silva
Re: [unclassified] Re: Let's eliminate the Module List
Graham Barr [EMAIL PROTECTED] writes: Right. And a grand job he has been doing. I second this. For a while I've tried to do something sensible with the registry requests, but failed due to lack of response in times where feedback was needed (i.e., with ambigous or dubious requests). So _I_ decided to leave the module registration for what it is and only handle user ID requests, most of which brian handles as well, he's just quicker than me :-). -- Johan
Re: namespace for users and groups
On 24 Aug 2004 at 11:32, Sam Vilain wrote: 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. Yes, I see that. So I'm building one particular model of an ACL, so the module name should refer to that, so Tree is more relevant than Group in the name. My model would be more like (UML neophyte diagram coming up): +-+ | GrantableEntity | +++ * | | +---+ +-+ | | * | |* +-+ 1 * ++ +--| Group |-| User | +-+ ++ What I mean is, groups contain subgroups to arbitrary depth, groups have things they can grant, these things can be strings, coderefs, or methods, and users always have to go through their (probably single) group to get at their GrantableEntities. I don't think my module says anything about the relationship between grants and the entities they protect. I think you create these yourself and store them on the nodes of the tree. Having heard a little about various ACL schemes here, and skimmed a few of the Authen:: modules on CPAN, I doubt if my module will be much use for, say, plugging into an existing ACL framework or service. They have their model, I have mine. But if you have a multiuser app and you need a straightforward means of splitting users up and assigning access permissions to different aspects of your app, then my module, hopefully, would be an option. [...] 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. I had a lot of fun a few months back using UML for the first time to design things properly, it's a powerful tool, I'm still seeing the benefits today. I've been looking for the next textbook to read, looks like I've just found it! Examples in a domain you are actually working in are always great. I've applied to register the namespace Tree::Authz on PAUSE. A name can never communicate everything about a module, but I think that covers the essentials. A huge improvement over Admin::Group! Cheers, d. -- Dr. David R. Baird Riverside Content Management Systems [EMAIL PROTECTED] http://www.riverside-cms.co.uk
Re: Let's eliminate the Module List
On Tue, 24 Aug 2004, Simon Cozens wrote: I still think sourceforge-like hierchical catagories (Topics) in META.yml would make for good light-weight search and improved by-catagory browsing I disagree quite violently with this, but I'm not going to implement searching and indexing in a way that precludes it. I think that the world moved from browse to search some time in the mid 90s (hell, we're even being encouraged to search rather than browse email these days) and that this is because browsing is useful if your search engine isn't good enough. Browsing and searching each have their place. It is conceivable that a powerful enough search could emulate browsing. Consider how much discussion has been generated by talk of removing a browse-oriented document like the module list. Some people and activities are more fond of browsing than searching. It may only be 10% of the cases where browsing works better than searching, but if I want to answer the question - what are all of the perl web applications it would take lots of searches and result munging to find out what a painless browse could produce. A hierarchical system that people can add into META.yml supplemented by an effort to fill in the gaps left by maintainers not motivated to fix their META.yml would be a wonderful thing. -- /chris There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare
Re: Let's eliminate the Module List
On Tue, 24 Aug 2004, Simon Cozens wrote: Repeat after me: browsing is just searching metadata. For our current purposes I'm willing to go along with that. Once the metadata exists people can do whatever they want with it. I strongly suspect that one of those things will be making something that is vaguely yahooish. This brings to mind an interesting question - shouldn't there be some central file of meta data that's automatically generated? Maybe in Storable and XML? That way people that want to experiment don't have to have a full CPAN mirror or dig data out of all of the tar files. -- /chris There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare
Re: Namespace for EUI related modules
Khemir Nadim [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 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. On the vim.org site, others have released applications that use perl or python and can be executed from Vim; for example, there is a web-browser and (more than one) IDE. (There are also apps like a tetris game and a drawing tool but these only use the built-in vimL scripting language.) Anyway, once the EUI concept is widely understood, I expect that there will be development of more applications that use a text editor as their interface. Moreover, the EUI concept allows applications to be easily ported to different editors (not just VIM)! --Suresh
Re: Let's eliminate the Module List
* Fergal Daly [EMAIL PROTECTED] [2004-08-20 11:39]: So why not auto generate another list, giving keyowrds and descriptions of _every_ module? Particularly as that's not almost trivial to write. I've done that before -- http://www.perlmonks.org/index.pl?node_id=281203 f.ex, which is far from the only piece of such code I've written (most other stuff is unpublished though). If noone else has the time, I could probably cook something up in an evening, assuming I have specs on the repository structure (filesystem layout, what kinds of files I need to look at, etc). I guess I'd know that already if I'd ever set up a personal CPAN mirror, but I haven't. Regards, -- Aristotle If you can't laugh at yourself, you don't take life seriously enough.
Re: Namespace for EUI related modules
On Aug 23, 2004, at 2:42 PM, Suresh Govindachar wrote: 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 Assuming 'EUI' is the top-level namespace you settle on (might not be a great idea since it doesn't tell the user anything about what it is), you can just register 'EUI' and not the rest. The PAUSE bot will recognize the interior namespaces as yours by default. -Ken
Re: Namespace for EUI related modules
Suresh Govindachar writes: Hello, I defined the concept of an Editable User Interface (EUI) on www.sonic.net/~suresh/eui and illustrated it with I find the following paragraph a little bold in its claim: The graphical user interface seeks to replace actions by widgets (such as icons and items in menus) that can be pointed to and clicked at. The specificity of the actions represented by the ultimate widgets and the impossibility of dynamically combining the ultimate widgets leads to the proliferation of widgets in any moderately complex application's graphical interface (widgets can be combined statically into a new widget, but one cannot form mega-widgets as and when needed, dynamically, the way one forms commands from keystrokes). The graphical interface is very good for beginning users of applications who execute a few simple actions. However, the atomicity of a widget's action (minute graphical action unrelated to the application-related action of the ultimate widget) and the static nature of the widgets necessitate several point-and-clicks to achieve the ultimate goal; which binds the user to the perceptual level. Acme is an example of a GUI which allows the things you claim as an impossibility. You do exactly form mega-widgets as and when needed, dynamically, the way one forms commands from keystrokes. There are only 3 widgets in Acme (that I can think of right now anyway): * layout boxes which allows the manipulation of windows * scrollbars which allow the scrolling of windows * any piece of text which allows executing commands Since you can manipulate text (it is a text editor after all) you can dynamically manipulate that last widget to your hearts content. Also Acme seems to fulfil your Editable User Interface concept. In fact in a 1994 usenix paper [2] Pike describes it as a User Interface for Programmers, as opposed to a text editor. It is by design not just a text editor, but also a window system and shell. Being a plan9 program it communicates with other processes by being a file server, but the unix clone (Wily) does so via unix domain sockets, the paper describes what can be done via that interface. Of course anything that uses vi must be good, so please don't take this as criticism, just as pointers to a body of similar work. [1] http://www.cs.bell-labs.com/magic/man2html/1/acme [2] http://www.usenix.org/publications/library/proceedings/sf94/full_papers/pike.pdf -- Sam Holden
