PowerShell compatibility I think is pretty important. Luckily, that just means 
building nice libraries in .NET and making sure they work for PowerShell.

Basically, I'm thinking that the vast majority of the functionality on the 
client is bound up in some well-documented libraries, which would be usable 
from a variety of languages (.NET, native, PowerShell, etc.)

The UI and console apps would be written using that.

Garrett Serack | Open Source Software Developer | Microsoft Corporation
I don't make the software you use; I make the software you use better on 
Windows.

From: coapp-developers-bounces+garretts=microsoft....@lists.launchpad.net 
[mailto:coapp-developers-bounces+garretts=microsoft....@lists.launchpad.net] On 
Behalf Of Kevin Moore
Sent: Friday, May 07, 2010 12:01 PM
To: coapp-developers@lists.launchpad.net
Subject: Re: [Coapp-developers] What packages do you want to see?

May I extend your user story, Trent?

I got to the command line.
I type: coapp search ruby
I see: a list of ruby packages, including MRI, jRuby, IronRuby, etc. Each lists 
their latest version.
I type: coapp info ironruby
I see: A description of IronRuby. The available versions. A pointer to their 
source code on github.
I type: coapp install ironruby
I see: the installation prompt for the latest 'official' install of ironruby. I 
could also install older versions, or maybe beta/RC versions by specifying the 
--version flag

If this was all PowerShell compatible, it would be easy to do fun piping, 
filtering, etc of this output. It could also serve as a great basis for GUI 
tools.

On Thu, May 6, 2010 at 23:50, Trent Nelson 
<tr...@snakebite.org<mailto:tr...@snakebite.org>> wrote:

When a developer consumes a shared library (say, zlib), they consume the 
library by binding to a library that is identified by NAME, PLATFORM (x86/x64), 
VERSION and PUBLICKEYTOKEN ... the publicKeyToken is derived from the public 
key of the signing certificate.

So, if the publisher of zlib wants to publish one for VC9 and one for VC10 they 
have to have two authenticode certificates.  A bit of a pain, yes. But we can 
have the same version of the library installed for multiple compilers at the 
same time, and never have a conflict.

                Ahh!  That's a great solution!

Boost immediately comes to mind as a project that intrinsically supports being 
built in all sorts of ways (different compilers, optimisations, etc), so the 
publicKeyToken approach will work very well, IMO.

....and here's some thoughts out loud:

New user story:
I'm a Windows developer that wants to consume a bunch of CoApp projects.  I 
need to know all of their NAME, PLATFORM, VERSION and PUBLICKEYTOKEN details 
with minimal fuss (I don't want to go to each project's website and have to 
find the details individually).

I'd like to go to http://use.coapp.org, be presented with a Google-like 
minimalist page; search box and not much else.  I'd like to type in `python 
boost apr zlib libpng` and then be presented with search results that clearly 
depict the latest versions of each, with NAME/PLATFORM/VERSION and 
PUBLICKEYTOKEN details readily available.  For projects with multiple builds 
(i.e. Boost), and thus, multiple PUBLICKEYTOKENS, I want clear descriptions of 
which build does what.

                Follow on questions:
What do I do with this information when I get it?  Do I plug it into an XML 
file that gets consumed/processed by the CoApp tool chain?  If so, couldn't 
http://use.coapp.org just generate the XML file for me?  i.e. after I type in 
the projects I want, I get search results with check boxes; I tick the ones I 
want, press a 'Generate' button, and wallah, I get my XML file that describes 
all my dependencies.



_______________________________________________
Mailing list: https://launchpad.net/~coapp-developers
Post to     : 
coapp-developers@lists.launchpad.net<mailto: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

Reply via email to