Re: MIME type meta-data

In a message dated: Wed, 05 Mar 2003 00:05:10 +0100
=?UTF-8?B?QnJhbmtvIMSMaWJlag==?= said:

>Paul Lussier wrote:
>
>>The file(1) depends upon the /etc/magic and /usr/share/misc/magic
>>files, and maps the data returned from the stat(2) call to these
>>files to determine type. Granted, this is very UNIX centric, but if
>>other platforms don't natively contain these files, couldn't svn or
>>apr ship with their own versions for those platforms like file(1)
>>does?
>>
>>
>
>Nononono! Other systems have other ways of determining the mime type. On
>Windows, for example, file extensions (and their mime types) are defined
>in the Registry, and there's a standard way of finding the mime type. We
>shouldn't go inventing our own.

Hmmm, I wasn't really advocating for re-inventing the wheel, rather
re-packaging a good wheel for platforms without one :)

However, since other platforms most likely have a native mechanism to
determine mime-type, then why not just rely upon the platforms
ability to do so correctly? Or is that the problem, we don't
necessarilly trust the platform's accuracy?

Is there some way to do this all portably without writing a different
'get_mime_type()' for each platform and using #IFDEFs to build the
correct one?

>*however*
>
>If we make this a completely client-side feature, different clients will
>behave differently when adding new files to the same repository. Ouch,
>eek and yikes.

Well, yeah, but would they necessarilly act differently upon the same
files being committed to the same repository? If so, then I echo
your 'Ouch, eek, and yikes!'.

>So I think this sort of mime type configuration should be
>a feature of the repository, with the clients just using the
>configuration from the repo. We've talked before about server-side
>configuration for clients, and haven't come up with a sane design, yet.

But wouldn't having this as a repo feature cause a performance hit?
What about a server-dictated config for the repo located on the
client? In otherwords, another file in the .svn/ dir?
The file would/could be managed on the server, and read-only on the
client. The client can use this 'map' to determine mime-types of
new files added based on 'magic numbers' contained in the server-side
config file. Though, that is rather like re-inventing the wheel if
the client has a native ability to determine mime-types.

Hmmm, this is a dilemma :)

-- 
Seeya,
Paul
--
Key fingerprint = 1660 FECC 5D21 D286 F853  E808 BB07 9239 53F1 28EE
	It may look like I'm just sitting here doing nothing,
   but I'm really actively waiting for all my problems to go away.
	 If you're not having fun, you're not doing it right!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org