> > I've no objection to creating a full-blown script language, or using an > existing extension language, but... Just hobbling a short list of > actions together, with no iteration or conditionals, which include the > ability to run external programs, piping or not piping the message > concerned, does it for me (oh, yeah, also the filter stuff!). The
> external programs can be written in any language the user desires, from > shell scripts to C++. They can be interpreted or compiled. It don't > matter. And as to the machinery that lies beneath this s-exp stuff, or > whatever it'll "evolve" into (pardon the pun), well, the better > organized, the more partitioned, the better off everyone will be, of > course! Well just being able to do these things with filters is a completely separate issue. For many people, that would be enough, for others, they would like more. e.g. how about a bunch of buttons that create automated replies for a support team? Or a myriad of other functions. If you do this by adding code to do this, and then adding a button to run it, you end up with a large pile of uncustomisable code - and a monolithic, giant, bloated application. If you do this by having a flexible, externally configurable customisation environment, anything is possible. 'reply to all' can be made to be 'really all' if you care about it, without having to edit some messy, arcane code, and rebuild a 10MB application. Anyway, I can't personally see any of this happening for quite a while, if ever. > There's plugins, dynamically loaded or not... the already mentioned > spawning an external process, with or without pipe... various compile-in > interpreters for already mentioned languages.... > > Your problem with a scripting language will be: > > 1. if you choose scheme or python or perl or VB, or whatever, a good > number of users will complain because they "have to learn a new > language". For the mass market, I'd guess this would be way out of the > reach of 98% of the user base, who won't know ANY language. And won't > want to, either. They also will probably not care either. The thing about scripting is you can then get contributions of features they can use without having to know how it works, or can pay someone to creat them for them. e.g. i use a lot of stuff in emacs, but i've only ever written a single emacs macro. > 2. And, if you create a NEW language, well, now, 100% won't know it! Just one reason I dont think doing anything more sophisticated with the filter gui/s-exp engine is a good idea, it becomes its own language, whereas now its just an expression really. > I guess what I'm saying is, that you should go ahead and pick an > extension language, but... the "sexp" interface needs to be there too, > because you want the mass-market, and those folks won't touch any > programming language. Period. The "advanced" users will play around with > the filters and this s-exp action-list stuff, if you make it an option. The gui that builds in-line code, sure, the s-exp mechanism i'm not so sure on. But that gui could be used to generate almost any scripting language with little or no modifications - you just need new template 'program fragments' in an xml file. > Oh, yeah, you'll also want to make it so you can export/import filters, > command lists, etc. Users may want to "share" with co-workers, archive > them, etc. Hmmm, Outlook users can't export/import their Rule Wizards, > can they? mail [EMAIL PROTECTED] < ~/evolution/filters.xml > I'll say no more. You guys have done a great job with Evolution, and > you'll no doubt have ten times better ideas than I would. > > murf > > > _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
