Hi Charlie, inline
On 8/7/07, Charlie Poole <[EMAIL PROTECTED]> wrote: > Some follow-up questions, now that I've looked at mono.getOptions. > > 1) I like the idea of having the system provide this capablility, > rather than including it in every app. But what do people generally > do for cross-platform stuff? > * package it with the app for windows only? > * package it with the app but ignore it at runtime on windows? > * package it and use the local copy on all platforms? > * build the source right into the app? > * something else? My experience on web apps, is to bundle all the binaries for the solution, as hosting providers don't let you install things in the GAC, as they hosts tenths to thousands of sites per server. On the Desktop, I've seen both approaches, depending on how well packaged/versioned the libraries are, put although the space cost, it's better to pack your binary dependencies with the program, especially for Windows, until some more universal dependency-resolving system, like LLuis is proposing can be relied to solve it. What I still find to be a hard task before us, is how such resolver, could gather enough information to be able to optimize versions. It is somewhat simple to use a library comparer like we use to maintain our status pages, to look for API-breaking changes, but without 100% coverage unit-test suites to assess semantical equivalence, one can't be confident that an upgrade is safe, also this is also a bit too restricting, as it looks at the whole API/behaviour spaces, it would be nicer to have subsets of interest, so that my app could say that it needs nunit basic testing features, but doesn't care about changes in the conditional-testing features. Obvously this is something to be assessed in each release of a package/app and kept in the dependency-resolver web-hosted database (or even in the distributed semantical web). but I digressed a lot. Back to your topics. > > 2) Has anyone tried creating a source-file based "light" version > of getOptions? One that could be used until a small app grew > to the point where it needed the whole thing? If not, I might > look at it. Well, never heard of it, and with mono Linker, you can do it directly in your binaries instead of having to dwell into Mono.GetOptions code. Nevertheless, you can do that, as the license for Mono libraries, including Mono.GetOptions permits you to that mostly anything with it. > > 3) NUnit is already using a similar, attribute-based approach > to options. The main drawback I see is with regard to localization. > Has anyone dealt with that issue? Well I never had the opportunity to address that, as Miguel asked for Mono.GetOptions API to be frozen, just when I was thinking of ways to do so. You can look in the archives, to see Miguel's motives. Basically the idea, would be to add another of the internal options that would you to extract either a gettext compatible base file, or a strings resource file, and use the appropriate mechanism to translate the descriptions (translating the options themselves, would make the scripts using the app not being shareable worldwide, what I don't think is a good thing) I've transfered the development of new GetOptions features to Commons.GetOptions (see http://monoblog.blogspot.com/2007/01/commonsgetoptions-sucessor-to.html part of my managed Commons initiative) but I must confess that I hadn't have alloted any time beyond the initial renaming/refactoring of the code, and never published it in any repository (I intended to do so as part of one of my projects at sourceforge, but I'm not sure anymore that it would be best place). See now I've chosen the Burroughs phrase to put in my signature below. Anyway, if you are interested, I can restart working on Commons.GetOptions, and package it in its own release and versioning policy. Hope it helps, -- Rafael "Monoman" Teixeira --------------------------------------- "I myself am made entirely of flaws, stitched together with good intentions." Augusten Burroughs _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list