On Sat, 2004-02-14 at 15:00, Jeffrey McManus wrote: > Hey team, <snip/> > - Do you have good evangelism tactics for Linux developers who evaluate > Mono and find it somehow "un-Unix-like"?
I don't, except to answer their questions... > - Is there a technical answer to the "mono my.exe" command-line objection? Yes. There are two solutions: 1) Use a shell script which calls the actual program. I've found this script to be useful: #!/bin/sh # Starts a CIL program whose name is patterned after the # filename of this script. The CIL program executed is # "$0".exe. file=$0 # If file is a symlink, find where it's pointing to if [ -L $file ] ; then if ! (readlink -f "$file") > /dev/null 2>&1; then echo `basename "$0"` ": missing required program readlink!" exit -1 fi file=`readlink -f "$file"` fi exec mono "$file.exe" "$@" 2) Use the Linux BINFMT_MISC kernel module. Then you can remove the ".exe" extension on the binaries, and still execute the programs normally. See: http://www.atoker.com/mono/, and search for BINFMT_MISC. In particular, the "mono.init" script can be used to set this up. > - Is there an elegant solution for distributing the Mono framework onto > client machines today? Other than RPM and Debian Packages? *Is* there a more elegant way to distribute *any* software? ;-) (Yes, this is a biased view, but Linux binary package management is fairly elegant, especially when using apt or yum systems.) However, this will depend upon what your client machines are. Does mono support them? Does Mono support them *well*? (Mac OS X isn't supported well at this time, and people frequently have problems building Mono on Windows...) > - Are there examples of functioning high-performance client/server apps > running on Mono today? I'm not aware of any, but I wouldn't know, either. <snip/> <digression type="major"> However, with regards to your particular situation, I think you might be going about this the wrong way. Mono may be the perfect choice. It might not be. And trying to get all developers, both internal and external, to agree to a single choice will be difficult. Which is why you shouldn't be making it. :-) This is *precisely* what SOAP and Web Services are for. What the client is implemented with, and what the server is implemented in, is immaterial as long as they both understand the same transport: SOAP. This would permit your developers to continue developing in a language they're comfortable with now (C++, apparently), and change strategies tomorrow without breaking any existing clients. You have the current scenario: "Maintainability and developer productivity is a big deal with custom eBay clients that use the API because eBay changes so frequently." There are two solutions: choose a more efficient development environment, which you seem to be advocating. While possibly an ideal solution, it is entirely possible that the new environment can't/won't be supported in all the areas current programs operate, or future required platforms. Furthermore, the more custom clients you have, the more work you will need to do if something changes, and just emphasizing a more efficient development environment will likely also emphasize making changes that will require updating all the existing clients, "because it's easy, so why not?" The other solution is to do some up-front design. It sounds like you've had several designs so far, so I would hope that your developers understand the problem domain sufficiently to create a decent design. With that design, decompose the system into layers, and pick a communication strategy between layers. As long as the interfaces between layers are consistent, the actual implementation can change ad hoc, and (done properly) no existing code will need to be touched. There's a reason that the networking protocols have remained consistent for nearly (over?) 20 years, and it's not because of an "efficient development environment." :-) This can be done with the efficient development environment. But this also allows you to make concessions to interact and integrate with environments that might not support Mono (or the chosen environment). It can also allow quick prototyping -- prototype the GUI in Python, for example, to see what works, before re-writing in some other language. With decent interfaces, Python will be able to function within the actual working system, and you may well find that Python is sufficient. Developer familiarity is also key. C# may be an easy language, but there's still a learning curve associated with it, and it may be more efficient to let the developers stay within their more familiar language. There's no reason that C++ can't be a decent development environment, AS LONG AS modern C++ techniques are used (templates, exception-safe code, NO POINTERS -- that's what std::vector and std::auto_ptr is for, etc.; failure to do so will lead to madness, which I've had to deal with far too often in "legacy" code...). The proper solution is *always* a decent design. Getting a decent design can be difficult, I'll freely admit, as it requires experience in the problem domain. But if your developers don't have enough experience in the problem domain by now, after making (apparently) frequent code/design changes to the entire system, you have larger problems than an inefficient development environment. </digression> - Jon _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list