On Tue, Apr 22, 2008 at 11:20 AM, Stephen Hahn <[EMAIL PROTECTED]> wrote: > * Shawn Walker <[EMAIL PROTECTED]> [2008-04-16 03:15]: > > My main concern with python web Frameworks, like cherrypy, is that > > they have a long way to go performance wise: > > > > http://osdir.com/ml/python.cherrypy/2004-02/msg00008.html > > http://www.cherrypy.org/ticket/571 > > > > That's somewhat concerning, though in the prototype stage, it may > > matter little as the rapid development aspect is more valuable. > > No, we probably need to stay restricted to templating first.
That is agreeable to me. > > I would love to see some sort of interface that lets you browse and > > pick packages for installation in a more interactive fashion than the > > cli can provide. > > > > Since many of the software packages will likely have URLs, etc. > > relating content; it seems like a great match. > > So, there are a few ways to do this, but they all require work. :) > > You can go down the MIME type path, and make a little "package > descriptor" file that triggers some external application (like pkg(1) > or packagemanager(1)). Or you can make an actual plugin that is > triggered by embedded content of that MIME type. Or you can > investigate a browser extension, and make the raw pkg: URIs trigger > that additional software. > > One key point: you must let the user pick the image in which the > indicated package will install. You've actually touched one of the mini-projects I was considering implementing: a FireFox extension to make it possible to click a raw pkg URI and have it trigger the GUI install process. I had not considered the image in which to install, though in retrospect, that makes perfect sense. > > Obviously there are many security concerns, but the initial > > development could focus on basic repository browsing and package > > publication. Later on, administrative possibilities could be pursued. > > That sounds good. I suppose my main point is that the set of > administrative operations on the server itself is expected to be > small; the more interesting bits are either in the service properties, > or possibly in the Apache/other web server (in some configurations). If I understand you correctly, the desire is to keep the web-interface presented here strictly related to informational purposes, and possibly package publication, since administration of the repository server itself would be performed through some other method. In that case, I'll restrict my efforts to those areas. > > Is the server/config.py module seen as the best place to integrate > > this interface, or is another, separate process more desirable for > > other reasons? > > server/ is the right place. You may wish to refactor config.py and > face.py. Great. I will file appropriate bugzilla entries soon and document a possible plan of action. Cheers, -- Shawn Walker "To err is human -- and to blame it on a computer is even more so." - Robert Orben _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
