RE: [U2] Where Will the .NET Apps Live ?
Putting some logic at a middle tier, not necessarily at the DBMS server, also has advantages. At the risk of yet more bandwidth, but not consuming licenses, many basic validation rules can be exposed as client-independent web services. That approximates that interpreted layer, makes changes virtually instantaneous, and eliminates deployment issues. Goes to show you what we'll do for cost considerations. Introducing another tier seems like madness, unless it's cheaper. :-) Yes, there are times it makes sense to use a third tier, especially where data manipulation or db-independent operations need to take place, or you need access to languages that can provide facilities not best handled in mv Basic (complex parsing, dynamic rules or anything requiring working with large data sets for example). Middle tier logic is pretty much an essential in the RBDMS world as (for the most part) there isn't the complexity available directly in the database that we have with our inbuilt Basic. In a sense, an MVDBMS is both a tier 2 and tier 3 (if I haven't got the numbers back to front!) in the same space, so if you look at it from that point of view just about any multivalued C/S application is essentially three tier grin. I've been putting together a tool mapping web services onto mvBasic subroutines, using an XML parser built into an ISAPI DLL in the middle tier to decompose the mapping of complex types to and from dynamic array subroutine arguments, and the results are proving reasonable in terms of performance. There's room for improvement at this stage, but as a model it seems to work well - once you get through the minefield of just how many different 'interpretations' you need to support to handle different SOAP clients. I'll be looking out for some beta testers some time soon (hint!) as I don't have the facilities any more to simulate volume processing. Brian --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Where Will the .NET Apps Live ?
Check out mv.NET . http://www.bluefinity.com/ Regards, Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brutzman, Bill Sent: Wednesday, December 29, 2004 4:39 PM To: 'u2-users@listserver.u2ug.org' Subject: RE: [U2] Where Will the .NET Apps Live ? Has anybody written a compiled .Net two-tier application (Win-GUI, not browser) hosted on Unix box launched from a Win client? --Bill --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Where Will the .NET Apps Live ?
Hey Mike - what's with the BlueFinity label, why not just send them here?: http://www.jbase.com/products/mvnet.html Now I'm confused about mv.NET. The diagrams and details make it look like a class library but the text in the bluefinity website makes it look like a RAD environment nested within Visual Studio. At some point there the line blurs between we provide this function and we provide the tool that allows you to create this function. Can you clarify where this product positions itself? Oh well, we don't really get hot babes when we buy a car either. To answer Bill's question - yes - depending on how you code it, the back-end can be platform and technology independent of the client. T Mike Street mikes-at-jbase.com |U2UG| wrote: Check out mv.NET . http://www.bluefinity.com/ Regards, Mike -Original Message- From: Brutzman, Bill Has anybody written a compiled .Net two-tier application (Win-GUI, not browser) hosted on Unix box launched from a Win client? --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Where Will the .NET Apps Live ?
Tony, Because, for those of you who can't break themselves away from your existing platform(s), it will work with the one you are already using. mv.NET definitely is more than a class library. It resides within the .NET IDE and allows intelligent access to your multi-value data and code from there. Regards, Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Gravagno Sent: Wednesday, December 29, 2004 7:36 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Where Will the .NET Apps Live ? Hey Mike - what's with the BlueFinity label, why not just send them here?: http://www.jbase.com/products/mvnet.html Now I'm confused about mv.NET. The diagrams and details make it look like a class library but the text in the bluefinity website makes it look like a RAD environment nested within Visual Studio. At some point there the line blurs between we provide this function and we provide the tool that allows you to create this function. Can you clarify where this product positions itself? Oh well, we don't really get hot babes when we buy a car either. To answer Bill's question - yes - depending on how you code it, the back-end can be platform and technology independent of the client. T Mike Street mikes-at-jbase.com |U2UG| wrote: Check out mv.NET . http://www.bluefinity.com/ Regards, Mike -Original Message- From: Brutzman, Bill Has anybody written a compiled .Net two-tier application (Win-GUI, not browser) hosted on Unix box launched from a Win client? --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: Re: [U2] Where Will the .NET Apps Live ?
Part of the reason you may be enamoured with OI is BECAUSE of the integration with the backend DB this is true of any tool worth it's weight - once you have the data structures in place the applications tend to write themselves, with just a few tweaks. Hey, that give me a great idea for a book title Algorithms + Data Structures = - classic ideas stand the test of time, and I think that Multi-value IS a classic idea ! Ross Ferris Stamina Software Visage an Evolution in Software Development -Original Message- From: [EMAIL PROTECTED] [mailto:owner-u2- [EMAIL PROTECTED] On Behalf Of David Tod Sigafoos Sent: Tuesday, 28 December 2004 5:20 AM To: [EMAIL PROTECTED] Subject: Re: Re: [U2] Where Will the .NET Apps Live ? brian, Monday, December 27, 2004, 3:44:01 AM, you wrote: snip bbcu But you are absolutely right that it all begins and ends with the server bbcu logic. Get that right, and the choice of front end become pretty much bbcu irrelevant. I always tell my clients to build the server first: it is bbcu so much easier to verify and QA before the front end is assembled. bbcu Unfortunately too many sites still seem to approach it from the other bbcu end and end up with garbage and high QA costs. Have to disagree a bit with this. Although the backend is very important so is the front end. Knowing your market .. the way users actually do their work for the specific market and tying the two together. That is the challenge. The choice of front ends is just a critical for this portion of the environment. Although Delphi is a brilliant product, OpenInsight is much better for any MV environment. With a native bond to U2 it is just about the perfect tool for MV front end development. Front end does matter. Although you can set a screw with a hammer a screw driver would be the preferred tool g -- DSig ` David Tod Sigafoos ( O O ) ___oOOo__( )__oOOo___ Whenever you are in doubt...apply the first test. Recall the face of the poorest and the weakest man whom you may have seen, and ask yourself if the step you contemplate is going to be any use to him...True development puts first those that society puts last.-Mahatma Gandhi --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.296 / Virus Database: 265.6.5 - Release Date: 26/12/2004 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.296 / Virus Database: 265.6.5 - Release Date: 26/12/2004 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Where Will the .NET Apps Live ?
I tend to put basic syntactical validation in the client and application-specific data integrity type validation in the back-end. Sure that creates more client-specific code, but with standard routines it's not such a bother. The reason I do this is that I'm concerned about traffic. Connectivity tools change pricing models from time to time, and people deal with various ISP's and hosting providers. I don't want to assume that voluminous bandwidth is always going to be a free ride. Not only that, but when used indiscriminately, even non-persistent connections to the back end will take their toll on licenses for the DBMS and some connectivity products. Brian's comment about intepreted code wasn't lost on me and I need to consider it - I confess I've never done that. Putting some logic at a middle tier, not necessarily at the DBMS server, also has advantages. At the risk of yet more bandwidth, but not consuming licenses, many basic validation rules can be exposed as client-independent web services. That approximates that interpreted layer, makes changes virtually instantaneous, and eliminates deployment issues. Tony TG at removethis Nebula dash RnD dotster com brian-at-brianleach.co.uk |U2UG| wrote: ... And the best way to achieve that is to build and QA the back end first and to hold the logic on the server or in a centralized location (which is best on the server) interpreted by the client. I prefer interpreted, as it means that you can guarantee that all changes are rolled out immediately to the accessing clients: no issues with installing changes, cached logic, people not updating or any of that jazz. ... And QAing server based business rules is so much easier before you add the front end... --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Where Will the .NET Apps Live ?
Tony: [stuff snipped] Brian's comment about intepreted code wasn't lost on me and I need to consider it - I confess I've never done that. Putting some logic at a middle tier, not necessarily at the DBMS server, also has advantages. At the risk of yet more bandwidth, but not consuming licenses, many basic validation rules can be exposed as client-independent web services. That approximates that interpreted layer, makes changes virtually instantaneous, and eliminates deployment issues. Goes to show you what we'll do for cost considerations. Introducing another tier seems like madness, unless it's cheaper. :-) That's why it sometimes looks like the main MV providers aren't really interested in exposing the dbms model to the mainstream. In IBM's case, they probably just want to kill the product, eventually, because growing the product competes with their other product(s). In RDUS's case, they probably just want to squeeze it for what they can because they believe it'll die by itself. Not sure about jBase though. Maybe if they can sell it to China they'll reach a critical mass that'll support a migration from D3 and U2. What a bizarre thought. :-) Bill --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Where Will the .NET Apps Live ?
Full agreement with Brian, Will, and David on separating rules from the UI, which is a concept that many MV developers tend to acknowledge but not apply. Will, I'll see your bet and raise you a few : The concept of compiling rules down to Java is only half of it, the other half is executing them. You're talking about Java triggers where changes in the environment invoke Java code rather than MV BASIC. That concept has been implemented in (I believe) Revelation and jBase but eludes IBM and RD products. (Someone please correct that if I'm wrong, thanks.) If Java were an alternative development language to BASIC, our world would be much more open to mainstream developers than it is now. This is exactly what Oracle has done, allowing Java as an alternative to PL/SQL, and I think it's a great move. I'll summarize a couple related ideas. I hope I'm not being being too vague but this could turn into a whole research paper: - MV environments shouldn't hard code to interface with the BASIC run-time. Since BASIC compiles down to interpreted tokens anyway, we're already running a form of IL in our own environment. Rather than extending U2 or other MV environments to support a single different language, the environments should incorporate and integrate with virtual machines to run both the Java and .NET virtual environments (for bytecode and CIL). This would allow native support for all popular languages and make U2/MV as mainstream as any other DBMS. - Related to separating rules from UI, how about separating the rules from the database? None of the MV providers have shown interest in extracting the BASIC run-time (sans DB) to run in a compact form on the client. No client is 100% thin and some are downright thick. If the U2 BASIC run-time could run in the client then validation could be done there as an alternative to using scripting languages or intricate round trips of data with the server. For validation requiring data access, the client-side environment only needs to implement an internal web service client with a corresponding API on the server. Of course the developer will have to code in a non-persistent mode because things like OPEN and READU wouldn't be processed the same as in a persistent server. - While that concept perpetuates the MV developer's reliance on MV BASIC, which may not be an entirely good thing, we can take it one step further: there's no firm reason for the BASIC compiler to be married to the DBMS either. IBM could offer the BASIC compiler and a run-time for the object as free downloadables (U2Script?), which may get the interest of some mainstream developers - of course they could only access a U2 database on the back end, but isn't that what upselling is all about? :) Sure those concepts have issues. Monolithic development effort? Maybe, maybe not. Would mainstream people appreciate a procedural and non-event-driven language? Well, we do! :) I'm just tossing ideas on the table because all discussions revolve around getting some outside and mainstream language to communicate with the U2 black box but there's rarely discussion of opening components of the box itself to embrace and extend mainstream tools. Tony TG at (remove this) Nebula dash RND dotster com brian-at-brianleach.co.uk |U2UG| wrote: Will, What you're talking about (as you know full well I'm just adding my 2c) is a proper division of labour: the heart of good client/server. We have the advantage in this sector that at least we don't need a separate third tier for the business logic, since we already have that tier inside the database. ...But you are absolutely right that it all begins and ends with the server logic. Get that right, and the choice of front end become pretty much irrelevant. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Where Will the .NET Apps Live ?
Whether one uses java or .Net, my recommendation is to keep as much of your business logic in U2. Always use the best of both worlds; U2 is an ideal tool for developing business rules, processes transactions efficiently and is tightly integrated to the database, something other RDBMS cannot simulate. Use java or .Net for the interface and call the business rules as a subroutine, Message Queue, sockets or whatever. By doing it this way if you make a wrong choice, you do not have such a big conversion. This enables to develop both fat client and thin client solutions to your application without duplicating the business logic. Then if you move to web services architecture then it is quite simple. Both Java and .Net are getting into web services, and building the application to interface to a web service may simplify development. For someone starting out and who is familiar with U2 Basic, then Visual Basic is probably the easiest path, although .Net VB is more complicated than VB6. If you are just starting out, look at working with the beta of Visual Studio .Net 2005 which is being made a lot easier for VB developers and is streamlining the amount of code to do tasks. Although .Net is a simpler install without the need for the register, there is increased complexity of security to deal with. While java runs on more platforms, you have the choice of the lowest common denominator that runs on many platforms but is less sophisticated or a more sophisticated development that is limited to fewer platforms. It is a harder language to learn unless you have had C experience and can be slower to develop in. Another issue is that I have experienced java applications to run slower than a windows application. Other directions to look at is using revelation open insight which has interfaces to U2, is a pick client development tool and runs on windows and linux. Omnis development tool from raining data that runs on windows and linux. The other option is Borlands development tools that can run similar code on windows and linux. When selecting the tool weigh up the upfront costs of the development tool against the long term labour cost of development and if client licenses are required to run the application. Regards David Jordan Managing Consultant (U2UG founding board member) --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Where Will the .NET Apps Live ?
Sorry that I misled you twice. First, I'm not dismissing Mono. As I said, Mono is one of the better tricks of our time. And that's really our business - tricks of the trade :) And my underlying meaning by saying that MS benefits is that Mono makes Windows useable by a wider audience and that has to be an underlying objective at MS. Now if someone would publish a .NET API for BSD, or whatever name it is now using, then we would have a really good trick in our bag. I am never grieved by disagreement. That's the heart and soul of a good discussion BobJ - Original Message - From: Tony Gravagno [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Thursday, December 23, 2004 9:22 PM Subject: RE: [U2] Where Will the .NET Apps Live ? BobJ bob-at-rjoslyn.com |U2UG| wrote: Mono is one of the better tricks of our time. But for practical purposes it IS Windows so MS wins again. They just don't get any profit when you use Mono. At least no direct profit. Hey Bob, I'll give you grief here but I look forward to seeing you at Spectrum if you get a chance to come out. I'm not sure what your point actually was there. I hope you aren't dismissing Mono because it's based on technology that's been pioneered by Microsoft? Mono is an open source implementation of open standards - those are two concepts that Java has yet to embrace. Mono is a bridge that allows developers with a stronger Windows focus (like many people here) to code for Linux and Mac where those platforms were previously difficult to embrace. Mono can help Linux to achieve credibility in the one area that seems to preclude its popular acceptance, running desktop applications - though it's just as capable for server and network-based apps. When you say But for practical purposes are you implying that Mono can't be used for practical purposes? I don't look at what we do or the tools we use in terms of who wins. When I'm presented with a business or technical problem I look for tools to address the needs. Mono has been progressing at a reasonable clip and has earned its place for worthiness among C/C++, Java/J2xE, VB, Perl, PHP, etc. I don't care who profits when I use technology, the point is that end-users have needs and I'm going to use the tools that make them happy. I guess what's getting me here is that people might dismiss technology based on what inspired it without ever having tried it or actually evaluating it at face value. If we're going to do that then we're as bad as people who dismiss U2 because it's associated with Pick, and dismiss Pick because it looks old and hierarchical. Tony [EMAIL PROTECTED] dash RND.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Where Will the .NET Apps Live ?
Ok , so how does that apply in the context that it was used - difference between versions of VB ? Gerry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of BobJ Sent: Thursday, December 23, 2004 07:14 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Where Will the .NET Apps Live ? There is a DOM for Word, a DOM for Excel, and a DOM for Accuterm. You have the definition right but too limited in scope. BobJ - Original Message - From: gerry-u2ug [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Thursday, December 23, 2004 6:11 PM Subject: RE: [U2] Where Will the .NET Apps Live ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of BobJ Sent: Thursday, December 23, 2004 02:27 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Where Will the .NET Apps Live ? snip I almost understood OOP - and got a few things running. Now I'm struggling with VB in many different manifestations and finding power that I had no idea existed. Manifestations? VBS, VBA, VB, VB.NET - each is the same and each is different. The differences are partly in the DOM and partly in the product of the compile - or the lack of a compile in the cases of VBS and VBA. Sorry for my ignorance , but what exactly do you mean by DOM ? The only software related definition of DOM that I know of is Document Object Model referring specifically to either XML or HTML document modelling and I don't see how DOM even remotely relates to differences in versions of VB. So I assume that you have an entirely different definition for DOM. Just curious. Gerry --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Where Will the .NET Apps Live ?
That D in DOM is a general term and doesn't necessarily refer only to legible Documents. I think DOM and API can be used interchangably when referring to class libraries that define complex data structures along with related method/property/event structures. The MS Office libraries are a good example of this. It's not really Document Object Model, but there are definite differences in the Object Models of the various languages, or at least the way that you get access to various types of objects to accomplish similar tasks. In some cases it's syntactical but in others the objects you use depend on the VB dialect. I don't know if this is what Bob intended, but for file system access, for example: (WSH)VBS/VBA: Set fs = CreateObject(Scripting.FileSystemObject) Set myfile = fs.OpenTextFile(myfile.txt,1) VBA/VB: Open myfile.txt For Output As #1 VB.NET: Imports System.IO Dim fs As FileStream fs = File.Open(myfile.txt, FileMode.Open, FileAccess.Write) Scripted languages don't have early binding, so objects need to be instantiated with CreateObject into Variants, where in compiled languages you have the option to set a reference to a library and declare objects as New. That can really affect how code is written. And event handling in scripted languages is very different than with compiled code - the way you handle events for specific class/objects will vary depending on the class/language combination. Absorbing these nuances can be a real pain for new developers (to this realm) who may expect that everything with the name Visual Basic should look or behave relatively the same way. BASIC is not. Again, not to put words into Bob's mouth, but it's also not that DOM's themselves are difficult, but that every language, class, and product has its own DOM and its own way of doing things. I might fire an error event from objects instantiated in my class, you might set a Boolean .ErrorFlag, someone else sets an ErrorDesc String. With any of these DOMs you frequently can't just create an object, you need to drill down into the DOM of classes, creating instances of factories, superclasses and containers that you don't care about, just so that you can finally arrive that the class/object that you really want. And certain operations can only be performed by passing instances of specific object through a method - deriving yet another object that has your results. There is no one way of doing things, so learning the DOM of every class you're working with is an important investment of time. Of course this applies to every OOP language, but for the Pick programmer it's an utter shock to realize that every class truly does have unique behavior that's invoked differently - sometimes dependent on the language you use. This has gone way OT, but to somehow put it back in context, one of my mantras is tools are not important, and the above is a perfect example of that. Languages, syntax, and tools will change every couple years, but what IS important that we focus on business solutions, not wait forever for the perfect tools to deliver those solutions, and not get so hung up on syntax as we go along. Tony TG at Nebula dash RnD dotster com gerry-u2ug simpson-u2ug-at-gerzio.ca |U2UG| wrote: Ok , so how does that apply in the context that it was used - difference between versions of VB ? Gerry -Original Message- From: BobJ There is a DOM for Word, a DOM for Excel, and a DOM for Accuterm. You have the definition right but too limited in scope. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Where Will the .NET Apps Live ?
Tony said it all and said it well. It's the understanding and knowledge of the Object Model that is needed in order to make the application do what you want. It's strange that it is always called DOM when, as Tony said, the word Document does not necessarily apply. There are some other apparently minor differences among the VBs and Tony alluded to them. Mainly it is that some are compiled and some are interpreted. The compiled ones allow early binding among other good things while the interpreted ones are easier to master - especially for a Pickie (not meaning to denigrate Pick or Pick programming). The whole point is that the language is not the important point - the Objects that are exposed are the important points. There is still some fuzz involved because some of the scripting (not compiled) versions are not able to instantiate some of the exposed objects for one reason or another. That gap seems to be narrowing quickly however. I wonder if there will be a VB version that can be directed to produce a VBS file or a EXE or a DLL or an IL That would be power. Obviously you could not expect to store managed code in any but IL but that has always been true in the sense that managed code only came into existence with the IL. Tony, thank you for your eloquent and accurate description. Gerry, I hope that I am not being even more confusing. I'm groping my way into this morass so sometimes I find it difficult to express the gleanings from the vast store of knowledge out there. BobJ - Original Message - From: Tony Gravagno [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, December 24, 2004 11:19 AM Subject: RE: [U2] Where Will the .NET Apps Live ? That D in DOM is a general term and doesn't necessarily refer only to legible Documents. I think DOM and API can be used interchangably when referring to class libraries that define complex data structures along with related method/property/event structures. The MS Office libraries are a good example of this. It's not really Document Object Model, but there are definite differences in the Object Models of the various languages, or at least the way that you get access to various types of objects to accomplish similar tasks. In some cases it's syntactical but in others the objects you use depend on the VB dialect. I don't know if this is what Bob intended, but for file system access, for example: (WSH)VBS/VBA: Set fs = CreateObject(Scripting.FileSystemObject) Set myfile = fs.OpenTextFile(myfile.txt,1) VBA/VB: Open myfile.txt For Output As #1 VB.NET: Imports System.IO Dim fs As FileStream fs = File.Open(myfile.txt, FileMode.Open, FileAccess.Write) Scripted languages don't have early binding, so objects need to be instantiated with CreateObject into Variants, where in compiled languages you have the option to set a reference to a library and declare objects as New. That can really affect how code is written. And event handling in scripted languages is very different than with compiled code - the way you handle events for specific class/objects will vary depending on the class/language combination. Absorbing these nuances can be a real pain for new developers (to this realm) who may expect that everything with the name Visual Basic should look or behave relatively the same way. BASIC is not. Again, not to put words into Bob's mouth, but it's also not that DOM's themselves are difficult, but that every language, class, and product has its own DOM and its own way of doing things. I might fire an error event from objects instantiated in my class, you might set a Boolean .ErrorFlag, someone else sets an ErrorDesc String. With any of these DOMs you frequently can't just create an object, you need to drill down into the DOM of classes, creating instances of factories, superclasses and containers that you don't care about, just so that you can finally arrive that the class/object that you really want. And certain operations can only be performed by passing instances of specific object through a method - deriving yet another object that has your results. There is no one way of doing things, so learning the DOM of every class you're working with is an important investment of time. Of course this applies to every OOP language, but for the Pick programmer it's an utter shock to realize that every class truly does have unique behavior that's invoked differently - sometimes dependent on the language you use. This has gone way OT, but to somehow put it back in context, one of my mantras is tools are not important, and the above is a perfect example of that. Languages, syntax, and tools will change every couple years, but what IS important that we focus on business solutions, not wait forever for the perfect tools to deliver those solutions, and not get so hung up on syntax as we go along. Tony TG at Nebula dash RnD dotster com gerry-u2ug simpson-u2ug-at-gerzio.ca |U2UG| wrote: Ok , so how does
RE: [U2] Where Will the .NET Apps Live ?
In fact if you want a software application environment that includes unix in any flavor or has the option of including such -- linux, Mac OS X, or anything other than strictly Windows, you will not want to go .NET (at least not yet, and I suspect not for a long time). From my perspective, .NET is for those who have completely married themselves to Microsoft and plan to continue that marriage for better or worse. The unfortunate thing is that it is not (yet) really easy to write small-to-midsize quality applications using Java. That's why many have opted for scripting languages such as Perl, PHP, and Python for web-based solutions. When everything is from a single-vendor (Microsoft), you at least have (knock on wood) compatibility and Microsoft has also done well, from what I hear, in making nice development environments. The other side of the house (Java, for example) is not so well coordinated, but that is where I'm spending my efforts none-the-less. It will get there. --dawn Dawn M. Wolthuis Tincat Group, Inc. www.tincat-group.com Take and give some delight today. -Original Message- From: [EMAIL PROTECTED] [mailto:owner-u2- [EMAIL PROTECTED] On Behalf Of Don Kibbey Sent: Wednesday, December 22, 2004 6:14 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Where Will the .NET Apps Live ? Java over .Net That just sounds wrong. If you have a server environment that's exclusively Unix, you will probably want to just stick with most anything except .Net. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brutzman, Bill Sent: Wednesday, December 22, 2004 6:28 PM To: 'u2-users@listserver.u2ug.org' Subject: [U2] Where Will the .NET Apps Live ? Is there a way to save .Net exe app programs on a Unix box... such that Windows users can launch these programs directly? A lecturer indicated how to save exe apps on a Windows Server. For us here, the trouble with this scheme is that it turns 2-tier into 3-tier. That is, if the Win Server goes down, clients would be unable to run their ERP programs. This scenario seems to make a compelling case for Java over .NET. Comments are welcome. --Bill --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Where Will the .NET Apps Live ?
Ah, but what IS the environment? If it is a server and a bunch of PCs then it is client server no matter how you slice it. And if it is client server and it is not from Mars then the client desk top is very probably Windows. Yes, there are exceptions. But they are just that - exceptions. I think that most of us who have an MV background in common write apps that are not shrink wrapped and not sold at CompUSA. And most of those apps, no matter the language, are very thin client and very thick server simply to avoid dealing with Windows and .NET in any detail. We might thicken the client a bit by using some of the better tools of Accuterm but even then we don't put much stress on the client. So you are right in the sense that using .NET to write the server software is probably not a good idea yet. But on the client side, assuming that we ever get to where we actually write client software, VB.NET has become a giant. And Visual Studio makes using that giant very easy once you are able to see the trees inside that vast and dense forest. There are some very real advantages to be gained by spending a little time learning the ins and outs of COM and the various DOMs. You can offer an application that looks and feels like it is part of Windows - and the guy or gal sitting at the keyboard gains comfort from that. When he or she is composing a quote or an order and comes to the part where a small story needs to be written and included then Word or Word Pad or Notes can be invoked and the results embedded in the transaction. When the thing is finished then it can be sent to a lot of places in a lot of different ways - including sending to USB printers even though the server doesn't support USB printers. But the learning curve is perhaps not steep but certainly not trivial. And for programmers like us (We? - tough grammar problem) who have been using the same tools for 20 years or more, learning anything new is tough. FWIW, I struggled with Java for a few months and actually got a few things running. Then I struggled with C# - which went a little quicker because now I almost understood OOP - and got a few things running. Now I'm struggling with VB in many different manifestations and finding power that I had no idea existed. Manifestations? VBS, VBA, VB, VB.NET - each is the same and each is different. The differences are partly in the DOM and partly in the product of the compile - or the lack of a compile in the cases of VBS and VBA. The bottom line of all of this is that MS does seem to have a strategy and it does seem to be working. It has cost them a few dollars to eliminate some of the competition and it may cost them a few more dollars to eliminate some more of the competition. But there does not appear to be any power on earth that can stop them. So resistance is futile - we might as well learn .NET. I suppose that eventually they will become part of the Government and there will be a cabinet post - Secretary of Microsoft - with a budget larger than that of the Intelligence Community. Merry Christmas to all. And meaning no disrespect to those who are not Christian. It will still be Christmas and they can still be merry :) BobJ - Original Message - From: Dawn M. Wolthuis [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Thursday, December 23, 2004 12:43 PM Subject: RE: [U2] Where Will the .NET Apps Live ? In fact if you want a software application environment that includes unix in any flavor or has the option of including such -- linux, Mac OS X, or anything other than strictly Windows, you will not want to go .NET (at least not yet, and I suspect not for a long time). From my perspective, .NET is for those who have completely married themselves to Microsoft and plan to continue that marriage for better or worse. The unfortunate thing is that it is not (yet) really easy to write small-to-midsize quality applications using Java. That's why many have opted for scripting languages such as Perl, PHP, and Python for web-based solutions. When everything is from a single-vendor (Microsoft), you at least have (knock on wood) compatibility and Microsoft has also done well, from what I hear, in making nice development environments. The other side of the house (Java, for example) is not so well coordinated, but that is where I'm spending my efforts none-the-less. It will get there. --dawn Dawn M. Wolthuis Tincat Group, Inc. www.tincat-group.com Take and give some delight today. -Original Message- From: [EMAIL PROTECTED] [mailto:owner-u2- [EMAIL PROTECTED] On Behalf Of Don Kibbey Sent: Wednesday, December 22, 2004 6:14 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Where Will the .NET Apps Live ? Java over .Net That just sounds wrong. If you have a server environment that's exclusively Unix, you will probably want to just stick with most anything except .Net. -Original Message- From: [EMAIL PROTECTED
RE: [U2] Where Will the .NET Apps Live ?
-Original Message- From: [EMAIL PROTECTED] [mailto:owner-u2- [EMAIL PROTECTED] On Behalf Of BobJ Sent: Thursday, December 23, 2004 1:27 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Where Will the .NET Apps Live ? Ah, but what IS the environment? If it is a server and a bunch of PCs then it is client server no matter how you slice it. And if it is client server and it is not from Mars then the client desk top is very probably Windows. Today it is very likely that the client is a version of Windows, Linux or Mac OS, with the largest percentage squarely in Windows category. Yes, there are exceptions. But they are just that - exceptions. I don't find it that exceptional for someone to be running either Linux or Mac OS X on the desktop, but I work with higher ed and other not-exactly-manufacturing companies. I haven't seen a recent pie chart of desktop OS's -- can anyone point to a URL that has one you think is pretty accurate? I think that most of us who have an MV background in common write apps that are not shrink wrapped and not sold at CompUSA. And most of those apps, no matter the language, are very thin client and very thick server simply to avoid dealing with Windows and .NET in any detail. We might thicken the client a bit by using some of the better tools of Accuterm but even then we don't put much stress on the client. So you are right in the sense that using .NET to write the server software is probably not a good idea yet. But on the client side, assuming that we ever get to where we actually write client software, VB.NET has become a giant. And Visual Studio makes using that giant very easy once you are able to see the trees inside that vast and dense forest. There are some very real advantages to be gained by spending a little time learning the ins and outs of COM and the various DOMs. You can offer an application that looks and feels like it is part of Windows - and the guy or gal sitting at the keyboard gains comfort from that. When he or she is composing a quote or an order and comes to the part where a small story needs to be written and included then Word or Word Pad or Notes can be invoked and the results embedded in the transaction. When the thing is finished then it can be sent to a lot of places in a lot of different ways - including sending to USB printers even though the server doesn't support USB printers. But the learning curve is perhaps not steep but certainly not trivial. And for programmers like us (We? - tough grammar problem) indeed -- my father the linguist would tell you to go ahead and use us there who have been using the same tools for 20 years or more, learning anything new is tough. FWIW, I struggled with Java for a few months and actually got a few things running. Then I struggled with C# - which went a little quicker because now I almost understood OOP - and got a few things running. Now I'm struggling with VB in many different manifestations and finding power that I had no idea existed. Manifestations? VBS, VBA, VB, VB.NET - each is the same and each is different. The differences are partly in the DOM and partly in the product of the compile - or the lack of a compile in the cases of VBS and VBA. I opted to take one of these to master and the other to let you master ;-) My current detour has me teaching college-level programming (Java I and Java II, as well as OO patterns), so I should come out of that a bit more savvy. It still looks to me that the easier route is .NET, but that lockin to Microsoft is too big an obstacle from my perspective. The bottom line of all of this is that MS does seem to have a strategy and it does seem to be working. It has cost them a few dollars to eliminate some of the competition and it may cost them a few more dollars to eliminate some more of the competition. But there does not appear to be any power on earth that can stop them. So resistance is futile - we might as well learn .NET. I suppose that eventually they will become part of the Government and there will be a cabinet post - Secretary of Microsoft - with a budget larger than that of the Intelligence Community. At that point I will really be pleased that I opted for a different path. Merry Christmas to all. And meaning no disrespect to those who are not Christian. It will still be Christmas and they can still be merry :) Amen. --dawn BobJ - Original Message - From: Dawn M. Wolthuis [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Thursday, December 23, 2004 12:43 PM Subject: RE: [U2] Where Will the .NET Apps Live ? In fact if you want a software application environment that includes unix in any flavor or has the option of including such -- linux, Mac OS X, or anything other than strictly Windows, you will not want to go .NET (at least not yet, and I suspect not for a long time). From my perspective, .NET
RE: [U2] Where Will the .NET Apps Live ?
Mono allows you to run the same C#/.NET code over Win32 and *nix. http://www.mono-project.com/about/index.html As an example, you can use Mono to serve ASP.NET pages from your Linux box with no Windows involved. Connectivity can be established with your U2 environment, just not via UO.NET, which internally uses the Win32-only Pinvoke. HTH Tony [EMAIL PROTECTED] dash RND.com Don Kibbey don-at-kibbey.com |U2UG| wrote: Java over .Net That just sounds wrong. If you have a server environment that's exclusively Unix, you will probably want to just stick with most anything except .Net. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Where Will the .NET Apps Live ?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of BobJ Sent: Thursday, December 23, 2004 02:27 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Where Will the .NET Apps Live ? snip I almost understood OOP - and got a few things running. Now I'm struggling with VB in many different manifestations and finding power that I had no idea existed. Manifestations? VBS, VBA, VB, VB.NET - each is the same and each is different. The differences are partly in the DOM and partly in the product of the compile - or the lack of a compile in the cases of VBS and VBA. Sorry for my ignorance , but what exactly do you mean by DOM ? The only software related definition of DOM that I know of is Document Object Model referring specifically to either XML or HTML document modelling and I don't see how DOM even remotely relates to differences in versions of VB. So I assume that you have an entirely different definition for DOM. Just curious. Gerry --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Where Will the .NET Apps Live ?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of BobJ Sent: Thursday, December 23, 2004 02:27 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Where Will the .NET Apps Live ? snip I almost understood OOP - and got a few things running. Now I'm struggling with VB in many different manifestations and finding power that I had no idea existed. Manifestations? VBS, VBA, VB, VB.NET - each is the same and each is different. The differences are partly in the DOM and partly in the product of the compile - or the lack of a compile in the cases of VBS and VBA. Sorry for my ignorance , but what exactly do you mean by DOM ? The only software related definition of DOM that I know of is Document Object Model referring specifically to either XML or HTML document modelling and I don't see how DOM even remotely relates to differences in versions of VB. So I assume that you have an entirely different definition for DOM. Just curious. Gerry --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Where Will the .NET Apps Live ?
There is a DOM for Word, a DOM for Excel, and a DOM for Accuterm. You have the definition right but too limited in scope. BobJ - Original Message - From: gerry-u2ug [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Thursday, December 23, 2004 6:11 PM Subject: RE: [U2] Where Will the .NET Apps Live ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of BobJ Sent: Thursday, December 23, 2004 02:27 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Where Will the .NET Apps Live ? snip I almost understood OOP - and got a few things running. Now I'm struggling with VB in many different manifestations and finding power that I had no idea existed. Manifestations? VBS, VBA, VB, VB.NET - each is the same and each is different. The differences are partly in the DOM and partly in the product of the compile - or the lack of a compile in the cases of VBS and VBA. Sorry for my ignorance , but what exactly do you mean by DOM ? The only software related definition of DOM that I know of is Document Object Model referring specifically to either XML or HTML document modelling and I don't see how DOM even remotely relates to differences in versions of VB. So I assume that you have an entirely different definition for DOM. Just curious. Gerry --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Where Will the .NET Apps Live ?
Mono is one of the better tricks of our time. But for practical purposes it IS Windows so MS wins again. They just don't get any profit when you use Mono. At least no direct profit. BobJ - Original Message - From: Tony Gravagno [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Thursday, December 23, 2004 6:04 PM Subject: RE: [U2] Where Will the .NET Apps Live ? Mono allows you to run the same C#/.NET code over Win32 and *nix. http://www.mono-project.com/about/index.html As an example, you can use Mono to serve ASP.NET pages from your Linux box with no Windows involved. Connectivity can be established with your U2 environment, just not via UO.NET, which internally uses the Win32-only Pinvoke. HTH Tony [EMAIL PROTECTED] dash RND.com Don Kibbey don-at-kibbey.com |U2UG| wrote: Java over .Net That just sounds wrong. If you have a server environment that's exclusively Unix, you will probably want to just stick with most anything except .Net. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Where Will the .NET Apps Live ?
BobJ bob-at-rjoslyn.com |U2UG| wrote: Mono is one of the better tricks of our time. But for practical purposes it IS Windows so MS wins again. They just don't get any profit when you use Mono. At least no direct profit. Hey Bob, I'll give you grief here but I look forward to seeing you at Spectrum if you get a chance to come out. I'm not sure what your point actually was there. I hope you aren't dismissing Mono because it's based on technology that's been pioneered by Microsoft? Mono is an open source implementation of open standards - those are two concepts that Java has yet to embrace. Mono is a bridge that allows developers with a stronger Windows focus (like many people here) to code for Linux and Mac where those platforms were previously difficult to embrace. Mono can help Linux to achieve credibility in the one area that seems to preclude its popular acceptance, running desktop applications - though it's just as capable for server and network-based apps. When you say But for practical purposes are you implying that Mono can't be used for practical purposes? I don't look at what we do or the tools we use in terms of who wins. When I'm presented with a business or technical problem I look for tools to address the needs. Mono has been progressing at a reasonable clip and has earned its place for worthiness among C/C++, Java/J2xE, VB, Perl, PHP, etc. I don't care who profits when I use technology, the point is that end-users have needs and I'm going to use the tools that make them happy. I guess what's getting me here is that people might dismiss technology based on what inspired it without ever having tried it or actually evaluating it at face value. If we're going to do that then we're as bad as people who dismiss U2 because it's associated with Pick, and dismiss Pick because it looks old and hierarchical. Tony [EMAIL PROTECTED] dash RND.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Where Will the .NET Apps Live ?
Java over .Net That just sounds wrong. If you have a server environment that's exclusively Unix, you will probably want to just stick with most anything except .Net. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brutzman, Bill Sent: Wednesday, December 22, 2004 6:28 PM To: '[EMAIL PROTECTED]' Subject: [U2] Where Will the .NET Apps Live ? Is there a way to save .Net exe app programs on a Unix box... such that Windows users can launch these programs directly? A lecturer indicated how to save exe apps on a Windows Server. For us here, the trouble with this scheme is that it turns 2-tier into 3-tier. That is, if the Win Server goes down, clients would be unable to run their ERP programs. This scenario seems to make a compelling case for Java over .NET. Comments are welcome. --Bill --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Where Will the .NET Apps Live ?
From: Don Kibbey Sent: Wednesday, December 22, 2004 5:14 PM Java over .Net That just sounds wrong. I think he might have meant java instead of .net. --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Where Will the .NET Apps Live ?
Brutzman, Bill wrote: Is there a way to save .Net exe app programs on a Unix box... such that Windows users can launch these programs directly? Yes, just run samba on the unix box and put the executables in a directory shared by samba. The Windows desktops won't know it's not a Windows server, and you'll have a unix level of uptime. -John -- John Hester System Network Administrator Momentum Group Inc. (949) 833-8886 x623 http://memosamples.com --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Where Will the .NET Apps Live ?
I'm pretty sure that the answer to this is 'yes' but I don't know if anything special is involved. You might want to do some research on the 'Zero Touch Deployment' feature in .NET. Basically, you just load up your executables onto a web server (probably best as an intranet solution). I don't think it matters what the web server is at all (so if you have your UNIX box run a web server then it's ok). You deploy your project to a web site and can then either point to the executable there (or create a stub program on the client pc). At this point, your app will load assemblies as needed off of the web site. Keep in mind that it will always look to the web site, but only download to the local cache once - unless there is an updated assembly. The bad thing is that you can't run the app at all if this web server is down even if you have all the assemblies cached locally. I don't think this will matter to you because you want to keep this to 2-tier anyway (if the web server is down so is your ERP database). This may also be improved in the next version of .NET, which is currently called 'Click Once Deployment' (the name can change so many more times before release). I'm sorry I don't remember this any better because, while it is simple once you get it going, it's a little tricky starting out. As I said, you will need to do some research on the topic. I stopped a long time ago because it was before UO.NET was available. This meant that the client PC must already have UniObjects ActiveX (I guess UniObjects Java would also be ok) installed and registered in order to work properly. This wasn't what I wanted so I abandoned further development. Now this all should change as UniObjects.NET is fully managed code. This means that the client only needs the .NET framework and nothing else. I think this is acceptable because the .NET framework is free to install, will be included in all MS operating systems moving forward, and it is already installed as part of so many other products. As the client will be running the executable (not the UNIX server or Windows app server), you will have to pay attention to client configurations. As long as you design properly (which is why I use only a few of the features of UniObjects) this should not be a problem. HTH. Regards, Jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brutzman, Bill Sent: Wednesday, December 22, 2004 6:28 PM To: 'u2-users@listserver.u2ug.org' Subject: [U2] Where Will the .NET Apps Live ? Is there a way to save .Net exe app programs on a Unix box... such that Windows users can launch these programs directly? A lecturer indicated how to save exe apps on a Windows Server. For us here, the trouble with this scheme is that it turns 2-tier into 3-tier. That is, if the Win Server goes down, clients would be unable to run their ERP programs. This scenario seems to make a compelling case for Java over .NET. Comments are welcome. --Bill --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
