On Mon, Apr 11, 2011 at 2:56 AM, Ionel Maries Cristian <span dir="ltr"><<a href="http://ionel.mc">ionel.mc</a>@<a href="http://gmail.com">gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font face="trebuchet ms,sans-serif">Hello,<br><br>I have few comments:<br></font><ul><li><font face="trebuchet ms,sans-serif">That file layout basically forces you to have your development environment as close to the production environment. This is especially visible if you're relying on python c extensions. Since you don't want to have the same environment constraints as appengine it should be more flexible in this regard and offer a way to generate the project dependencies somewhere else than the depeloper's machine.<br>
</font></li></ul></blockquote><div>Yes; in this case in Silver Lining I have allowed non-portable libraries to be declared as dependencies, and then the deployment tool ensures they are installed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<ul><li><span class="Apple-style-span" style="font-family: 'trebuchet ms', sans-serif; ">There's no builtin support for logging configuration.</span></li></ul></blockquote><div>This would be useful, yes; though I think the format itself would mostly want to declare how it logs and then deployment tools could try to configure that. E.g., it would be useful to have a list of logging names that an app uses. The actual configuration is deployment-specific, so shouldn't be inside the application format itself.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><ul><li><font face="trebuchet ms,sans-serif">The update_fetch feels like a hack as it's not extensible to do lifecycle (hooks for shutdown, start, etc). Also, it's shouldn't be a application url because you'd want to run a hook before starting it or after stopping it. I guess you could accomplish that with a wsgi wrapper but there should be a clear separation between the app and hooks that manage the app.<br>
</font></li></ul></blockquote><div>In Silver Lining you can also do scripts; I started with URLs because it was simpler on the implementation side, but scripts have generally been easier to develop, so at least the default could be revisited.</div>
<div><br></div><div>At least in the case of mod_wsgi there isn't a very good definition of shutdown and start. There's the runner itself, that imports the WSGI application -- this is always run on start, but it's the start of the worker process, not necessarily the server process (IMHO "starting the server process" is an internal implementation detail we should not expose). Silver Lining also tries to import a silvercustomize module, which is kind of a universal initialization (also imported for tests, etc). atexit can be used to run stuff on process shutdown. I don't really see a compelling benefit to another process shutdown technique. It seems perhaps reasonable to have something that is run when the actual application instance is shut down, but I've never personally needed that in practice. Of course other configuration settings could be added for different states if they were reasonably universal states and there was a real need for those.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><ul><li><span class="Apple-style-span" style="font-family: 'trebuchet ms', sans-serif; ">I'm not entirely clear on why you avoid a build process (war-like) prior to deployment. It works fine for appengine - but you don't have it's constraints.</span></li>
</ul></blockquote><div>In my own experience with App Engine I found it to be a useful constraint -- it was not particularly hard to get around (at least if you understand the relevant tools) and while App Engine has annoying constraints this wasn't one of them. Of course I couldn't use lxml at all on App Engine, and I agree we shouldn't accept that constraint, but for the majority of libraries that are portable this isn't a constraint.</div>
<div><br></div><div> Ian</div><div><br></div></div>