Danek Duvall wrote: > On Tue, Nov 25, 2008 at 03:55:17PM -0600, Shawn Walker wrote: > >>> server/api.py: >>> - In general, this looks nice, though I'd question why this is being >>> done >>> as a separate module, rather than massaging the underlying modules to >>> do the right thing. Adding a layer to fix problems in lower layers is >>> wrong. I suppose it's just a matter of running out of time? >> I'm not sure I understand you here. My whole purpose in creating the >> server API was two-fold: >> >> 1) provide a stable interface to the request, catalog, and configuration of >> the server that unknown clients (i.e. random user) can use in templates >> >> 2) abstract away and hide various parts of the api that shouldn't be used >> by anyone but the server internally (i.e. destroy_catalog, etc.) >> >> 3) prevent major internal changes from breaking template consumers or allow >> us to completely change the web back-end (i.e. BaseHTTP to CherryPy) >> transparently >> >> I thought these were the same reasons that moved us to create a client API. > > They are. I just think that adding a layer to do this, rather than simply > doing it in the existing layers, is the wrong way to go about this. I'm > simply registering my dislike of the method, just like I did for the client > API. I don't expect to win this argument, either.
I actually agree with you, and I would have preferred to do it in the existing layers. I was just following the client API philosophy. RequestInterface is the only problematic exception; I really don't want to expose our underlying "web server" to clients. >> Remember that the templates provided by the depot are completely >> customisable, and it is intended that anyone can write their own set of >> depot facing pages using the API provided instead of relying on ours. > > True, but that doesn't mean that we're opening it up for other people to > use right now, either. I could see that. I'm willing to change this at a later date to use the existing layers for the configuration and catalog. The RequestInterface is the only I'd want to keep. >>> Is there a standard way for editors to recognize a file as a mako >>> template? >> None that I've found. I did find a vim syntax thing for Mako, but I've >> had to do "set ft=mako" each time I edit a file. It's annoying. > > Hm. Perhaps putting "# vim: ft=mako" down at the bottom would work, but > that's a bit annoying. If there's no standard header or footer in the > file, or filename extension that indicates mako, then that would be the > best we can do. :-/ There isn't any standard header, footer, or file extension sadly. >> Note that the '-*- coding: utf-8 -*-' line at the beginning tells Mako >> what the encoding of the file is -- it isn't for vim. > > It could be both, of course, if the mako syntax file chose to read that. > But this is *well* beyond the scope of the code review. :) Whatever works, I'm open to suggestions. Thanks for your feedback, -- Shawn Walker _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
