Improved Login Infrastructure for Data Abstract

i've just finished implementing a new feature in Data Abstract (.NET and OS X, for now, but the same will be ported over to Delphi before we ship the summer releases in May) that takes care of one my my pet peeves with the old system: Login.

In general, RO/DA has a pretty sophisticated system in place for handling login (explicitly, or implicitly when sessions timed out or the first call failed due to lack of authorization) and session management, but there was one part that was not very standardized: the Login() method itself.

Basically, different templates provided different Login() methods - for example one taking just Username/Password, another taking Username, Password and an additional Connection Name, if your server app supports different back-end connections.

These of course keep working, but we've added a new LoginEx() method on the base service, which takes just one parameter: a Login String. Think of a Login String as you would of a connection string in, say, ADO - a collection of parameter/value pairs separated by semicolons.

For the default login services, LoginEx is implemented to parse user name, password and connection name out of the string and call Login() - so if you have implemented Login methods in your services, these will transparently work with new clients calling LoginEx(). But - and that is the important part - when writing new servers you can choose to implement LoginEx instead, and get much more flexibility in what needs to be passed in from the client.

The big benefit, of course, is that *client* applications can now be written to just call LoginEx without having to worry what set of parameters need to be passed to Login(). The same code can talk to a single- or multi-database - or, say, to the upcoming DAServer6, which will expect user name, password and a domain to connect to* - just by using the appropriate connection string