On Wed, 23 Jan 2002 11:10, Adam Murdoch wrote:
> * Guarantee that certain functionality is available in all providers, and
> behaves consistently across all providers. Some examples: providers must
> handle paths with / and \ separators. Or, providers must throw an
> exception on an attempt to read the content of something that is not a
> file. Searching would also fall under this category - providers will have
> to support searching, and will have to be able to handle the Ant-style path
> wildcards. ("provider" here means "provider, with the help of the VFS
> framework").
cool. So like JNDI there will be a separate "SearchControl" and perhaps
separate "NameParsers"?
> * Make other functionality optional, but guarantee that it behaves
> consistently across all providers for which it is available. Some
> examples: Delete must be recursive, if delete is supported. Or, the
> parent folder must be implicitly created when writing to a new file, if
> writing to files is supported.
ok.
> * Allow provider-specific functionality to be exposed, but make no
> guarantees about its availablility, or portability. Some examples: The
> set of attributes supported for files is unspecified. Or caching - a
> provider can cache whatever and however it wants.
works for me - so the set of attributes is defined purely by the
provider/filesystem combo. Will it be possible for a user to associate
attributes with files in the build file or anything like that ?
> I think that the tasks' needs should drive where a particular feature sits.
> Features like concurrency detection can start in the third category, and
> work their way up, if they prove useful.
+1
BTW when are you going to submit your source ;)
--
Cheers,
Pete
----------------------------------------
Whatever you do will be insignificant,
but it is very important that you do it.
--Gandhi
----------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
