<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Dear Pasi,<br>
    <br>
    it is a great idea to fork a new line and rewrite code to satisfy
    all requests which been put forward.<br>
    <br>
    Please let me know when you will set a repository and write stable
    code so that I could give it a try. Please make changes quick so
    that people who was waiting for this changes had a chance to have
    better software.<br>
    <br>
    You will be our hero.<br>
    <br>
    NOTE: many demand but few commit time and do it.<br>
    <br>
    Thank you,<br>
    Andy<br>
    <br>
    On 17/12/10 1:58 PM, Pasi Juppo wrote:
    <blockquote cite="mid:4D0BDCE8.9010902@Juppo.fi" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      On 12/15/2010 10:49 PM, Ville Skytt&auml; wrote:<br>
      <span style="white-space: pre;">&gt; On Wednesday 15 December
        2010,<br>
        Jouni Karvo wrote:<br>
        <br>
        &gt;&gt; <br>
        <br>
        &gt;&gt; I think adding dependencies to outside packages is a<br>
        burden that<br>
        <br>
        &gt;&gt; should be avoided. There are already many things I need<br>
        to install<br>
        <br>
        &gt;&gt; separately in order the vdr box to work; kernel,
        graphics<br>
        drivers,<br>
        <br>
        &gt;&gt; and xine-lib. Luckily, lirc is now already part of the<br>
        kernel, and<br>
        <br>
        &gt;&gt; DVB drivers, too; much less hassle than before. This is<br>
        the right<br>
        <br>
        &gt;&gt; direction to go - not adding more moving parts that
        need<br>
        to be<br>
        <br>
        &gt;&gt; installed (with compatible versions).<br>
        <br>
        &gt; <br>
        <br>
        &gt; I'm not saying anything about the epg data as plain text vs<br>
        sqlite<br>
        <br>
        &gt; thing, but would like to note that things are not always
        that<br>
        black<br>
        <br>
        &gt; and white as the above seems to say. In my opinion it does<br>
        not make<br>
        <br>
        &gt; sense to reimplement everything that's required just in
        order<br>
        to<br>
        <br>
        &gt; avoid dependencies (but other valid reasons for not using<br>
        something<br>
        <br>
        &gt; that's already there might of course exist).<br>
        <br>
      </span><br>
      And it's not only to avoid unnecessary wheel inventing but also
      going towards more generic solution of the software itself. If I'm
      not mistaking sqlite would actually help also in multi-instance
      ("server" solution) vdr implementation when each instance would be
      reading/writing from/to same DB but also external tools to
      read/write epg data way more faster than via vdr.<br>
      <br>
      But this depate can go on forever back and forth - probably
      leading to no changes what so ever. Klaus have already decided few
      posts ago to keep the text file based solution. Same goes for
      standalone-server wishes (vdr will not change to server-client
      system). And same for few other features.<br>
      <br>
      That said and with no disrespect to the author of vdr in my
      opinion it starts to be a time to fork vdr and redefine its base +
      few other elements. There are many very talented coders reading
      this mailing-list (+ many others over different vdr related sites)
      who are developing plugins and patches - some being very big. Put
      sources to accessible version control system (almost already
      existing at place where previously unmaintained plugins where
      brought alive), set up issue handling system with roadmaps etc.
      (like Mantis) and of course set up a core team of developers who
      make decisions what go in and what not. I believe this would also
      speed up the development of the vdr itself tremendeously due to
      much greater man power.<br>
      <br>
      Of course things can remain the same but will we ever see natively
      implemented in vdr:<br>
      -_proper_ implementation of server-client solution (centralized
      records, epg etc. without "hacks")<br>
      -good looking high res OSD<br>
      -good integration to XBMC or similar<br>
      -fully redefinable menu system<br>
      -channel specific configurability (epg...)<br>
      -native ATSC support<br>
      -several of the big patches integrated (long list) and
      configurable<br>
      -etc.etc.<br>
      <br>
      If I've not read incorrectly what have been written in this
      mailing-list then the answer is *no*.<br>
      <br>
      Hope to get some active discussion around this and actions as
      well.<br>
      <br>
      Br, Pasi<br>
      <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
vdr mailing list
<a class="moz-txt-link-abbreviated" href="mailto:vdr@linuxtv.org">vdr@linuxtv.org</a>
<a class="moz-txt-link-freetext" href="http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr">http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>