Select 2.4 ConfigDb

[roteague]

I see that some of the most basic settings for an instance of Select are now stored within the SelectConfigDb, which I see as a good thing. However, there are still a number of settings in the Select.exec.config file that look to be good candidates for storing in this database as well. This leads me to a couple of questions:

Are there any plans on moving more config settings to the database?
Will there be a publicly exposed API to allow users to store information in this database as well?
Will there be a publicly exposed method to determine which pool an instance of Select is running under?

Thanks,

Robert

[John Morris]

At this point, we are not moving any other settings, however, as the need arises, we can certainly evaluate the need. Which settings do you see as being candidates for relocation?

There is an API into the configuration store, however, we have not made it public (yet). As for custom values being stored in that database, we did not plan to enable that scneario.Can you give me some examples of how you would use that feature?

Using the previously mentioned API, you can easily determine which pool a server is member of, so when you make this API public (and we will), this ability will there.

[roteague]

John,

We would like to see most of the items in the SoftPro.Select.Settings key in the ConfigDb (except the Window state ones); these are items we may want to control, based upon our workload, any system errors we see, or just changes to how we monitor our SP installations. I understand this would impact startup time of the application and other factors, so it woudn't be a major item we would like to see.

Currently, we store a number of settings in the Select.exe.config file that our packages use; for example, database connection strings, WebService and WCF endpoint addresses. We use these to integrate Select with out Document Management System, for example, as well as other backend systems. My thought was that if I could at least get the id (guid) of the pool, we could create our own configuration database, which would share the same ID that you use for as a Pool ID. That way, all our of config settings could move to our own config database, with the exception of the WCF endpoint we would need to talk to this database.

I've got a custom management tool (written in .NET 4.0) that helps me keep track of the health of our SP installation, and our custom designed packages and snap sections. So, whatever API you eventually expose would help us.

Thanks for the feedback,

[John Morris]

Robert,

The Select Server mid-tier and client side API allow for the addition of services by 3rd parties. You could add your own "config" service, removing the need to store the settings in the select.exe.config file. That should allow you to centrally manage your settings. The API design of Select is designed to allow this, but you would be the first external party to begin leveraging it. This ability exists now.

If you're interested in this approach, we should probably setup a phone call to discuss the details. A webex session may even be helpful here.

Cheers!

[roteague]

Robert,

The Select Server mid-tier and client side API allow for the addition of services by 3rd parties. You could add your own "config" service, removing the need to store the settings in the select.exe.config file. That should allow you to centrally manage your settings. The API design of Select is designed to allow this, but you would be the first external party to begin leveraging it. This ability exists now.

If you're interested in this approach, we should probably setup a phone call to discuss the details. A webex session may even be helpful here.

Cheers!

John,

Sorry for not getting back to you sooner, I'm working on other aspects and got busy. I'll talk this over with my manager, and see if we can do this after I finish my current project.