Bug 216596 - [api] Request a Connection time-out Preference setting (for dstore, at least)
Summary: [api] Request a Connection time-out Preference setting (for dstore, at least)
Status: RESOLVED FIXED
Alias: None
Product: Target Management
Classification: Tools
Component: RSE (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P3 enhancement (vote)
Target Milestone: 3.0 M5   Edit
Assignee: David McKnight CLA
QA Contact: Martin Oberhuber CLA
URL:
Whiteboard:
Keywords: api
Depends on:
Blocks:
 
Reported: 2008-01-25 10:47 EST by Samuel Wu CLA
Modified: 2008-02-13 15:51 EST (History)
3 users (show)

See Also:


Attachments
patch containing dstore preferences page (13.45 KB, patch)
2008-01-25 12:19 EST, David McKnight CLA
no flags Details | Diff
updated patch with pref to not show mismatched server warning (19.07 KB, patch)
2008-01-25 13:51 EST, David McKnight CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Samuel Wu CLA 2008-01-25 10:47:29 EST
When connecting to a remote host and the host doesn't respond within a certain mount of time, the connection will timed-out. The current time out is 300 seconds and can't be change. 
A preferences page is needed to expose the time-out so that the user can change it to fit the environment.
Comment 1 David McKnight CLA 2008-01-25 12:19:08 EST
Created attachment 87881 [details]
patch containing dstore preferences page

I've added a patch with this new preference page.  Does this work for you?
Comment 2 David McKnight CLA 2008-01-25 13:51:24 EST
Created attachment 87899 [details]
updated patch with pref to not show mismatched server warning

I updated the patch to include a preference for not showing a mismatched server warning.
Comment 3 Martin Oberhuber CLA 2008-01-28 07:52:05 EST
Isn't the connection timeout something that one might want to be different for multiple different hosts?

For my SSH hosts, for instance, I want a small timeout for those that I know to be on the local LAN. But when I connect to the Eclipse.org servers, which are about 4000 miles away, I want a longer timeout.

Matters get yet a bit more complex when multiple different protocols are used to access a single host: For instance FTP filesystem + Telnet shell -- should there be one and the same timeout for both, or separate timeouts for each?

My personal feeling is that I'd prefer a single timeout per host, which all protocols should honor. The UI control could be on the page where host name and address are entered. I could also imagine an "Advanced" button on that page, such that the contributed SystemType decides what kinds of UI should be behind that "Advanced" button.

Any other thoughts?
Comment 4 David McKnight CLA 2008-01-28 09:30:00 EST
(In reply to comment #3)
> Isn't the connection timeout something that one might want to be different for
> multiple different hosts?
> For my SSH hosts, for instance, I want a small timeout for those that I know to
> be on the local LAN. But when I connect to the Eclipse.org servers, which are
> about 4000 miles away, I want a longer timeout.
> Matters get yet a bit more complex when multiple different protocols are used
> to access a single host: For instance FTP filesystem + Telnet shell -- should
> there be one and the same timeout for both, or separate timeouts for each?
> My personal feeling is that I'd prefer a single timeout per host, which all
> protocols should honor. The UI control could be on the page where host name and
> address are entered. I could also imagine an "Advanced" button on that page,
> such that the contributed SystemType decides what kinds of UI should be behind
> that "Advanced" button.
> Any other thoughts?

Even if there were a host-specific preference for specifying this, it would still be useful to have a preference to indicate the defaults.  For dstore, we know this preference makes sense, while for other protocols it may or may not make sense.  I guess we could implement a connector service to use the preference in SSH and FTP but for other services that get contributed how would you suggest we enforce the use of this preference?
Comment 5 Martin Oberhuber CLA 2008-02-01 08:24:02 EST
New API:
IUniversalDStoreConstants.ALERT_MISMATCHED_SERVER
IUniversalDStoreConstants.DEFAULT_ALERT_MISMATCHED_SERVER
Comment 6 Kevin Doyle CLA 2008-02-01 11:00:01 EST
Dave,

If you change the preferences and click Okay the preferences aren't saved.  You need to click Apply first.  Also should the preference page be DataStore(capital S)?
Comment 7 David McKnight CLA 2008-02-01 12:36:00 EST
(In reply to comment #6)
> Dave,
> If you change the preferences and click Okay the preferences aren't saved.  You
> need to click Apply first.  Also should the preference page be
> DataStore(capital S)?

I guess we should call it DataStore.  I've fixed the okay problem.  I'm going to mark this fixed.  For non-dstore connection preference issues, separate defects should be used.