I apologize if there was some earlier context to thread that I am misssing and which might help me make a more meaningful reply. I am traveling and am a few hundred e-mail messages behind, but happened to see this at the top of the stack and couldn't resist replying!
We have conducted a couple of surveys to gather inputs from the community to the GT.M team. I am not comfortable sharing the results for competitive reasons (I know it's nothing personal, but there are at least a couple of folks out there who would like to see me calling at the local unemployment office). But I will say that I try to stay connected with the community, and we take community input seriously. For example, there is now a $Increment() in GT.M as a result of 2004 survey input. The recent functionality to be able to deploy a GT.M provided service under inetd/xinetd came from community input, although not from the 2004 survey. The GT.M Group operates as a classic open source business in that we provide services for hire (even within Fidelity, we have specific development projects funded by other internal organizations, in much the same way that we can have funding from the external organizations for development). Money talks, and when you have bills to pay, it talks pretty loudly. If there are specific enhancements that are worth it to people to have, please do contact me offline. We will also be happy to consider enhancements developed by the community - again, please write to me directly. -- Bhaskar -----Original Message----- From: [EMAIL PROTECTED] on behalf of Michael Zacharias Sent: Thu 10/6/2005 12:34 PM To: hardhats-members@lists.sourceforge.net Cc: Subject: Re: [Hardhats-members] Language extensions in GT.M - a possibility? a necessity? a bad idea? i would like to add to this. some time ago, i took part in a FNF sponsered survey on what features, progress , direction gt.m users would like to see in gt.m. i was wondering if bhasker would be able to share the results of this survey. also further greg's thoughts, is it necessary to extend gt.m or use gt.m as an implementation language to create the kind of extensions found in a product like cache. what specifically comes to my mind is something like esiobjects... michael --- Greg Woodhouse <[EMAIL PROTECTED]> wrote: > I know this is a very general question, but given the level of interest > in language extensions, I wonder if extending GT.M beyond the existing > ANSI standard is a possibility. Of course, updating the standard is the > most desirable course, but is that an option? > > Implementations such as Cache' offer extensions to the language that > are now verboten in VistA, and given the community's interest in > running VistA on GT.M, I would not want to see changes that were > incompatible with GT.M. > > > === > Gregory Woodhouse <[EMAIL PROTECTED]> > > > > "Without the requirement of mathematical aesthetics a great many discoveries > would not have been made." > > -- Albert Einstein > > > > > > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Hardhats-members mailing list > Hardhats-members@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hardhats-members > __________________________________________________________ Find your next car at http://autos.yahoo.ca ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
<<winmail.dat>>
