Re: [U2] Consuming Web Services
But we all know U2 is much more than a DB, in fact it is also much less than a DB. The concept of having the DB just do DB stuff works fine for SQL server and MySQL where the DB itself actually does a lot in terms of the data, and the clients, written in .NET, C, Python Java etc do all the business logic. For these stored procedures do exist but are usually kept to a minimum and certainly only for data interaction. The U2 databases are actually quite stupid, they store and retrieve data from tables in a (hopefully) quick and efficient manner, but they certainly don't do any of the clever stuff you find inside Sql server like map reduce, caching, indexing etc. The clever bits are what we do in the unibasic code. So I firmly believe there IS a case for the clever Unibasic code we write to access data over http, read in xml and to then process all of these different data streams. Yeah sure there are things which in theory are easier to do outside It does not mean you should always do things outside of unibasic. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Brutzman Sent: 03 October 2012 23:48 To: U2 Users List Subject: Re: [U2] Consuming Web Services Tony and Ben are right on... Invoking Stephen Colbert's concept of... The Word... the word is... MiddleWare. As legacy U2 was ahead of its time... by building-in middleware technologies... it is easy to lose sight of what belongs where. --Bill -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: Wednesday, October 03, 2012 6:31 PM Subject: Re: [U2] Consuming web services I do the same as Ben but with .NET: -- Local U2 .NET client web service Remote server Pick is a database server, not a communications protocol end-point. We simply should not be doing direct comms from this platform anymore, given the huge number of mainstream options. This is coming from someone who has written all of the bi-directional comms interfaces to/from MV with sockets and cURL and plugins and anything else I could create - because (in the 90's) people said it wasn't possible and because I figured it would be kewl just to do it. It _is_ all technically possible, but that doesn't mean it makes good business sense: Doing things like this in BASIC creates a maintenance hassle later. It leaves the environment subject to DBMS-specific issues that often aren't addressed for quite a long time. Using mainstream tools vastly increases the resources available for getting help and solving problems. So these days I get MV to push a query or data payload out to a middle-tier that uses the latest communications methods available. The request goes out, the response comes back, it all just works - that That should be our bottom line here. HTH T From: Ben Souther We use a middle layer written in Java. Jeff Schasny wrote: I know we have both the SOAP and RESTful web services development for publishing web services from Universe but how are folks consuming other peoples web services into the database? Are there tools for this or am I going to just open a socket, read, and parse 'till I'm blue in the face? ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Consuming Web Services
The U2 database does do indexing. -Original Message- From: Symeon Breen syme...@gmail.com To: 'U2 Users List' u2-users@listserver.u2ug.org Sent: Thu, Oct 4, 2012 12:56 am Subject: Re: [U2] Consuming Web Services But we all know U2 is much more than a DB, in fact it is also much less than a DB. The concept of having the DB just do DB stuff works fine for SQL server and MySQL where the DB itself actually does a lot in terms of the data, and the clients, written in .NET, C, Python Java etc do all the business logic. For these stored procedures do exist but are usually kept to a minimum and certainly only for data interaction. The U2 databases are actually quite stupid, they store and retrieve data from tables in a (hopefully) quick and efficient manner, but they certainly don't do any of the clever stuff you find inside Sql server like map reduce, caching, indexing etc. The clever bits are what we do in the unibasic code. So I firmly believe there IS a case for the clever Unibasic code we write to access data over http, read in xml and to then process all of these different data streams. Yeah sure there are things which in theory are easier to do outside It does not mean you should always do things outside of unibasic. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Brutzman Sent: 03 October 2012 23:48 To: U2 Users List Subject: Re: [U2] Consuming Web Services Tony and Ben are right on... Invoking Stephen Colbert's concept of... The Word... the word is... MiddleWare. As legacy U2 was ahead of its time... by building-in middleware technologies... it is easy to lose sight of what belongs where. --Bill -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: Wednesday, October 03, 2012 6:31 PM Subject: Re: [U2] Consuming web services I do the same as Ben but with .NET: -- Local U2 .NET client web service Remote server Pick is a database server, not a communications protocol end-point. We simply should not be doing direct comms from this platform anymore, given the huge number of mainstream options. This is coming from someone who has written all of the bi-directional comms interfaces to/from MV with sockets and cURL and plugins and anything else I could create - because (in the 90's) people said it wasn't possible and because I figured it would be kewl just to do it. It _is_ all technically possible, but that doesn't mean it makes good business sense: Doing things like this in BASIC creates a maintenance hassle later. It leaves the environment subject to DBMS-specific issues that often aren't addressed for quite a long time. Using mainstream tools vastly increases the resources available for getting help and solving problems. So these days I get MV to push a query or data payload out to a middle-tier that uses the latest communications methods available. The request goes out, the response comes back, it all just works - that That should be our bottom line here. HTH T From: Ben Souther We use a middle layer written in Java. Jeff Schasny wrote: I know we have both the SOAP and RESTful web services development for publishing web services from Universe but how are folks consuming other peoples web services into the database? Are there tools for this or am I going to just open a socket, read, and parse 'till I'm blue in the face? ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Consuming Web Services
I know - but you have to set it up against specific attributes and it creates a fairly standard index for the specified attributes in hand, you do that on sql as well, but it does its own indexing to make row retrieval optimised, has its own referential integrity rules around that etc. It's quite a different beast altogether. I am not saying it is better, but it does a lot more inside than U2 does. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: 04 October 2012 09:05 To: u2-users@listserver.u2ug.org Subject: Re: [U2] Consuming Web Services The U2 database does do indexing. -Original Message- From: Symeon Breen syme...@gmail.com To: 'U2 Users List' u2-users@listserver.u2ug.org Sent: Thu, Oct 4, 2012 12:56 am Subject: Re: [U2] Consuming Web Services But we all know U2 is much more than a DB, in fact it is also much less than a DB. The concept of having the DB just do DB stuff works fine for SQL server and MySQL where the DB itself actually does a lot in terms of the data, and the clients, written in .NET, C, Python Java etc do all the business logic. For these stored procedures do exist but are usually kept to a minimum and certainly only for data interaction. The U2 databases are actually quite stupid, they store and retrieve data from tables in a (hopefully) quick and efficient manner, but they certainly don't do any of the clever stuff you find inside Sql server like map reduce, caching, indexing etc. The clever bits are what we do in the unibasic code. So I firmly believe there IS a case for the clever Unibasic code we write to access data over http, read in xml and to then process all of these different data streams. Yeah sure there are things which in theory are easier to do outside It does not mean you should always do things outside of unibasic. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Brutzman Sent: 03 October 2012 23:48 To: U2 Users List Subject: Re: [U2] Consuming Web Services Tony and Ben are right on... Invoking Stephen Colbert's concept of... The Word... the word is... MiddleWare. As legacy U2 was ahead of its time... by building-in middleware technologies... it is easy to lose sight of what belongs where. --Bill -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: Wednesday, October 03, 2012 6:31 PM Subject: Re: [U2] Consuming web services I do the same as Ben but with .NET: -- Local U2 .NET client web service Remote server Pick is a database server, not a communications protocol end-point. We simply should not be doing direct comms from this platform anymore, given the huge number of mainstream options. This is coming from someone who has written all of the bi-directional comms interfaces to/from MV with sockets and cURL and plugins and anything else I could create - because (in the 90's) people said it wasn't possible and because I figured it would be kewl just to do it. It _is_ all technically possible, but that doesn't mean it makes good business sense: Doing things like this in BASIC creates a maintenance hassle later. It leaves the environment subject to DBMS-specific issues that often aren't addressed for quite a long time. Using mainstream tools vastly increases the resources available for getting help and solving problems. So these days I get MV to push a query or data payload out to a middle-tier that uses the latest communications methods available. The request goes out, the response comes back, it all just works - that That should be our bottom line here. HTH T From: Ben Souther We use a middle layer written in Java. Jeff Schasny wrote: I know we have both the SOAP and RESTful web services development for publishing web services from Universe but how are folks consuming other peoples web services into the database? Are there tools for this or am I going to just open a socket, read, and parse 'till I'm blue in the face? ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Consuming Web Services
A U2 Table *can* also have referential integrity, it's an option. And SQL Table don't force referential integrity, you can turn that off :) -Original Message- From: Symeon Breen syme...@gmail.com To: 'U2 Users List' u2-users@listserver.u2ug.org Sent: Thu, Oct 4, 2012 1:17 am Subject: Re: [U2] Consuming Web Services I know - but you have to set it up against specific attributes and it creates a fairly standard index for the specified attributes in hand, you do that on sql as well, but it does its own indexing to make row retrieval optimised, has its own referential integrity rules around that etc. It's quite a different beast altogether. I am not saying it is better, but it does a lot more inside than U2 does. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: 04 October 2012 09:05 To: u2-users@listserver.u2ug.org Subject: Re: [U2] Consuming Web Services The U2 database does do indexing. -Original Message- From: Symeon Breen syme...@gmail.com To: 'U2 Users List' u2-users@listserver.u2ug.org Sent: Thu, Oct 4, 2012 12:56 am Subject: Re: [U2] Consuming Web Services But we all know U2 is much more than a DB, in fact it is also much less than a DB. The concept of having the DB just do DB stuff works fine for SQL server and MySQL where the DB itself actually does a lot in terms of the data, and the clients, written in .NET, C, Python Java etc do all the business logic. For these stored procedures do exist but are usually kept to a minimum and certainly only for data interaction. The U2 databases are actually quite stupid, they store and retrieve data from tables in a (hopefully) quick and efficient manner, but they certainly don't do any of the clever stuff you find inside Sql server like map reduce, caching, indexing etc. The clever bits are what we do in the unibasic code. So I firmly believe there IS a case for the clever Unibasic code we write to access data over http, read in xml and to then process all of these different data streams. Yeah sure there are things which in theory are easier to do outside It does not mean you should always do things outside of unibasic. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Brutzman Sent: 03 October 2012 23:48 To: U2 Users List Subject: Re: [U2] Consuming Web Services Tony and Ben are right on... Invoking Stephen Colbert's concept of... The Word... the word is... MiddleWare. As legacy U2 was ahead of its time... by building-in middleware technologies... it is easy to lose sight of what belongs where. --Bill -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: Wednesday, October 03, 2012 6:31 PM Subject: Re: [U2] Consuming web services I do the same as Ben but with .NET: -- Local U2 .NET client web service Remote server Pick is a database server, not a communications protocol end-point. We simply should not be doing direct comms from this platform anymore, given the huge number of mainstream options. This is coming from someone who has written all of the bi-directional comms interfaces to/from MV with sockets and cURL and plugins and anything else I could create - because (in the 90's) people said it wasn't possible and because I figured it would be kewl just to do it. It _is_ all technically possible, but that doesn't mean it makes good business sense: Doing things like this in BASIC creates a maintenance hassle later. It leaves the environment subject to DBMS-specific issues that often aren't addressed for quite a long time. Using mainstream tools vastly increases the resources available for getting help and solving problems. So these days I get MV to push a query or data payload out to a middle-tier that uses the latest communications methods available. The request goes out, the response comes back, it all just works - that That should be our bottom line here. HTH T From: Ben Souther We use a middle layer written in Java. Jeff Schasny wrote: I know we have both the SOAP and RESTful web services development for publishing web services from Universe but how are folks consuming other peoples web services into the database? Are there tools for this or am I going to just open a socket, read, and parse 'till I'm blue in the face? ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Consuming Web Services
Ok so perhaps there is this and that. My point is a database like SQL server is architected in a very different manner to U2 - it is the actual central sqlserver.exe process that does the majority of the work, it accesses the tables and presents them to the api, its caching often used data, it obeys the schema, transaction, referential, indexing rules, it map reduces collations and totals, it looks after security, pools, licencing a whole plethora of things. Thereis a lot more out of the box inside SQL server than there is from U2 (again not saying it is better, just different) The central U2 processes look after licencing, locks, shared memory subroutines and a few other things. It is the udt or uvsh client process in which your databasic runs that has built into it the DB access code this is the key difference I feel, and hence why I feel clever unibasic code has a right to do clever things with sockets and xml etc. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: 04 October 2012 09:20 To: u2-users@listserver.u2ug.org Subject: Re: [U2] Consuming Web Services A U2 Table *can* also have referential integrity, it's an option. And SQL Table don't force referential integrity, you can turn that off :) -Original Message- From: Symeon Breen syme...@gmail.com To: 'U2 Users List' u2-users@listserver.u2ug.org Sent: Thu, Oct 4, 2012 1:17 am Subject: Re: [U2] Consuming Web Services I know - but you have to set it up against specific attributes and it creates a fairly standard index for the specified attributes in hand, you do that on sql as well, but it does its own indexing to make row retrieval optimised, has its own referential integrity rules around that etc. It's quite a different beast altogether. I am not saying it is better, but it does a lot more inside than U2 does. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: 04 October 2012 09:05 To: u2-users@listserver.u2ug.org Subject: Re: [U2] Consuming Web Services The U2 database does do indexing. -Original Message- From: Symeon Breen syme...@gmail.com To: 'U2 Users List' u2-users@listserver.u2ug.org Sent: Thu, Oct 4, 2012 12:56 am Subject: Re: [U2] Consuming Web Services But we all know U2 is much more than a DB, in fact it is also much less than a DB. The concept of having the DB just do DB stuff works fine for SQL server and MySQL where the DB itself actually does a lot in terms of the data, and the clients, written in .NET, C, Python Java etc do all the business logic. For these stored procedures do exist but are usually kept to a minimum and certainly only for data interaction. The U2 databases are actually quite stupid, they store and retrieve data from tables in a (hopefully) quick and efficient manner, but they certainly don't do any of the clever stuff you find inside Sql server like map reduce, caching, indexing etc. The clever bits are what we do in the unibasic code. So I firmly believe there IS a case for the clever Unibasic code we write to access data over http, read in xml and to then process all of these different data streams. Yeah sure there are things which in theory are easier to do outside It does not mean you should always do things outside of unibasic. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Brutzman Sent: 03 October 2012 23:48 To: U2 Users List Subject: Re: [U2] Consuming Web Services Tony and Ben are right on... Invoking Stephen Colbert's concept of... The Word... the word is... MiddleWare. As legacy U2 was ahead of its time... by building-in middleware technologies... it is easy to lose sight of what belongs where. --Bill -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: Wednesday, October 03, 2012 6:31 PM Subject: Re: [U2] Consuming web services I do the same as Ben but with .NET: -- Local U2 .NET client web service Remote server Pick is a database server, not a communications protocol end-point. We simply should not be doing direct comms from this platform anymore, given the huge number of mainstream options. This is coming from someone who has written all of the bi-directional comms interfaces to/from MV with sockets and cURL and plugins and anything else I could create - because (in the 90's) people said it wasn't possible and because I figured it would be kewl just to do it. It _is_ all technically possible, but that doesn't mean it makes good business sense: Doing things like this in BASIC creates a maintenance hassle later. It leaves the environment subject to DBMS-specific issues that often aren't addressed for quite a long time. Using mainstream tools vastly increases the resources
Re: [U2] Consuming Web Services
On 04/10/12 09:43, Symeon Breen wrote: Ok so perhaps there is this and that. My point is a database like SQL server is architected in a very different manner to U2 But that's why U2 is superior :-) - it is the actual central sqlserver.exe process that does the majority of the work, it accesses the tables and presents them to the api, its caching often used data, Which U2 actually does far better - (a) it leaves it to the OS, and (b) with a disk hit rate approaching 100% it doesn't need the cache that often (that's badly put, but I know what I mean :-) it obeys the schema, transaction, referential, indexing rules, it map reduces collations and totals, it looks after security, pools, licencing a whole plethora of things. Thereis a lot more out of the box inside SQL server than there is from U2 (again not saying it is better, just different) That's what gets me - U2 is often assumed to be inferior because it doesn't have the things SQL databases have, when the reality is it doesn't have them because it doesn't need them! The central U2 processes look after licencing, locks, shared memory subroutines and a few other things. It is the udt or uvsh client process in which your databasic runs that has built into it the DB access code this is the key difference I feel, and hence why I feel clever unibasic code has a right to do clever things with sockets and xml etc. But it would be nice if more of these things (even if written in BASIC, which is a *good* thing) actually came out of the box with U2. Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Consuming Web Services
I was not trying to say sql server is better or worse than U2 just Different - hence supporting my argument that xml and socket calls are OK in unibasic -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wols Lists Sent: 04 October 2012 10:20 To: u2-users@listserver.u2ug.org Subject: Re: [U2] Consuming Web Services On 04/10/12 09:43, Symeon Breen wrote: Ok so perhaps there is this and that. My point is a database like SQL server is architected in a very different manner to U2 But that's why U2 is superior :-) - it is the actual central sqlserver.exe process that does the majority of the work, it accesses the tables and presents them to the api, its caching often used data, Which U2 actually does far better - (a) it leaves it to the OS, and (b) with a disk hit rate approaching 100% it doesn't need the cache that often (that's badly put, but I know what I mean :-) it obeys the schema, transaction, referential, indexing rules, it map reduces collations and totals, it looks after security, pools, licencing a whole plethora of things. Thereis a lot more out of the box inside SQL server than there is from U2 (again not saying it is better, just different) That's what gets me - U2 is often assumed to be inferior because it doesn't have the things SQL databases have, when the reality is it doesn't have them because it doesn't need them! The central U2 processes look after licencing, locks, shared memory subroutines and a few other things. It is the udt or uvsh client process in which your databasic runs that has built into it the DB access code this is the key difference I feel, and hence why I feel clever unibasic code has a right to do clever things with sockets and xml etc. But it would be nice if more of these things (even if written in BASIC, which is a *good* thing) actually came out of the box with U2. Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Consuming Web Services
Very true and I agree that the DB Server (SQL, et al) and the DB client engine (UV) models each have pros and cons. UV is a lightweight DB and application engine with some very good capabilities in the DB and application area. Plus of course some truly powerful features too! It is not the best or worse in any of these fields. It fills its own little niche very nicely. UV has had some truly good native SQL engine abilities (schemas, tables, triggers, integrity constraints, stored procedures, dynamic normalisation of multi-valued fields, etc) for a long time. Not tacked on like the UD counterparts. But next to no one uses them. As they would break your legacy application. Plus if you created a new application/DB using it - you may as well use a read SQL database server! Some of the nifty features of true SQL DB servers are really to work around the limitations of the relational model and how you store your data (requiring complex joins, queries, etc). Which tends to make those nifty features essential. Whereas SQL DB servers are progress in leaps and bounds in many different and diverse ways and this is where they truly diverge - be it to cater for massive databases or distributed or failover-active/active database clusters, etc., of any data type or structure you could imagine. Whereas the U2 database engine has not really progressed or evolved much at all in reality - that is not a bad thing. Adding various extensions to the traditional PICK/U2 application interfaces is a very good thing. It does add lots of functions that are truly useful - requiring minimal effort and zero install or cost (a key requirement for lots of sites). If you need something better AND you have local talent to build/maintain it (or consultancy budget) - then go again and do it. :) There are many examples of organisations using their own interfaces/extensions - because they can afford something better that works for them. Your mileage and budgetary will vary! Hence, as you imply - use each database - exploiting their inherent strengths. Use the right tool for the right job. Every tool has its sweet spot! ;) I won't mention the number of MS Access databases out there doing real work...groan! -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Symeon Breen Sent: Thursday, 4 October 2012 5:56 PM To: 'U2 Users List' Subject: Re: [U2] Consuming Web Services But we all know U2 is much more than a DB, in fact it is also much less than a DB. The concept of having the DB just do DB stuff works fine for SQL server and MySQL where the DB itself actually does a lot in terms of the data, and the clients, written in .NET, C, Python Java etc do all the business logic. For these stored procedures do exist but are usually kept to a minimum and certainly only for data interaction. The U2 databases are actually quite stupid, they store and retrieve data from tables in a (hopefully) quick and efficient manner, but they certainly don't do any of the clever stuff you find inside Sql server like map reduce, caching, indexing etc. The clever bits are what we do in the unibasic code. So I firmly believe there IS a case for the clever Unibasic code we write to access data over http, read in xml and to then process all of these different data streams. Yeah sure there are things which in theory are easier to do outside It does not mean you should always do things outside of unibasic. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Brutzman Sent: 03 October 2012 23:48 To: U2 Users List Subject: Re: [U2] Consuming Web Services Tony and Ben are right on... Invoking Stephen Colbert's concept of... The Word... the word is... MiddleWare. As legacy U2 was ahead of its time... by building-in middleware technologies... it is easy to lose sight of what belongs where. --Bill -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: Wednesday, October 03, 2012 6:31 PM Subject: Re: [U2] Consuming web services I do the same as Ben but with .NET: -- Local U2 .NET client web service Remote server Pick is a database server, not a communications protocol end-point. We simply should not be doing direct comms from this platform anymore, given the huge number of mainstream options. This is coming from someone who has written all of the bi-directional comms interfaces to/from MV with sockets and cURL and plugins and anything else I could create - because (in the 90's) people said it wasn't possible and because I figured it would be kewl just to do it. It _is_ all technically possible, but that doesn't mean it makes good business sense: Doing things like this in BASIC creates a maintenance hassle later. It leaves the environment subject to DBMS-specific
Re: [U2] Consuming Web Services
Getting back to the original question: In most, but not all cases, I use: UniVerse = (socket) = .NET Service - Web Service Where the .net service is not necessarily on the same machine as UniVerse (security/firewalling restrictions). Using UniVerse sockets to drive services is something I do in a lot of my applications (mvPDF, mvDistributor etc.) and works well. I also have routines for calling web services directly over UniVerse sockets, but you don't get the advantages of WSDL import and XML/JSON serialization built into .Net. The CallHTTP stuff is a pretty rubbish set of functions over the top of the socket API and XDOM is horrible so it's easier and more flexible to do your own if you're going that way :) As for the other stuff: we all love the u2 model (or we wouldn't be here) but that shouldn't blind us to the fact that there are areas where the implementation could be improved: indexing is one of those. Using cache better is probably another, but restricted by the fact that this is a multi-process model: caching would be much easier for single process, multithreaded servers that don't have to load shared memory segments to make data visible to all participants. In a replication scenario, for example, being able to replicate directly to a subscribers' cache could have advantages if you don't need the subscriber to guarantee that it has committed to disk in good time (unless it suddenly becomes a publisher/fail-over when it has to sync the cache).. Brian ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Consuming web services
createRequest setRequestHeader addRequestParameter SubmitRequest All unibasic functions for working with http -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Jeff Schasny Sent: 03 October 2012 21:56 To: U2-Users@listserver.u2ug.org Subject: [U2] Consuming web services I know we have both the SOAP and RESTful web services development for publishing web services from Universe but how are folks consuming other peoples web services into the database? Are there tools for this or am I going to just open a socket, read, and parse 'till I'm blue in the face? -- Jeff Schasny - Denver, Co, USA jschasny at gmail dot com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Consuming Web Services
I don't understand what's wrong with indexing, can you clarify this point, and I'll wipe out a fix in three days :) -Original Message- From: Brian Leach br...@brianleach.co.uk To: 'U2 Users List' u2-users@listserver.u2ug.org Sent: Thu, Oct 4, 2012 4:05 am Subject: Re: [U2] Consuming Web Services Getting back to the original question: In most, but not all cases, I use: UniVerse = (socket) = .NET Service - Web Service Where the .net service is not necessarily on the same machine as UniVerse (security/firewalling restrictions). Using UniVerse sockets to drive services is something I do in a lot of my applications (mvPDF, mvDistributor etc.) and works well. I also have routines for calling web services directly over UniVerse sockets, but you don't get the advantages of WSDL import and XML/JSON serialization built into .Net. The CallHTTP stuff is a pretty rubbish set of functions over the top of the socket API and XDOM is horrible so it's easier and more flexible to do your own if you're going that way :) As for the other stuff: we all love the u2 model (or we wouldn't be here) but that shouldn't blind us to the fact that there are areas where the implementation could be improved: indexing is one of those. Using cache better is probably another, but restricted by the fact that this is a multi-process model: caching would be much easier for single process, multithreaded servers that don't have to load shared memory segments to make data visible to all participants. In a replication scenario, for example, being able to replicate directly to a subscribers' cache could have advantages if you don't need the subscriber to guarantee that it has committed to disk in good time (unless it suddenly becomes a publisher/fail-over when it has to sync the cache).. Brian ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Consuming Web Services
The closest we get is we have a WCF service host that maintains a block of logins for all of our .net apps that use UniObjects and handles running the subs through the service reference. -Original Message- From: Brian Leach br...@brianleach.co.uk To: 'U2 Users List' u2-users@listserver.u2ug.org Sent: Thu, Oct 4, 2012 4:05 am Subject: Re: [U2] Consuming Web Services Getting back to the original question: In most, but not all cases, I use: UniVerse = (socket) = .NET Service - Web Service Where the .net service is not necessarily on the same machine as UniVerse (security/firewalling restrictions). Using UniVerse sockets to drive services is something I do in a lot of my applications (mvPDF, mvDistributor etc.) and works well. I also have routines for calling web services directly over UniVerse sockets, but you don't get the advantages of WSDL import and XML/JSON serialization built into .Net. The CallHTTP stuff is a pretty rubbish set of functions over the top of the socket API and XDOM is horrible so it's easier and more flexible to do your own if you're going that way :) As for the other stuff: we all love the u2 model (or we wouldn't be here) but that shouldn't blind us to the fact that there are areas where the implementation could be improved: indexing is one of those. Using cache better is probably another, but restricted by the fact that this is a multi-process model: caching would be much easier for single process, multithreaded servers that don't have to load shared memory segments to make data visible to all participants. In a replication scenario, for example, being able to replicate directly to a subscribers' cache could have advantages if you don't need the subscriber to guarantee that it has committed to disk in good time (unless it suddenly becomes a publisher/fail-over when it has to sync the cache).. Brian ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] XLr8Editor update 3.5.12 [ad]
In keeping with our goal to have continual releases, U2logic is proud to announce the release of 3.5.12. We are cleaning up a few bugs and other things that have come up. We are back focusing on the XLr8Editor and XLr8Dictionary editor. v3.5.12 - October 04, 2012 Bugzilla [Bug 513] - XLr8Editor needs a popup error message when reporting item locked item. Bugzilla [Bug 459] - XLr8Editor color coding fails with back slashes and either double quotes or single quotes. Bugzilla [Bug 436] - XLr8Dictionary Editor needs to allow Value Marked character entry. 1) Fixed bug in continuous compile reporting errors to the console 2) Fixed miscellaneous errors messages that where wrong. Regards, Doug www.u2logic.com/tools.html ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] Tim Bryant passed away last week
at the age of 48 from a heart attack/stroke this was announced on the manage 2000 user group last week but i just wanted to send something to this group to cover all bases. he was a great guy and will be missed by all ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] [UD] Odd question re: 7.1 docs
I just found this in the UDT.OPTIONS manual... If UDT.OPTIONS 107 is off, UniData returns incorrect multivalues from the target file. Here's my question. With that description in mind, why would anyone want this to be off? ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UD] Odd question re: 7.1 docs (Unclassified)
At a guess, an important customer relies on the behaviour that the option turns off and lost the argument about whether this was a feature-not-a-bug rather than a bug-not-a-feature Regards Mike -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Friday, 5 October 2012 3:19 p.m. To: U2 Users List Subject: [U2] [UD] Odd question re: 7.1 docs I just found this in the UDT.OPTIONS manual... If UDT.OPTIONS 107 is off, UniData returns incorrect multivalues from the target file. Here's my question. With that description in mind, why would anyone want this to be off? ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users The information contained in this Internet Email message is intended for the addressee only and may contain privileged information, but not necessarily the official views or opinions of the New Zealand Defence Force. If you are not the intended recipient you must not use, disclose, copy or distribute this message or the information in it. If you have received this message in error, please Email or telephone the sender immediately. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
