The goal is very simple: to make also other than FTP connections appear as integral part of TC, exactly the same as FTP ones.
Lets say we have new group of optional functions that can be implemented by FS plugin. For first two I already presented one possible solution in sftpplug thread. Here they are:
Code: Select all
int __stdcall FsGetBookmarks(void* Bookmarks, PDWORD Size);
Returns list of available connections (bookmarks) that plugin provides.
BOOL __stdcall FsManageBookmarks(char* BookmarkId, int Action);
Tells plugin to add/edit/delete connection (bookmark).
int __stdcall FsOpenConnection(char* BookmarkId, char* OpenUrl, char* UrlString, int maxlen);
Tells plugin to open connection and return it's unique identifier.
int __stdcall FsSelectConnection(int ConnId);
Tells plugin that all following standard commands (FsFindFirst, etc..) should apply to given connection.
int __stdcall FsCloseConnection(int ConnId);
Tells plugin to close connection.- user opens FTP connections dialog
- TC checks available FS plugins if they implement the above functions
- if they don't, nothing happens
- it they do, TC calls FsGetBookmarks() and adds the plugin connections to the list
- user chooses to open some plugin-provided connection
- TC calls FsOpenConnection() with connection (bookmark) identifier (char* BookmarkId) and receives new connection id; it also receives plugin-generated URL representing root of current connection (char* UrlString), eg. "sftp://user@some.server.net/" for display to user
- because the connection is now uniquely identified, TC can easily add the "<number> drive" for it, same as for internal FTP connections
- TC calls FsSelectConnection(id) to tell plugin that following commands will be for given connection and paths are relative to it's root
- if user switches to another connection provided by same plugin, TC just calls FsSelectConnection(anotherid); it's no problem for TC to know where the user currently is
Usage for quick connection:
- user opens FTP quick connection dialog
- TC checks available FS plugins if they implement the above functions
- if they don't, nothing happens
- if any of them do, TC adds combobox "connection type" listing available plugins
- user enters some URL and selects plugin type; it's because the same URL can be handled by more plugins, eg. http:// can be used for many things (WebDAV, plain HTTP download, ...); this part can use some work, e.g. plugins could provide some info about supported URL schemes and the more choices would be presented only if more plugins are installed for the same URL scheme
- TC calls FsOpenConnection with given URL (char* OpenUrl) instead of BookmarkId which will be NULL
- the rest is as above
The whole thing would be optional. So filesystem plugins where connections make no sense (ext2fs, undelete, ...), would just not implement it. Together with centralized bookmarks and "<number> drive" it solves another limitation of current FS plugins (sftpplug, ...), the easy way to connect to one server multiple times with different usernames ("easy" meaning without creating separate bookmarks for every username). It's also backward compatible, the plugin can still make the connections accessible in Network neighbourhood where they're now.
What do you think? Comments, suggestions, spotted flaws? Or should I just stop dreaming and forget about it? :)