Difference between revisions of "DTP Connectivity Project Committers Meeting Minutes: September 29, 2008"

From Eclipsepedia

Jump to: navigation, search
(Agenda)
 
(2 intermediate revisions by one user not shown)
Line 11: Line 11:
 
*Early discussion of API refactoring
 
*Early discussion of API refactoring
 
*One possibility
 
*One possibility
**Connection Profiles contain properties for connecting to various systems/services
+
**Today
**Driver Templates are plug-in supplied extensions defining an initial set of property values
+
***Connection Profiles contain properties for connecting to various systems/services
**Driver Definitions are defined instances of Driver Templates contain properties
+
***Driver Templates are plug-in supplied extensions defining an initial set of property values
**Skip Driver Definitions and allow users to modify/clone/create Driver Templates
+
***Driver Definitions are defined instances of Driver Templates contain properties
**System Driver Templates are those defined by plug-ins
+
**Possibility
**User Driver Templates are those created/modified by users
+
***Skip Driver Definitions and allow users to modify/clone/create Driver Templates
**Connection Profiles then are simply a property cache with an applied template
+
**So...
**Exported profiles would contain references to the template used to create them that could be used to re-create the template if necessary upon import.
+
***System Driver Templates are those defined by plug-ins
**The Driver Management preference page becomes a Driver Template Management preference page where users can see available system and user-created driver templates. Users can clone an existing template, delete a user-created template, edit a user-created template, and so on.
+
***User Driver Templates are those created/modified by users
**The benefit of killing driver instances is that an exported connection profile is complete without one.
+
***Connection Profiles then are simply a property cache with an applied template
**The bad side is that we can no longer share a driver instance to get things like the jar list from.
+
**Other thoughts
**We can work around that by having listeners for driver template updates and prompt the user if an update happens (or do it silently behind the scenes). If the user wants the changes, the appropriate fields could be updated in affected connection profiles.
+
***Exported profiles would contain references to the template and template values used to create them that could be used to re-create the template if necessary upon import.
**We should also possibly provide a "validation" action that would allow the user to see if their connection profile properties were up to date (perhaps store something like a "last update" date stamp for both connection profiles and driver templates) and prompt the user to see if they want their connection profiles updated accordingly if discrepancies (driver templates & connection profiles out of sync) exist.
+
***The Driver Management preference page becomes a Driver Template Management preference page where users can see available system and user-created driver templates. Users can clone an existing template, delete a user-created template, edit a user-created template, and so on.
 +
***The benefit of killing driver instances is that an exported connection profile is complete without one.
 +
***The bad side is that we can no longer share a driver instance to get things like the jar list from.
 +
***We can work around that by having listeners for driver template updates and prompt the user if an update happens (or do it silently behind the scenes). If the user wants the changes, the appropriate fields could be updated in affected connection profiles.
 +
***We should also possibly provide a "validation" action that would allow the user to see if their connection profile properties were up to date (perhaps store something like a "last update" date stamp for both connection profiles and driver templates) and prompt the user to see if they want their connection profiles updated accordingly if discrepancies (driver templates & connection profiles out of sync) exist.
 +
**Questions
 +
***Can a user apply a different template to a connection profile? What effect does that have? Does it change all the profile's property values?
 
*Open discussion
 
*Open discussion
  

Latest revision as of 16:39, 29 September 2008

Back to DTP Connectivity Project Committers' Meeting Page

Contents

[edit] Attendees

  • Brian Fitzpatrick
  • Linda Chan
  • Larry Dunnell

[edit] Regrets

[edit] Agenda

  • Early discussion of API refactoring
  • One possibility
    • Today
      • Connection Profiles contain properties for connecting to various systems/services
      • Driver Templates are plug-in supplied extensions defining an initial set of property values
      • Driver Definitions are defined instances of Driver Templates contain properties
    • Possibility
      • Skip Driver Definitions and allow users to modify/clone/create Driver Templates
    • So...
      • System Driver Templates are those defined by plug-ins
      • User Driver Templates are those created/modified by users
      • Connection Profiles then are simply a property cache with an applied template
    • Other thoughts
      • Exported profiles would contain references to the template and template values used to create them that could be used to re-create the template if necessary upon import.
      • The Driver Management preference page becomes a Driver Template Management preference page where users can see available system and user-created driver templates. Users can clone an existing template, delete a user-created template, edit a user-created template, and so on.
      • The benefit of killing driver instances is that an exported connection profile is complete without one.
      • The bad side is that we can no longer share a driver instance to get things like the jar list from.
      • We can work around that by having listeners for driver template updates and prompt the user if an update happens (or do it silently behind the scenes). If the user wants the changes, the appropriate fields could be updated in affected connection profiles.
      • We should also possibly provide a "validation" action that would allow the user to see if their connection profile properties were up to date (perhaps store something like a "last update" date stamp for both connection profiles and driver templates) and prompt the user to see if they want their connection profiles updated accordingly if discrepancies (driver templates & connection profiles out of sync) exist.
    • Questions
      • Can a user apply a different template to a connection profile? What effect does that have? Does it change all the profile's property values?
  • Open discussion

[edit] Minutes

[edit] Action Items