You are viewing a plain text version of this content. The canonical link for it is here.
Posted to stonehenge-dev@incubator.apache.org by "Avantika Agrawal (JIRA)" <ji...@apache.org> on 2009/06/12 19:29:07 UTC
[jira] Updated: (STONEHENGE-66) Create a .NET Config Service
[ https://issues.apache.org/jira/browse/STONEHENGE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Avantika Agrawal updated STONEHENGE-66:
---------------------------------------
Attachment: Stonehenge-66.patch
Here's what I have so far.
You will find a new folder called Config_Service which hs the same structure as the OrderProcessor_Service - it should have a ConfigServiceSolution
Also, there are some addtions made to the common folder - an IConfig interface and its implementation.
I am sticking with the format of the php. Ben, you may find that I changed your contract very slightly, but this is in line with the php format so I don't think it should be an issue. I have left comments in areas which still need work. Moreover, I have not implemented setActiveDB, getDBConfig, and other methos relating to DB configuration yet - I think we should come to those later, once we have this service up and running.
This service builds successfully but it is not running. I am getting a few errors. Will update this when those are fixed, but for now, you guys can take a look at what I've done so far and send me any feedback you may have.
> Create a .NET Config Service
> ----------------------------
>
> Key: STONEHENGE-66
> URL: https://issues.apache.org/jira/browse/STONEHENGE-66
> Project: Stonehenge
> Issue Type: New Feature
> Reporter: Avantika Agrawal
> Priority: Minor
> Attachments: Stonehenge-66.patch
>
>
> Implement Ben's ConfigContract to create a configuration service attached to the .NET Client
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
RE: [jira] Updated: (STONEHENGE-66) Create a .NET Config Service
Posted by "Drew Baird (Volt)" <a-...@microsoft.com>.
We will have the same chicken and egg dilemma with metro
Cardinal rule should be to never check in broken code or code that breaks the build.
Other than that; ask: does it make sense?
another 2 cents
Drew
________________________________________
From: Scott Golightly [scott_golightly@hotmail.com]
Sent: Friday, June 12, 2009 2:52 PM
To: Stonehenge Development
Subject: RE: [jira] Updated: (STONEHENGE-66) Create a .NET Config Service
There is probably an already established precedence but my vote would be to only commit completed code. If I want to test the current code I can do so from the patch.
Just my 2 cents.
Scott Golightly
> From: Ben.Dewey@26ny.com
> To: stonehenge-dev@incubator.apache.org
> Date: Fri, 12 Jun 2009 17:30:53 -0400
> Subject: RE: [jira] Updated: (STONEHENGE-66) Create a .NET Config Service
>
> In regards to the items needed in the future (ie set/get DbConfig):
>
> What's the procedure for commiting code that has two parts or planned upgrades?
> Should we avoid committing a bunch of commented-out code?
> Should we just commit code that’s directly applicable?
>
> -Ben
>
>
> -----Original Message-----
> From: Avantika Agrawal (JIRA) [mailto:jira@apache.org]
> Sent: Friday, June 12, 2009 3:29 PM
> To: stonehenge-dev@incubator.apache.org
> Subject: [jira] Updated: (STONEHENGE-66) Create a .NET Config Service
>
>
> [ https://issues.apache.org/jira/browse/STONEHENGE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Avantika Agrawal updated STONEHENGE-66:
> ---------------------------------------
>
> Attachment: Stonehenge-66.patch
>
> Here's what I have so far.
>
> You will find a new folder called Config_Service which hs the same structure as the OrderProcessor_Service - it should have a ConfigServiceSolution
> Also, there are some addtions made to the common folder - an IConfig interface and its implementation.
>
> I am sticking with the format of the php. Ben, you may find that I changed your contract very slightly, but this is in line with the php format so I don't think it should be an issue. I have left comments in areas which still need work. Moreover, I have not implemented setActiveDB, getDBConfig, and other methos relating to DB configuration yet - I think we should come to those later, once we have this service up and running.
>
> This service builds successfully but it is not running. I am getting a few errors. Will update this when those are fixed, but for now, you guys can take a look at what I've done so far and send me any feedback you may have.
>
>
> > Create a .NET Config Service
> > ----------------------------
> >
> > Key: STONEHENGE-66
> > URL: https://issues.apache.org/jira/browse/STONEHENGE-66
> > Project: Stonehenge
> > Issue Type: New Feature
> > Reporter: Avantika Agrawal
> > Priority: Minor
> > Attachments: Stonehenge-66.patch
> >
> >
> > Implement Ben's ConfigContract to create a configuration service attached to the .NET Client
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
RE: [jira] Updated: (STONEHENGE-66) Create a .NET Config Service
Posted by Ben Dewey <Be...@26ny.com>.
Currently the config overhaul project is broken into 3+ tickets.
1. Create a .NET Config service that doesn't talk to anything
2. Modify .NET to communicate thru the config service
3. Upgrade config service to send its own endpoint address for lookup in the services table.
4. Create Config UI tab in clients and make any additional config service upgrades, etc
None of these should break the build, but #1 is arguable not entirely useful without #2, so should #1 not get committed until #2 is completed as well?
Also, my previous question was specifically geared towards implementing functionally for #4 in ticket #1. Is that jumping the gun? Should we leave it out until the time comes to work on #4? For the record my thoughts are that we should.
-Ben
-----Original Message-----
From: Scott Golightly [mailto:scott_golightly@hotmail.com]
Sent: Friday, June 12, 2009 5:52 PM
To: Stonehenge Development
Subject: RE: [jira] Updated: (STONEHENGE-66) Create a .NET Config Service
There is probably an already established precedence but my vote would be to only commit completed code. If I want to test the current code I can do so from the patch.
Just my 2 cents.
Scott Golightly
> From: Ben.Dewey@26ny.com
> To: stonehenge-dev@incubator.apache.org
> Date: Fri, 12 Jun 2009 17:30:53 -0400
> Subject: RE: [jira] Updated: (STONEHENGE-66) Create a .NET Config Service
>
> In regards to the items needed in the future (ie set/get DbConfig):
>
> What's the procedure for commiting code that has two parts or planned upgrades?
> Should we avoid committing a bunch of commented-out code?
> Should we just commit code that's directly applicable?
>
> -Ben
>
>
> -----Original Message-----
> From: Avantika Agrawal (JIRA) [mailto:jira@apache.org]
> Sent: Friday, June 12, 2009 3:29 PM
> To: stonehenge-dev@incubator.apache.org
> Subject: [jira] Updated: (STONEHENGE-66) Create a .NET Config Service
>
>
> [ https://issues.apache.org/jira/browse/STONEHENGE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Avantika Agrawal updated STONEHENGE-66:
> ---------------------------------------
>
> Attachment: Stonehenge-66.patch
>
> Here's what I have so far.
>
> You will find a new folder called Config_Service which hs the same structure as the OrderProcessor_Service - it should have a ConfigServiceSolution
> Also, there are some addtions made to the common folder - an IConfig interface and its implementation.
>
> I am sticking with the format of the php. Ben, you may find that I changed your contract very slightly, but this is in line with the php format so I don't think it should be an issue. I have left comments in areas which still need work. Moreover, I have not implemented setActiveDB, getDBConfig, and other methos relating to DB configuration yet - I think we should come to those later, once we have this service up and running.
>
> This service builds successfully but it is not running. I am getting a few errors. Will update this when those are fixed, but for now, you guys can take a look at what I've done so far and send me any feedback you may have.
>
>
> > Create a .NET Config Service
> > ----------------------------
> >
> > Key: STONEHENGE-66
> > URL: https://issues.apache.org/jira/browse/STONEHENGE-66
> > Project: Stonehenge
> > Issue Type: New Feature
> > Reporter: Avantika Agrawal
> > Priority: Minor
> > Attachments: Stonehenge-66.patch
> >
> >
> > Implement Ben's ConfigContract to create a configuration service attached to the .NET Client
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
RE: [jira] Updated: (STONEHENGE-66) Create a .NET Config Service
Posted by Scott Golightly <sc...@hotmail.com>.
There is probably an already established precedence but my vote would be to only commit completed code. If I want to test the current code I can do so from the patch.
Just my 2 cents.
Scott Golightly
> From: Ben.Dewey@26ny.com
> To: stonehenge-dev@incubator.apache.org
> Date: Fri, 12 Jun 2009 17:30:53 -0400
> Subject: RE: [jira] Updated: (STONEHENGE-66) Create a .NET Config Service
>
> In regards to the items needed in the future (ie set/get DbConfig):
>
> What's the procedure for commiting code that has two parts or planned upgrades?
> Should we avoid committing a bunch of commented-out code?
> Should we just commit code that’s directly applicable?
>
> -Ben
>
>
> -----Original Message-----
> From: Avantika Agrawal (JIRA) [mailto:jira@apache.org]
> Sent: Friday, June 12, 2009 3:29 PM
> To: stonehenge-dev@incubator.apache.org
> Subject: [jira] Updated: (STONEHENGE-66) Create a .NET Config Service
>
>
> [ https://issues.apache.org/jira/browse/STONEHENGE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Avantika Agrawal updated STONEHENGE-66:
> ---------------------------------------
>
> Attachment: Stonehenge-66.patch
>
> Here's what I have so far.
>
> You will find a new folder called Config_Service which hs the same structure as the OrderProcessor_Service - it should have a ConfigServiceSolution
> Also, there are some addtions made to the common folder - an IConfig interface and its implementation.
>
> I am sticking with the format of the php. Ben, you may find that I changed your contract very slightly, but this is in line with the php format so I don't think it should be an issue. I have left comments in areas which still need work. Moreover, I have not implemented setActiveDB, getDBConfig, and other methos relating to DB configuration yet - I think we should come to those later, once we have this service up and running.
>
> This service builds successfully but it is not running. I am getting a few errors. Will update this when those are fixed, but for now, you guys can take a look at what I've done so far and send me any feedback you may have.
>
>
> > Create a .NET Config Service
> > ----------------------------
> >
> > Key: STONEHENGE-66
> > URL: https://issues.apache.org/jira/browse/STONEHENGE-66
> > Project: Stonehenge
> > Issue Type: New Feature
> > Reporter: Avantika Agrawal
> > Priority: Minor
> > Attachments: Stonehenge-66.patch
> >
> >
> > Implement Ben's ConfigContract to create a configuration service attached to the .NET Client
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
RE: [jira] Updated: (STONEHENGE-66) Create a .NET Config Service
Posted by Ben Dewey <Be...@26ny.com>.
In regards to the items needed in the future (ie set/get DbConfig):
What's the procedure for commiting code that has two parts or planned upgrades?
Should we avoid committing a bunch of commented-out code?
Should we just commit code that’s directly applicable?
-Ben
-----Original Message-----
From: Avantika Agrawal (JIRA) [mailto:jira@apache.org]
Sent: Friday, June 12, 2009 3:29 PM
To: stonehenge-dev@incubator.apache.org
Subject: [jira] Updated: (STONEHENGE-66) Create a .NET Config Service
[ https://issues.apache.org/jira/browse/STONEHENGE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Avantika Agrawal updated STONEHENGE-66:
---------------------------------------
Attachment: Stonehenge-66.patch
Here's what I have so far.
You will find a new folder called Config_Service which hs the same structure as the OrderProcessor_Service - it should have a ConfigServiceSolution
Also, there are some addtions made to the common folder - an IConfig interface and its implementation.
I am sticking with the format of the php. Ben, you may find that I changed your contract very slightly, but this is in line with the php format so I don't think it should be an issue. I have left comments in areas which still need work. Moreover, I have not implemented setActiveDB, getDBConfig, and other methos relating to DB configuration yet - I think we should come to those later, once we have this service up and running.
This service builds successfully but it is not running. I am getting a few errors. Will update this when those are fixed, but for now, you guys can take a look at what I've done so far and send me any feedback you may have.
> Create a .NET Config Service
> ----------------------------
>
> Key: STONEHENGE-66
> URL: https://issues.apache.org/jira/browse/STONEHENGE-66
> Project: Stonehenge
> Issue Type: New Feature
> Reporter: Avantika Agrawal
> Priority: Minor
> Attachments: Stonehenge-66.patch
>
>
> Implement Ben's ConfigContract to create a configuration service attached to the .NET Client
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
RE: [jira] Updated: (STONEHENGE-66) Create a .NET Config Service
Posted by Avantika Agrawal <t-...@microsoft.com>.
Hi Ben,
Thanks for the feedback. I will make the changes to the patch and probably upload an updated version today.
With regards to the approach, here's what I had in mind. I was thinking of delivering the ConfigService in two phases, with the first phase offering very basic functionality and a basic UI. This case doesn't deal with the case of multiple clients, multiple DBs, addition and deletion of endpoints, etc.
For this phase, I definitely agree with you that only three operations would probably be required for this ticket (I was going for the 1st approach you mentioned). I implemented the others thinking that we'd probably need them for the UI - setBSToOPS, setClientToOPS would probably be used when the user selects the services from the front-end. GetServiceLocations, getClientToBSConnections, getBSToOPSConnections - these could also be useful when populating drop-down lists for the UI. But like you said, this may be jumping the gun for this ticket.
I think that the second phase will give us the opportunity to discuss what additional features we want this config service to offer - this will probably include the case of multiple clients, multiple DBs, and possible changes to the structure of the DB. For these issues, we will probably need to use the other operations setActiveDB, getDBConfig. Also, in this phase we may want to consider the idea of having the UI take care of addition of new endpoints and new services. The reason I thought of tabling these issues to Phase II is that I think we should get a configService up and running before we deal with additional complexity.
These are just my thoughts on this service so let me know what you think. I am also in the process of documenting a specification for this service, which may clarify some ideas mentioned here.
Thanks,
Avantika
-----Original Message-----
From: Ben Dewey [mailto:Ben.Dewey@26ny.com]
Sent: Friday, June 12, 2009 2:20 PM
To: 'stonehenge-dev@incubator.apache.org'
Subject: RE: [jira] Updated: (STONEHENGE-66) Create a .NET Config Service
Avantika,
Great start, Here is a list of some comments.
- The Config Configuration Settings should really only include DB connString/user/password
- Same for the ConfigConsole App.config
- don't include your .sou files in the patches (they fail anyways)
- The IDAL, DALFac, DALSql Config.cs and IConfig.cs files were added to the csproj files, but not included in the patch.
- Can you describe the use cases for the operations you've setup? I think there still some unnecessary operations in yours.
I can think of two different approaches both have only 3 operations.
1. (how PHP does it) Get your own config before any operation, this includes your database info and your next parties endpoint info (getconfig would return db info+bs address)
- in this scenario all we need is GetClientConfig, GetBsConfig, GetOpsConfig
// ClientConfigResponse GetClientConfig(ClientConfigRequest client)
// BsConfigResponse GetBsConfig(BsConfigRequest client)
// OpsConfigResponse GetOpsConfig(OpsConfigRequest client)
2. Get the active endpoints or database depending on what you need
- in this scenario you'd have GetActiveDb, GetBsForClient, GetOpsForBs
// DbConfigResponse GetActiveDb()
// EndpointConfigResponse GetBsForClient(string client)
// EndpointConfigResponse GetOpsForBs(string bs)
To me it comes down to the return type objects, in scenario 1, we need custom inputs/outputs for everything. In scenario 2 we could use common strings, DbConfig, and EndpointConfig objects.
Now, this is really the basic level and we need to try to think forward a bit to what we might have with the full new UI. For this ticket I would stick to something along these lines.
I'd like to hear your thoughts and any other Use Cases you are planning for.
-Ben
-----Original Message-----
From: Avantika Agrawal (JIRA) [mailto:jira@apache.org]
Sent: Friday, June 12, 2009 3:29 PM
To: stonehenge-dev@incubator.apache.org
Subject: [jira] Updated: (STONEHENGE-66) Create a .NET Config Service
[ https://issues.apache.org/jira/browse/STONEHENGE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Avantika Agrawal updated STONEHENGE-66:
---------------------------------------
Attachment: Stonehenge-66.patch
Here's what I have so far.
You will find a new folder called Config_Service which hs the same structure as the OrderProcessor_Service - it should have a ConfigServiceSolution
Also, there are some addtions made to the common folder - an IConfig interface and its implementation.
I am sticking with the format of the php. Ben, you may find that I changed your contract very slightly, but this is in line with the php format so I don't think it should be an issue. I have left comments in areas which still need work. Moreover, I have not implemented setActiveDB, getDBConfig, and other methos relating to DB configuration yet - I think we should come to those later, once we have this service up and running.
This service builds successfully but it is not running. I am getting a few errors. Will update this when those are fixed, but for now, you guys can take a look at what I've done so far and send me any feedback you may have.
> Create a .NET Config Service
> ----------------------------
>
> Key: STONEHENGE-66
> URL: https://issues.apache.org/jira/browse/STONEHENGE-66
> Project: Stonehenge
> Issue Type: New Feature
> Reporter: Avantika Agrawal
> Priority: Minor
> Attachments: Stonehenge-66.patch
>
>
> Implement Ben's ConfigContract to create a configuration service attached to the .NET Client
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
RE: [jira] Updated: (STONEHENGE-66) Create a .NET Config Service
Posted by Ben Dewey <Be...@26ny.com>.
Avantika,
Great start, Here is a list of some comments.
- The Config Configuration Settings should really only include DB connString/user/password
- Same for the ConfigConsole App.config
- don't include your .sou files in the patches (they fail anyways)
- The IDAL, DALFac, DALSql Config.cs and IConfig.cs files were added to the csproj files, but not included in the patch.
- Can you describe the use cases for the operations you've setup? I think there still some unnecessary operations in yours.
I can think of two different approaches both have only 3 operations.
1. (how PHP does it) Get your own config before any operation, this includes your database info and your next parties endpoint info (getconfig would return db info+bs address)
- in this scenario all we need is GetClientConfig, GetBsConfig, GetOpsConfig
// ClientConfigResponse GetClientConfig(ClientConfigRequest client)
// BsConfigResponse GetBsConfig(BsConfigRequest client)
// OpsConfigResponse GetOpsConfig(OpsConfigRequest client)
2. Get the active endpoints or database depending on what you need
- in this scenario you'd have GetActiveDb, GetBsForClient, GetOpsForBs
// DbConfigResponse GetActiveDb()
// EndpointConfigResponse GetBsForClient(string client)
// EndpointConfigResponse GetOpsForBs(string bs)
To me it comes down to the return type objects, in scenario 1, we need custom inputs/outputs for everything. In scenario 2 we could use common strings, DbConfig, and EndpointConfig objects.
Now, this is really the basic level and we need to try to think forward a bit to what we might have with the full new UI. For this ticket I would stick to something along these lines.
I'd like to hear your thoughts and any other Use Cases you are planning for.
-Ben
-----Original Message-----
From: Avantika Agrawal (JIRA) [mailto:jira@apache.org]
Sent: Friday, June 12, 2009 3:29 PM
To: stonehenge-dev@incubator.apache.org
Subject: [jira] Updated: (STONEHENGE-66) Create a .NET Config Service
[ https://issues.apache.org/jira/browse/STONEHENGE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Avantika Agrawal updated STONEHENGE-66:
---------------------------------------
Attachment: Stonehenge-66.patch
Here's what I have so far.
You will find a new folder called Config_Service which hs the same structure as the OrderProcessor_Service - it should have a ConfigServiceSolution
Also, there are some addtions made to the common folder - an IConfig interface and its implementation.
I am sticking with the format of the php. Ben, you may find that I changed your contract very slightly, but this is in line with the php format so I don't think it should be an issue. I have left comments in areas which still need work. Moreover, I have not implemented setActiveDB, getDBConfig, and other methos relating to DB configuration yet - I think we should come to those later, once we have this service up and running.
This service builds successfully but it is not running. I am getting a few errors. Will update this when those are fixed, but for now, you guys can take a look at what I've done so far and send me any feedback you may have.
> Create a .NET Config Service
> ----------------------------
>
> Key: STONEHENGE-66
> URL: https://issues.apache.org/jira/browse/STONEHENGE-66
> Project: Stonehenge
> Issue Type: New Feature
> Reporter: Avantika Agrawal
> Priority: Minor
> Attachments: Stonehenge-66.patch
>
>
> Implement Ben's ConfigContract to create a configuration service attached to the .NET Client
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.