[haiku-commits] Re: Aw: Re: haiku: hrev47086 - in src: kits/media servers/media

  • From: Stephan Aßmus <superstippi@xxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Wed, 02 Apr 2014 20:51:58 +0200

Hi,

Am 02.04.2014 17:59, schrieb Axel Dörfler:
Am 02/04/2014 16:57, schrieb Stephan Aßmus:
2) To get a specific codec for a given format without knowing the list
of codecs. This one is also interesting, since it triggers each time a
file is opened.

Why wouldn't it address that? Where have I written that it would not
address that?
Just caching the names would be completely superfluous. That's actually
a pretty fast operation. Loading the add-on, and executing it is what's
expensive, and should be avoided as long as possible in the client.

You specifically said the application would do the work, the media_server would then cache it. That rules out any benefit of the cache for the application startup, since the work would have to be done at least once. Or do you mean one application would benefit from another of the same architecture having started before it and having populated the cache?

If this form of caching is desired, then the media server should simply
have one add-on scanning sub-service per architecture. And it should
forward the requests it receives from clients to the one matching the
client architecture. I did suggest this in IRC yesterday.

That sounds indeed like the best solution so far.

Ok. But it involves some work.

But one problem with this whole discussions is that the list of add-ons
is reduced to one, the ffmpeg addon. The performance concerns are rather
pointless, given that all that will most likely ever happen from here on
is the ffmpeg plugin getting fixes and supporting more and more formats.
Why would there ever be additional codec plugins anymore?

640kb will be enough for anybody. Fact is, you don't know the future.
Besides that, we already had a good, scalable, caching implementation.

Only in theory. In practice it always rescanned the list.

Replacing that with an inferior mechanism in order to add a feature
makes me shudder.

Practically it only added a feature, and a rather important one. One aspect of the discussion is how important that removed /theoretical/ feature even is.

Even that one add-on could make a difference in application
responsiveness, anyway.

In theory, sure.

Best regards,
-Stephan


Other related posts: