2011/4/28 Jonas Smedegaard <span dir="ltr"><<a href="mailto:dr@jones.dk">dr@jones.dk</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Regarding upstream tarball releases: The description on your code being<br>
all contained in a single script unfolding itself automagically and<br>
therefore not needing common things like config file or documentation,<br>
really really worries me! That might be cool when you serve the code<br>
directly to your end-users, but un-cool when distributed by e.g. Debian.<br></blockquote><div><br>Of course, that's part of the packaging project - define what the system integration should look like and make sure PageKite does that and only that when used as a background daemon.<br>
<br>I've spent much of the last 15 years working as a sys-admin, so I know exactly what you are talking about. :-) I was just explaining why I don't have all those things already, the
tool has primarily been distributed as a user-space utility, not a
system component. I also realize that as soon as PageKite is packaged, the "API" of its command-line arguments, log-file format and overall behavior will have to remain backwards compatible as much as possible.<br>
<br>However, that said, at the moment the most popular use-case for PageKite is as a helper tool for web developers - not as a system-level background tool at all.<br><br>They use it interactively at the console, switching it on or off and potentially reconfiguring it many times a day. The same code-base is also used on Windows and Mac OS X, where expectations are quite different from those of a Debian sysadmin. That is where the "cleverness" comes in, trying to provide a good user interface for these users.<br>
<br>Obviously I would like it if debian packages could serve serve these users as well - not just sysadmins.<br><br>Perhaps we will want more than one package? One which provides just the tool for interactive use, and others which depend upon it and do different types of stable system integration. Eventually there will be a GTK-based GUI package as well. Expected 'roles' for pagekite are as follows:<br>
<br> 1) system-level tool for exposing a HTTP or SSH server to the Internet (back-end)<br> 2) system-level tool for helping others expose their servers (front-end)<br> 3) interactive tool for developers (interactive backend, cli)<br>
4) interactive tool for end-users (interactive backend, GUI)<br><br>Of these, 1-3 all exist and could be packaged, 4 is in development. 1 and 2 are potentially relevant to the FreedomBox project, those are probably the use-cases you had in mind when you became worried. :-)<br>
<br>I am not sure all of these roles really fit in a single package, as the requirements and behavior of each are quite different. One possibility is to package for 3), with configs for 1) included but disabled by default, and configs for 2) in /usr/share/docs/, and make 4) depend on that.<br>
<br>Another is to make them all separate packages, where 1) and 2) and 4) depend on 3).<br><br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Tools should be reliable, not clever. Not create config files<br>
automagically, but contain sensible internal defaults and/or fail if<br>
crucial config info is missing.<br></blockquote><div><br>At the system level yes, no argument at all.<br><br>As a user-space tool, the features will be there but the tool still won't even touch the file-system and change anything without being asked to by the user. But being able to save the configuration you've carefully constructed using a GUI or wizard or something is rather important, wouldn't you say? :-)<br>
</div></div><br>-- <br>Bjarni R. Einarsson<br>The Beanstalks Project ehf.<br><br>Making personal web-pages fly: <a href="http://pagekite.net/" target="_blank">http://pagekite.net/</a><br>