Hi Paul, Thought you might comment on this ;-)
Although .NET may have it's fine points, there's one point to make that you seem to miss. Not all MapInfo users have a need for or interest in MIPro8. So a COM model for MIPro 4.1-7.0 would fill a gap regardless of v8/.NET. There's been a lot of talk on this list about the lack of real improvements in latter versions, and many are still stuck on 5.0-6.5. They would still be able to benefit from something less than .NET. .NET is still (just) one standard, not a strict requirement. And I've said it frequently before, and I'll say it again: MapX is just an enhanced CAD component, imho ! MIPro's strength comes from it's table centric view. Adopting MapX's map centric view in MIPro is a mistake, and will degrade it to the level of all the GIS/CAD hybrids. I still hope something better's coming up, I was actually consulted about this a year ago. Nevertheless I fear that you may be correct, which in my judgement will ultimately doom MIPro. A shame you can't share the work you've done. I'll be happy to share notes if you want, although I assume participation on your part in any development is out of the question. Best regards/Med venlig hilsen Lars V. Nielsen GisPro, Denmark http://www.gispro.dk/ http://hjem.get2net.dk/lars-online/ WGS84: 10.20'40"E 55.20'20"N ----- Original Message ----- From: "CRISP, Paul -Syntegra UK" <[EMAIL PROTECTED]> To: "MAPINFO-L Mailinglist" <[EMAIL PROTECTED]> Sent: Thursday, March 20, 2003 10:45 AM Subject: RE: MI-L MI/MB developements + a proposition > Lars > > I have also been working on a COM style object model for MapInfo for some > years - covers I reckon 80% of the MapBasic functionality now. Its live > software though and paid for by my employers so I can't hand it over, even > fyi. Sounds like we're on similar lines though and it would be interesting > to compare notes. If an idea is good enough it usually ends up in the > product in the end. My feeling is that the forthcoming .NET stuff will make > it unnecessary to pursue this unless there are gaps in the new MI object > model. This may well be the case - the MapX model is the most likely clue as > to what to expect and that allows you to send in MapBasic statements in some > cases. > > > Paul Crisp > > Syntegra > Innovation Place Delta Bank Road Newcastle NE11 9DJ > Tel 0191 461 4522 Fax 0191 460 1987 > > > -----Original Message----- > From: Lars V. Nielsen [mailto:[EMAIL PROTECTED] > Sent: 19 March 2003 19:42 > To: MAPINFO-L Mailinglist > Subject: Re: MI-L MI/MB developements + a proposition > Importance: High > > > Hi, > > Being a MapBasic programmer since version 2.0 (oh yes!), I've spend many > happy hours Mb'ing :-) And seing that era coming to an end > is not easy, and I agree with Ben Crane that MI/MB will probably not die out > for a few years. Just look at ArcView, it's still > kicking even though ArcMap was released years ago. But I don't think we > should kid ourselves either - MapInfo Corp. will dump > MapBasic eventually, they'll simply have to to stay on the MS bandwagon. > > One idea that comes to mind is perpetuating MapBasic outside MapInfo, > perhaps as an Open Source project. MapBasic programs could > (almost) just as easily be run via a COM/.NET application from outside Pro > than from inside (_if_ the data compatability is kept > intact and _if_ the Pro object model is well designed !) However, that would > require for MapInfo Corp. to release all relevant specs > for mbo/mbx (who should we ask to for this ?), and even then I'm not sure > whether enough dedicated developers are willing to > shoulder the task. > > The idea proposed by Darrin Clement about a symbolic subscription fee to > continue MAPINFO-L is intriguing, but unfortunately I can't > see the economics of it as sound. Even for a fee of $10 per year it would > require several hundreds of paying subscribers to even pay > for a single man-year per year. And the strength of the current list is that > it features not one but many experts. And paid-for > solutions are usually also subject to support issues, which would increase > the need for funding. This forum can only continue on > it's current voluntary basis, imho, so I think we should get the most of it > as it is. > > But there may be an alternative route to MB, so let me make a proposition. > > I've been working on-off and off-shift for more than a year now on a VB/6 > project I call MIProxy. The project involves building an > external COM object model for MIPro 4.1-7.0, publishing a full featured > object model for external programming languages while > working internally with the very limited object model the current MIPro > itself publishes. I haven't been able to give it the time it > deserves, so I'm willing to turn this project into an Open Source project if > anyone's seriously interested in helping out with the > development. The project's currently about 95% finished including docs, but > needs some serious alpha/beta testing. Sofar it doesn't > support feature objects, but that may become possible if more hands are at > work - I have some ideas. > > So please contact me if you're a "medium hard core" ;-) VB/6 programmer with > an interest in COM'ing the current MIPro. > > Best regards/Med venlig hilsen > Lars V. Nielsen > GisPro, Denmark > http://www.gispro.dk/ > http://hjem.get2net.dk/lars-online/ > WGS84: 10.20'40"E 55.20'20"N > ----- Original Message ----- > From: "Jacques Paris" <[EMAIL PROTECTED]> > To: "MIL" <[EMAIL PROTECTED]> > Sent: Tuesday, March 18, 2003 3:23 PM > Subject: MI-L MI/MB developements > > > > The recent wish list discussion reopened an old concern of mine that I > will > > sum up to present to you and have your feed back. > > > > 1 - I am pretty convinced that MI will not put much efforts into > supporting > > and developing its MI Pro beyond 7.0 in its present format. The move to > .net > > structure will create a rupture in the working environment and in the > > framework for developing applications. > > 2 - There will be for several years many MI users who will continue to use > > versions <=7.0 because they fit their needs or because updating to the > > latest one (to come) would not be $$$ justified. > > 3 - There are several, not to say many, among us that have a certain > > knowledge ob MapBasic and find pleasure at building applications or tools > in > > that language. > > 4 - The creation of new tools seems to be more in reaction to "personal > > inspirations" than in answer to some "organized coverage" and potential > > programming resources are misused with frequent duplications and > > re-inventions. > > 5 - Wish lists do not generally differentiate between "internal" > > improvements (achievable essentially through internal programming) and new > > "tools" that can be created as external resources. Beside, they do not > offer > > follow-up to wishes > > > > > > I believe that we could set up some organization to improve on that > > situation. For sake of expediency I offer an acronym: MIP-TPF that someone > > could read as MapInfo Professional - Tool Programming Forum. I would give > it > > immediately the following tasks: > > > > A - recording wishes for tools > > B - establishing if no solutions already exist (and their availability) > > C - sketching specifications for new tools required > > D - recording the resource who would take the responsibility for > developing > > a specific tool > > E - recording the progress in new tools availability > > > > I would also consider adding later on the tasks of > > > > F - identifying existing tools and their accessibility > > G - reviewing existing tools and making recommendations to the users and > to > > their authors > > > > In order to make programming easier and more daring, I would add some > modus > > operandi considerations > > > > I - the MIP-TPF should be inspired by the terms of the Lesser GNU General > > Public (Lesser GNU General Public License page at: > > http://www.fsf.org/copyleft/lesser.html). Tools produced in that spirit > will > > be available with their code and be open to further developments that > should > > be recorded with the MIP-TPF > > II - the MIP-TPF should provide support to programming by at least > > identifying existing resources in that area; it could also offer its own > MB > > resource library including all sorts of DLL's. > > > > > > I would like very much to know your reactions to this suggestion; its > > usefulness, ways to improve on it, your willingness to participate at its > > creation, at the conception of tools to support it (site design, > functioning > > and management), your potential contributions as a tool programmer, etc. > > Once I am convinced there is enough support, I will start the ball rolling > > most probably by using some special list for the necessary exchanges. > > > > I know that you are all very busy, but there are several among you (some > > have told me so already) who have resources almost available to share, and > > occasionally some "free" time to "play". You can answer me directly (I > will > > find a way to sum up at some future date) or through the MapInfo-L if you > > think your answer can fuel some debate on the subject. > > > > Thanks for taking the time of reading this message, and high hopes you > will > > react. > > > > Jacques Paris > > > > > --------------------------------------------------------------------- > List hosting provided by Directions Magazine | www.directionsmag.com | > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > Message number: 6019 > > > ******************************************************************** > > This email may contain information which is privileged or confidential. If you are > not the intended recipient of this email, please notify the sender immediately and delete it without reading, copying, storing, forwarding or disclosing its contents to any other person > Thank you > > Check us out at http://www.syntegra.com > > ******************************************************************** > > --------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 6030
