SOAP - Client (Win32) / Server (Web) - where are the limitations

[Wolfgang Orth]

Hello Bruce and all others!

For several reasons I am using TPS and am quite happy with that. Nonetheless I try to make my app more robust, so I thought of using the IP-Driver. But in my opinion its too "monstrous" and beside that I was not able to get it running out of the box. I know others do, but that is not help for me.

My idea is to have Win32-Clients on the network, sending requests to SOAP-Server, receiving back datasets to display.

Those Win32-Clients may be distributed onto the Client-machine, running locally there, or may be called from a desktop-link, IOW they are actually still sitting somewhere on a server. But thats a problem of the admins and how they want to maintain the install.

I have played with Example 42 SOAP-Server, which nearly covers what I think of. But other than the Example 42, I have to display quite some listboxes.

Does anyone have experiences about the limitating numbers, about how many records can be transferred and displayed?

My idea is to display the received dataset with InMemory-tables. I am in the comfortable situatiuon that the large tables, 1000 to 2000 records, are for reading only. The number of records in some listboxes that get written, is relative small, just 20 or 30 records. Think of thousands of CUSTOMERS, with thousands of INVOICES, but only one invoice will actually be listed in a listbox and these items are set for writing back intoi the TPS on the server.

Anyway, sending 1000 CUSTOMER records from the server to be listed in the clients listbox (page-/file-loaded?) for picking the right one, is that a reasonable scenario with a Client/Server combo based on SOAP and XML?

What would be the appropriate driver on the client-side? InMemory? Queue?

What do I have to expect when I send back a single record for writing back into the TPS, when in a multi-user-environment?

Is it worthwile to continue on such a scenario at all?

Thanks for your patience,
Wolfgang

[kevin plummer]

It seems to me an incredible amount of work where at the end of the day you will need to mimic the mechanics of a web server app as a desktop app. The 2 big issues I see is concurrency and sending large volumes of data. Both are doable and latter via views or zipping and sending your customer file are possible but a lot of work.

[Bruce]

Hi Wolfgang,

you are doing this the hard way to avoid doing it the easy way.
My suggestion would be to get the IP driver working. there may be a bit of effort in doing that, but it's not rocket science, and should be straight-forward enough. If you are struggling then I recommend asking on the newsgroups for help. Or pay someone to assist you in implementing it.

Trying to duplicate all the functionality of the file driver system, and everything that's built on top of it with nettalk, would be a mountain of effort.

If you are going to build a whole new client, then you're probably better off just building a web server and letting the browser be the client. At least that way you won't have to hand-code all the functionality. (just for a browse you'd need to figure out mechanisms for page-loading, locators, sort-orders and so on - it'd be a mountain of work.)

cheers
Bruce

[Wolfgang Orth]

Hmmmm

IP-Driver

hmmmm



hmmmm


thx