We're actually writing the core so that it can be consumed by both GUI and CLI clients; pretty much everything is being written in this way so that we've got maximum flexibility.
As for abbreviations, I was thinking that exact same thing. I'll see about adding that sometime soon. We've got some plans around portable apps; I haven't yet actually documented how that works, but we've got a fairly good idea how it all works out. WinSxS can be used in an entirely portable fashion, I just have to sit down and do some proof-of-concept work to solidify exactly how that works out. I suspect this will be the exact same functionality that we'll need for Azure support. As for a middle ground for CLA ... as a requirement of the Codeplex Foundation, we require a CLA for people to work on new IP (code, docs, specs, etc) for CoApp. AFAIR, this is similar to the requirements that the Apache Foundation requires as well. It is notable; the CLA doesn't force a particular license for code contributions. Our chosen license is ASL 2.0 However, as for contributing back to existing projects (via the 'shallow-fork' model) for packages that the CoApp project is working with, no CLA should be required, and contributions to those should happen under whatever license model the original project is under. We definitely don't want to muck with that! Perhaps we'll create a "Forker" role :D And you are correct--we do have plans ensure there is a concerted effort to supply appropriate end-user and developer documentation. The CC license sounds good to me. G -----Original Message----- From: coapp-developers-bounces+garretts=microsoft....@lists.launchpad.net [mailto:coapp-developers-bounces+garretts=microsoft....@lists.launchpad.net] On Behalf Of m...@distasis.com Sent: Tuesday, June 29, 2010 7:11 AM To: coapp-developers@lists.launchpad.net Subject: [Coapp-developers] misc There were 3 topics I wanted to bring up for possible further discussion while things are still in the planning stages. The first was to ask that there would be a command line interface for any tools that would be created. Just read the post about cli command syntax, so hopefully that topic's covered. Thanks for making sure there's a command line interface. Doing things the Windows way doesn't necessarily mean using a GUI. I don't think preference for command line versus GUI is operating system specific. My guess is it has more to do with factors like whether a person is better at learning visually (seeing a video of how it's done) or text/orally (reading a manual) and how fast typing speed is versus mouse clicking speed. So, thanks for any command line interfaces you can add to the project. Also makes it easier to write different GUI front-ends with different libraries to change look and feel easily and use the command line tools to do the actual work. I looked over the suggested commands for the CLI. Just wanted to add the suggestion that maybe there could be a way to abbreviate commands. For instance, you can type: CoApp-cli install package_name It might be nice if you could shorten commands as long as they're still unique, so you could also type: CoApp-cli i package_name I like the part about wildcards with the package_name too. Second topic, was about installing software. I remember reading on the wiki that the installer would use the MSI format. Not that familiar with the format (usually prefer zip files and tarballs). However, can't help wondering how applications like portable apps (programs that run on removable drives or flash drives) will fit into the picture. Removable drives fill a nice niche between cloud computing and having everything local to one machine. You can take your programs and data with you anywhere to any Windows system and work. If the install program ends up tying a program to the registry or expecting it to be on a particular drive at all times, it'll make it difficult to use the applications provided by CoAPP as portable apps. It would be nice if CoAPP could host portable apps alongside regular applications that tie in to the registry and use helpful Windows features like defaulting file extensions to a particular program. Has any thought about how to handle a typical portable app (a program that's meant to be installed to a flash drive or removeable drive) within the project? Third topic, I read through the governance information at: http://coapp.org/Getting_Started/CoApp_Project_Governance Would like to suggest adding one more community role, something possibly between a user and contributer. Is there any way to add a role for people who want to contribute but may not want to work with the Contributor License Agreement? I think it may attract more Free and Open Source software developers if you had another category for contribution listed. Since the libraries and programs the project is building are Open Source and already covered by typical Open Source licenses, it wouldn't be that much of a stretch to let developers contribute under an Open Source licence rather than the Contributor License Agreement at the site. Personally, if I'm going to contribute patches to something that's licensed under GNU GPL, I'll license my patches under the same GNU General Public License just to avoid licensing conflicts. I think if it's possible to add one more category for developers who want to contribute to the project, but use a compatible Open Source license instead, that would attract more developers. I'm not specifically thinking of the build tools the CoApp project is working on, but for contributions to building the Open Source itself and to patches needed to get the code to work on Windows if it doesn't already. Also, the most overlooked part of a project is often documentation. CoApp project members might need to come up with documentation to explain how to get and install software that's built by the CoApp project. Might also be nice to store documentation that project members come up with on how to work with some of these Open Source applications that are being built (especially if it can be oriented to Windows users specifically too). Maybe something like a Creative Commons license for contributing documentation would be a useful option too. Sincerely, Laura _______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
