* Shawn Walker <[EMAIL PROTECTED]> [2008-04-16 03:15]: > On Tue, Apr 8, 2008 at 12:46 PM, Stephen Hahn <[EMAIL PROTECTED]> wrote: > > * Amit Kumar Saha <[EMAIL PROTECTED]> [2008-04-08 17:16]: > > > > > Hello, > > > > > > On 4/8/08, Shawn Walker <[EMAIL PROTECTED]> wrote: > > > > Greetings, > > > > > > > > Something I would like to know is whether any plans have been > > > > developed yet to further develop the web interface that the ips > > > > repository currently provides? > > > > > > > > I would love to see ips provide a rich, powerful web-based interface > > > > for administrators and users alike in addition to the cli and gui > > > > interfaces being developed. > > > > > > IMO, a definitely desired feature would be, search for/in packages. > > > > I think web-based search would be interesting and would be helped by a > > better browsing interface. (Some progress in search is dependent on > > making progress on the tag/attribute discussion.) I have a > > preliminary changeset that provides an Atom feed of the catalog > > updates that would be nice to see finished. I'd like to see work on > > the intent and statistics side, too. > > > > Dan and I were kicking around how we might use either a templating > > system, like > > > > http://www.makotemplates.org/ > > > > or even one of the lighter frameworks, like > > > > http://www.cherrypy.org/ > > > > to make it easier to flesh out pkg.depotd's reporting capabilities. > > >From what reading I've done, cherrypy and mako complement each other. > cherrypy provides the web framework, and mako is best suited as the > template system on top ( http://www.cherrypy.org/wiki/intro/1 ) Yes, that's right.
> 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. > > It might be interesting to examine package publication via a web form, > > but that's contingent on work on pkgsend(1) itself, probably the > > initial SSL support Krister and I are wrapping up, possibly the > > challenge-response protocol I outlined in an earlier thread, and > > examination of how to provide per-package and per-operation > > authorization. > > > > I'm less keen on a full-blown administrative web interface at this > > time, but maybe I'm missing something. > > To me, a web interface to administrate the server can be quite > convenient if done right. > > I'm somewhat torn though as to how far it should go. > > 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. > 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). > 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. - Stephen -- [EMAIL PROTECTED] http://blogs.sun.com/sch/ _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
