 | |
If you were starting from scratch
comp.databases.pick comp.databases.pick
 |
| | Thread Tools | Display Modes |
#41
 
| |||
| |||
|
Re: If you were starting from scratch -
02-16-2007
, 09:20 PM
|
been tried including Expat, Pyexpat, RXP, XML4J, XML::Parser, or the Mono XML libraries. (No idea if all of those are even still viable, I'm just mentioning names.) |
My score: 0
Chandru
#42
| |||
| |||
|
|
Abstraction layers can be between the application and the DBMS and they can also be between the application and the user. We've all (mostly?) moved on from the single process dumb terminal green-screen world. We now (mostly?) work in environments where we expect multiple 'users' to share the same process and - here's the good bit - we need not concern ourselves too much with their particular location and/or local environment. All we need - really - is an authentic, secure means of communicating with them and a way of exchanging messages with them. That's it. What we need then, is the ability to insert an abstraction layer to sort this out for us. All we need to know (when starting from scratch) is that we'll be getting messages in and passing messages out. Let the abstraction layer go play on the buses. |
the development of yet another XML solution within MV, what I'm trying
to do is encourage people to consider the wealth of resources that
already exist outside of the environment which we can use as a
service. This is the model that the world is working toward and it's
increasingly well regarded - it's a politically safe approach where in
the past it was considered a cludge, go figure. I think the
difference is in the perception of stability and maintainability.
The interface from the application layer should be exactly the same.
Down from that business layer I'm just wondering why people always
insist on writing stuff in MV when non-MV people have invested their
tears specifically to create platform (more DBMS here) independent
solutions for all of us to use. If we can build a better mousetrap in
MV, great, but until we see other projects have failed and we've
learned from those failures, why do MV people start their exploration
by writing code rather than researching how to interface to existing
solutions?
Primarily I think this is because MV people are in their comfort zone
with MV. That's no surprise and no criticism, it's just the way it
is. But where other IT managers do research to find solutions, MV
people hunker down at the keyboard to write their own solutions the
way they think it should be done. This existential approach to
development is yet another one of the great failings of our market.
It's like when Dick rejected PC's and insisted that everyone should
use dumb terminals, even if they needed a foot pedal to do it. While
we can all laugh at that, a large number of Pick people deep down
still think like that: write it myself, write it cheap, sell it cheap.
A lot of you guys don't quite get me yet with all of these forum
postings. I often don't make specific points (though I think it's
funny when people violently disagree with me in such cases because I
could easily change many positions) - I'm trying to get you guys to
think about why you're focused on the points that you're making or the
approaches you're taking. I'm not advocating or critcizing any
specific approach. I'm trying to get people to think about why they
do things in certain ways. It's like asking someone why they want to
use feature Z in a program when it turns out their business case
doesn't call for such a program in the first place. If the reasoning
is valid, go for it. If I help someone to question and re-affirm why
they approach things in certain ways then I feel like I've done my
part here.
T
#43
| |||
| |||
|
|
"Tony Gravagno" wrote: And there are many tech-1 options that haven't been tried including Expat, Pyexpat, RXP, XML4J, XML::Parser, or the Mono XML libraries. (No idea if all of those are even still viable, I'm just mentioning names.) Just curious...how many on this list know these mnemonics? My score: 0 Chandru |
T
#44
| |||
| |||
|
|
"Mike Preece" wrote: Abstraction layers can be between the application and the DBMS and they can also be between the application and the user. We've all (mostly?) moved on from the single process dumb terminal green-screen world. We now (mostly?) work in environments where we expect multiple 'users' to share the same process and - here's the good bit - we need not concern ourselves too much with their particular location and/or local environment. All we need - really - is an authentic, secure means of communicating with them and a way of exchanging messages with them. That's it. What we need then, is the ability to insert an abstraction layer to sort this out for us. All we need to know (when starting from scratch) is that we'll be getting messages in and passing messages out. Let the abstraction layer go play on the buses. Mike, you're providing a very good description of SOA. By questioning the development of yet another XML solution within MV, what I'm trying to do is encourage people to consider the wealth of resources that already exist outside of the environment which we can use as a service. This is the model that the world is working toward and it's increasingly well regarded - it's a politically safe approach where in the past it was considered a cludge, go figure. |
bandwidth
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.