Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "DSDP/TM/Face-to-face Toronto 23-Feb-2006"

< DSDP‎ | TM
 
Line 19: Line 19:
 
=== Symbian TM Demo ===
 
=== Symbian TM Demo ===
 
* Presentation to be posted
 
* Presentation to be posted
 +
*  Test Automation Tool (STAT), with an FTP Proxy on the host (for translation)
 +
* Browse / Send / Execute / Install / Restart; FTP Proxy supporting multiple PC clients (and 1 target) - with semaphore: only 1 client allowed at any time.
 +
* New system: multiple services on the target (STAT broken up) - SMDCP: Simple Multiplexed Device Control Protocol, Symbian specific
 +
* TM Daemon: Based on proposal from Pierre-Alexandre: query availability of ServiceTypes, TM UI to display available ones
 +
** Planning to contribute the "yellow" parts in Open Source (the interfaces) ; "green" implementation to remain proprietory at Symbian.
 +
** Debugging TBD as just another service
 +
* FileZilla: Raw FTP commands for installing and launching
 +
* Future: Want services like install, uninstall, process list ... defined and available in TM system.
 +
  
 
=== RSE Demo and Architecture ===
 
=== RSE Demo and Architecture ===
 
* [http://www.eclipse.org/downloads/download.php?file=/dsdp/tm/presentations/2006-2-23_Toronto_TM_RSE.ppt Presentation] by Dave McKnight
 
* [http://www.eclipse.org/downloads/download.php?file=/dsdp/tm/presentations/2006-2-23_Toronto_TM_RSE.ppt Presentation] by Dave McKnight
 +
* RSE Demo
 +
** Ability to cancel shell commands?
 +
** RSE Files View: Contextmenu, Run > Host C/C++ Application
 +
*** Remote Source Locator integrated with Remote Launch
 +
** "Attach" Launches directly from the RSE View:
 +
*** Re-uses existing Launch with same properties (potentially overwrite old "similar" launch)
 +
** Same for Remote Java Launches
 +
** Classifying remote files: dstore running a "file" command on the remote in order to find out the file type
 +
** Seamless File Transfer: need conflict detection on multi-user machines (if file is simultaneously modified while edited on client)
 +
* RSE Architecture
 +
** IHostFile: the simple data
 +
** Connector Service: Manage passwords etc.
 +
** As long as no subsystem extension for Files exists, the Subsystem definition won't be loaded
 +
** Pete Nicholls: Can bundle RSE in Rich Client Platform?
 +
*** Should be possible.. no more strong dependencies
 +
** Persistence: Persistence Providers can be registered to persist the RSE DOM.
 +
*** DOM is everything above the actual RSE objects: connections, filters, actions, ...
 +
*** FelixB: Use Persistence Providers to auto-discover remote systems?
 +
**** MartinO: Looking at use-cases, detecting a new remote system is an explicit step that can be done via an import wizard. There is littel use in automiatically populating the list of local connections ("my favorites") with automatically detected connections.
 +
** System Registry API
 +
*** Used by the Persistence Provider to create RSE objects, read them and persist them.
 +
*** Persistence Provider is called whenever something is modified
 +
** Creating the FTP Subsystem
 +
*** Subclass AbstractFileService, implementing IFileService
 +
*** Subclass FileSubsystemConfiguration and register it as SubSystemConfiguration extension
 +
*** Reason for layering: Once filters etc. are defined for a subsystem, these shold remain available when you switch protocols
 +
*** Most of the work in FTP was the parsers for directory listings etc. (which depend on the host system type with the Sun FTP client)
 +
** Contributing a brand-new subsystem type
 +
*** Doing the layering (subystem - service) is possible, but not required. Vendor can choose to make the separation or not (in practice, the separationg might make sense... in case it turns out that the original choice of protocol is to be revised at some later time
 +
*** Shared Protocol is possible: a single service can be used to populate multiple subsystems
 +
*** Subsystem is providing a lot of re-usable code... e.g. integration with the Eclipse Jobs model
 +
** Debugging / Attaching: Is Debugging a Service?
 +
*** So far, more used it as an Action (making use of the Files / Processes subsystem) and not a service
 +
*** Pete Nicholls created a Debug Subsystem, allowing to register various things there
 +
*** Martin O: Two usage models - (a) launching a debugger, (b) using a debugger to retrieve system info or manipulate the remote system (to populate a subsystem)
 +
*** Tom Hochstein: Want to use (reference) connection data in the Launches - Martin O: That's already there (referencing a connection by dropdown)
 +
** File Export / Import: can take a list of local files and transfer them to the remote system, and save the configuration information (about the list of files) in a configuration -- very much like the JAR export
 +
** External Tools > Remote Build, Remoe Command
 +
** Associate a local project with RSE connections (such that local changes are automatically synced to the remote system)?
 +
** Creating a new SubSystem:
 +
*** Extend abstract SubSystem
 +
**** Methods to override: connect(), disconnect(),
 +
**** Every query (expansion) comes down to resolveFilterString()
 +
**** Initial List of Objects need to adapt to SystemViewElementAdapter; these adapters define what should happen when they are further expanded. That way, the elements (objects) can decide if they want to do caching etc.
 +
**** The master implementation of SubSystem implements resolveFilterString() itself, in order to create Jobs for retrieving the information -- subsystems only need to implement InternalResolveFilterString()
 +
**** See IBM "Universal Sample"
 +
***** getObjectWithAbsoluteName()
 +
*** AaronS: It might make sense to even have a dummy server on some port , just for showing how the subsystem works
 +
** MartinO: How are events from the target handled?
 +
*** RSE allows asynchronous retrieval of information: when a large directory (e.g. lib) is expanded, DataStore first returns the list of file names and forks off a job for analyzing the type of files. Decorartors are create later, in response to a DataStore Event from the target
 +
*** Dstore should be able to transfer any classes (miners) to the remote system and execute them there - but this has not really been explored so far
 +
** Aaron: Relation to TPTP?
 +
*** RSE works in User Space, whereas the TPTP agent lives in System space
 +
** FelixB: The new Debug Model with its Flexible Hierarchy - might it make sense using this for the RSE Tree?
 +
*** Since the RSE view is totally Adapter diven, it is pretty flexible already now, so there is probably no need for adopting the Debug Model
 +
** Pawel P: Performance Issues?
 +
*** Yes, there can exist queries that are extremely large or extremely costly to run...
 +
*** UI Rendering can get pretty expensive, though not seen a very expensive rendering for a long time
 +
**** MartinO: Yes rendering Search Results can be expensive when it's 10000s of results
 +
**** As long as the query is cancelable (in a job) and the UI isnt blocked, it's OK
 +
* AaronS: People want to just monitor remote systems (e.g. with TPTP) without attaching a debugger... RSE should allow to select a particular context, and choose "Attach Profiler" from the contextmenu, such that profiling information is recorded...
 +
** Mentor already have an adaptor for their proprietory protocol to what TPTP expects (the adapter runs on the host) - TPPT thinks it connects to the localhost
 +
** TPTP also talking to BIRT folks for getting reports
  
 
=== Component-Based Launching ===
 
=== Component-Based Launching ===
 
* [http://www.eclipse.org/downloads/download.php?file=/dsdp/tm/presentations/2006-2-23_Toronto_TM_LaunchActions.ppt Presentation] by Martin O
 
* [http://www.eclipse.org/downloads/download.php?file=/dsdp/tm/presentations/2006-2-23_Toronto_TM_LaunchActions.ppt Presentation] by Martin O
 +
* KenRyall: Better decouple the Launch Action Framework from RSE, such that it can be used independently of RSE
 +
* KenRyall: What script to use? - A slippery slope... would like to script debuggers, or the whole Eclipse IDE
 +
** MartinO: yes -- perhaps best keep the Launch scripts extremely simple though it is tempting to make them more complex
 +
* PawelP: Expect that the Generic Launch UI would not be exposed to the user, but specialized Launch UIs would make use of the component framework
 +
* JohnCortell: Consider using ANT for the Launch scripts
 +
* Darian Wong, Felix Burton: will need Target Groups to execute same action on a list of targets
 +
* Paul Gingrich: Suggest scripts to be stored-away components of their own: users tend having to execute the same sequence of steps again and again, with different parameters
 +
** Martin O: might use Eclipse Variables in order to make actions (and scripts) configurable; create "super Actions" that just reference other actions. Doing that in the UI is difficult.
  
 
== Minutes - Friday TM session ==
 
== Minutes - Friday TM session ==

Revision as of 15:38, 26 February 2006

Agenda & Attendee List

Presentations

Minutes - Thursday TM session

See DD Meeting Notes for the Joint Session:

  • Doug G - Update on DSDP, Plans for EclipseCon
  • Hobson Bullman - Introduction to SPIRIT
  • Doug G - WR's data file standards
  • Aaron Spear - Hardware Descriptions at Mentor / SPIRIT Requirements for DSDP

Symbian TM Demo

  • Presentation to be posted
  • Test Automation Tool (STAT), with an FTP Proxy on the host (for translation)
  • Browse / Send / Execute / Install / Restart; FTP Proxy supporting multiple PC clients (and 1 target) - with semaphore: only 1 client allowed at any time.
  • New system: multiple services on the target (STAT broken up) - SMDCP: Simple Multiplexed Device Control Protocol, Symbian specific
  • TM Daemon: Based on proposal from Pierre-Alexandre: query availability of ServiceTypes, TM UI to display available ones
    • Planning to contribute the "yellow" parts in Open Source (the interfaces) ; "green" implementation to remain proprietory at Symbian.
    • Debugging TBD as just another service
  • FileZilla: Raw FTP commands for installing and launching
  • Future: Want services like install, uninstall, process list ... defined and available in TM system.


RSE Demo and Architecture

  • Presentation by Dave McKnight
  • RSE Demo
    • Ability to cancel shell commands?
    • RSE Files View: Contextmenu, Run > Host C/C++ Application
      • Remote Source Locator integrated with Remote Launch
    • "Attach" Launches directly from the RSE View:
      • Re-uses existing Launch with same properties (potentially overwrite old "similar" launch)
    • Same for Remote Java Launches
    • Classifying remote files: dstore running a "file" command on the remote in order to find out the file type
    • Seamless File Transfer: need conflict detection on multi-user machines (if file is simultaneously modified while edited on client)
  • RSE Architecture
    • IHostFile: the simple data
    • Connector Service: Manage passwords etc.
    • As long as no subsystem extension for Files exists, the Subsystem definition won't be loaded
    • Pete Nicholls: Can bundle RSE in Rich Client Platform?
      • Should be possible.. no more strong dependencies
    • Persistence: Persistence Providers can be registered to persist the RSE DOM.
      • DOM is everything above the actual RSE objects: connections, filters, actions, ...
      • FelixB: Use Persistence Providers to auto-discover remote systems?
        • MartinO: Looking at use-cases, detecting a new remote system is an explicit step that can be done via an import wizard. There is littel use in automiatically populating the list of local connections ("my favorites") with automatically detected connections.
    • System Registry API
      • Used by the Persistence Provider to create RSE objects, read them and persist them.
      • Persistence Provider is called whenever something is modified
    • Creating the FTP Subsystem
      • Subclass AbstractFileService, implementing IFileService
      • Subclass FileSubsystemConfiguration and register it as SubSystemConfiguration extension
      • Reason for layering: Once filters etc. are defined for a subsystem, these shold remain available when you switch protocols
      • Most of the work in FTP was the parsers for directory listings etc. (which depend on the host system type with the Sun FTP client)
    • Contributing a brand-new subsystem type
      • Doing the layering (subystem - service) is possible, but not required. Vendor can choose to make the separation or not (in practice, the separationg might make sense... in case it turns out that the original choice of protocol is to be revised at some later time
      • Shared Protocol is possible: a single service can be used to populate multiple subsystems
      • Subsystem is providing a lot of re-usable code... e.g. integration with the Eclipse Jobs model
    • Debugging / Attaching: Is Debugging a Service?
      • So far, more used it as an Action (making use of the Files / Processes subsystem) and not a service
      • Pete Nicholls created a Debug Subsystem, allowing to register various things there
      • Martin O: Two usage models - (a) launching a debugger, (b) using a debugger to retrieve system info or manipulate the remote system (to populate a subsystem)
      • Tom Hochstein: Want to use (reference) connection data in the Launches - Martin O: That's already there (referencing a connection by dropdown)
    • File Export / Import: can take a list of local files and transfer them to the remote system, and save the configuration information (about the list of files) in a configuration -- very much like the JAR export
    • External Tools > Remote Build, Remoe Command
    • Associate a local project with RSE connections (such that local changes are automatically synced to the remote system)?
    • Creating a new SubSystem:
      • Extend abstract SubSystem
        • Methods to override: connect(), disconnect(),
        • Every query (expansion) comes down to resolveFilterString()
        • Initial List of Objects need to adapt to SystemViewElementAdapter; these adapters define what should happen when they are further expanded. That way, the elements (objects) can decide if they want to do caching etc.
        • The master implementation of SubSystem implements resolveFilterString() itself, in order to create Jobs for retrieving the information -- subsystems only need to implement InternalResolveFilterString()
        • See IBM "Universal Sample"
          • getObjectWithAbsoluteName()
      • AaronS: It might make sense to even have a dummy server on some port , just for showing how the subsystem works
    • MartinO: How are events from the target handled?
      • RSE allows asynchronous retrieval of information: when a large directory (e.g. lib) is expanded, DataStore first returns the list of file names and forks off a job for analyzing the type of files. Decorartors are create later, in response to a DataStore Event from the target
      • Dstore should be able to transfer any classes (miners) to the remote system and execute them there - but this has not really been explored so far
    • Aaron: Relation to TPTP?
      • RSE works in User Space, whereas the TPTP agent lives in System space
    • FelixB: The new Debug Model with its Flexible Hierarchy - might it make sense using this for the RSE Tree?
      • Since the RSE view is totally Adapter diven, it is pretty flexible already now, so there is probably no need for adopting the Debug Model
    • Pawel P: Performance Issues?
      • Yes, there can exist queries that are extremely large or extremely costly to run...
      • UI Rendering can get pretty expensive, though not seen a very expensive rendering for a long time
        • MartinO: Yes rendering Search Results can be expensive when it's 10000s of results
        • As long as the query is cancelable (in a job) and the UI isnt blocked, it's OK
  • AaronS: People want to just monitor remote systems (e.g. with TPTP) without attaching a debugger... RSE should allow to select a particular context, and choose "Attach Profiler" from the contextmenu, such that profiling information is recorded...
    • Mentor already have an adaptor for their proprietory protocol to what TPTP expects (the adapter runs on the host) - TPPT thinks it connects to the localhost
    • TPTP also talking to BIRT folks for getting reports

Component-Based Launching

  • Presentation by Martin O
  • KenRyall: Better decouple the Launch Action Framework from RSE, such that it can be used independently of RSE
  • KenRyall: What script to use? - A slippery slope... would like to script debuggers, or the whole Eclipse IDE
    • MartinO: yes -- perhaps best keep the Launch scripts extremely simple though it is tempting to make them more complex
  • PawelP: Expect that the Generic Launch UI would not be exposed to the user, but specialized Launch UIs would make use of the component framework
  • JohnCortell: Consider using ANT for the Launch scripts
  • Darian Wong, Felix Burton: will need Target Groups to execute same action on a list of targets
  • Paul Gingrich: Suggest scripts to be stored-away components of their own: users tend having to execute the same sequence of steps again and again, with different parameters
    • Martin O: might use Eclipse Variables in order to make actions (and scripts) configurable; create "super Actions" that just reference other actions. Doing that in the UI is difficult.

Minutes - Friday TM session

TM Project Plan

  • See the Plan on the main website

Target Connection Adapter Update

Technology Subgroups and Future Plans

Action Items

Copyright © Eclipse Foundation, Inc. All Rights Reserved.