Hi Marc,
Oops, I've made a mistake when I wrote the mail. There is no
distinction between a file with no extension and a file with unknown
extensions.
At the end of the process, the variant must be completed with either
its "natural metadata" or some default ones. That's what I wanted to
say.
> By the way: the instance-of checking on the subclass of Metadata is a
> bit messy (not very OO/polimorfism) I would suggest refactoring to adding:
Thanks for the suggestion!
best regards,
Thierry Boileau
On Mon, Feb 25, 2008 at 8:55 PM, Marc Portier <[EMAIL PROTECTED]> wrote:
>
>
> Thierry Boileau wrote:
> > Hello Marc,
> >
> > thanks a lot for tracking this bug. The first path has been chosen
>
> cool, and thx.
>
>
> > because of symetry, and because there is a distinction between a file
> > having no extensions and a file having extensions not registered by
> > the metadataService.
> >
>
> OK, but I'm unsure if I understand the "distinction" now.
> In the current situation: when a file does not have an extension, then
> no metadata will get loaded in the updateMetadata in LocalClientHelper
> (and thus the default will be added anyway.)
>
> I'm perfectly happy with this solution, but if you _do_ want that to
> have a no-extension mapping to be distinct from the 'default', then I
> would suggest to insert at line 105 something that
>
> // checks for the no extension-case
> if (tokens.length == 1)
> {
> // and makes the association from
> current = getMetadata("");
>
> // and then applying the media-type to the variant
> }
>
>
> By the way: the instance-of checking on the subclass of Metadata is a
> bit messy (not very OO/polimorfism) I would suggest refactoring to adding:
>
> public void applyTo(Variant variant) to the MetaData class
>
> you can either make it abstract there, or let it do nothing
>
> and then have the specific subclasses make the correct implementation.
>
> Inside LocalClientHelper this would replace the complete set of
> if-else "current instanceof" testing with a mere
>
> current.applyTo(variant)
>
>
> HTH,
>
> regards,
> -marc=
>
>
>
> > best regards,
> > Thierry Boileau
> >
> > On Mon, Feb 25, 2008 at 5:16 PM, Marc Portier <[EMAIL PROTECTED]> wrote:
> >> Hi,
> >>
> >> I'm looking for a way to allow PUT on
> >> - file:/// URI's
> >> - to resources that have no extension
> >> - by pushing entities of type "application/octet-stream"
> >> (or whatever would be the metadata-service's default-mime)
> >>
> >> Currently the file-client-helper checks the metadata-consistency of the
> >> file being put.
> >>
> >> This check *always* fails when the file doesn't have an extension at all.
> >>
> >>
> >> To resolve, I see two possible paths:
> >>
> >> [1] let consistency check pass when:
> >> extension doesn't yield a mapped type
> >> AND the type being put matches the default.
> >>
> >> Looking at the MetadataService I see it holding a defaultMediaType, but
> >> that one isn't considered when doing the consistency check. (While the
> >> default-language is, so this would put both in sync more.)
> >>
> >>
> >> [2] allow to assign metadata to the "" extension (empty string)
> >>
> >> I'm not entirely sure how the meaning of 'default' relates to the
> >> meaning of 'no extension', if those have different meaning, then I think
> >> this would be the appropriate way out.
> >>
> >>
> >> I'm tempted to go for [2], but wanted to check here if I'm not
> >> overlooking possible conflicts or yet more elegant solutions, so please
> >> comment.
> >>
> >> As before, I'll be happy to provide the patch for this.
> >>
> >> regards,
> >> -marc=
> >>
> >
>
