Rob Shortt wrote: >> Well, it may be ok for you, but I don't want a public 2.0 release out >> there with a huge security risk. You know what you are doing by >> choosing this kind of communication, others don't. > > OK, I can respect that. I still need a networked EPG that performs > well. I also forgot to mention the need to support diskless clients - > no disk to store local db.
Define diskless. I have a very dump box here, unable to start anything
except mpeg2. For that kind of box I want to have remote access in the
future. I powerfull pc somewhere that streams the display to that box
and does on-the-fly encoding of the videos.
But I guess you want to boot from the network and run freevo localy,
video comes from network filesystems. Well, this can be a problem. I'm
rewriting kaa.vfs (in freevo it is a mix of vfs and mediadb). It is
similar to kaa.epg but the clients also access the db read only. It's
a choice of speed. Yes, kaa.ipc is fast, but it is faster if we do the
reading part in the client itself. That means, kaa.vfs needs a local
database right now. I'm not sure this is a problem. Yes, sqlite is not
designed to work on network filesystems because you can't do atomic
operations, but if all clients are from the same machine, it should
work. Maybe for a diskless client we need some sync support. Give
Freevo a dir to save in RAM and sync it to the server. On boot, copy
the data back.
>>>>1. Use kaa.epg has interface and do not care that it is a different
>>>> process. This is done by kaa.vfs and kaa.vfs will start a server if
>>>> needed and stop it when you are done. Communication is kaa.ipc, but
>>>> you don't see it.
>>>>
>>>>2. Define that we have an epg server. Communication is mbus and you
>>>> have to start the server on your own.
>>>
>>>I would prefer something more like 2, but I don't think mbus is suitable
>>>for EPG data is it?
>>
>>
>> Yes and no. Right now mbus has the limitation that the message has to
>> fit into one UDP packet. That may not work when you try to get the epg
>> for the whole day on all channels.
>
> Sometime I can do some more tests with the EPG and mbus. With epg1
> architecture it seemed to take too many resources disassembling objects
> into mbus messages, then reassembling on the client. Maybe this will be
> better in epg2 since it may be hooked into the GuideClient _load()
> easily. DB rows are a lot like mbus messages.
Yes, mbus is slower than kaa.ipc. Kaa.ipc just takes the data and
pickles it while mbus transforms it into strings being independed of
the programming language. So that costs some more time. For kaa.vfs it
may be too much time, but for kaa.epg we have to see.
1. The tvserver has the epg internal, so no need to use mbus at this
point.
2. The webserver also is no problem, an overhead of 200ms won't be a
problem.
3. The freevo ui. The current code does the epg lookup when needed,
e.g. you go to the left and it fetches the data. An overhead of
200ms will be bad. But I don't like the current tv guide, it is
very hard to navigate. Maybe a different kind of tv kind solves
that problem and mbus is ok for us.
I would like to have one epg server part in the system. And IMHO it
should be part of tvserver. The tvserver without epg makes no sense
and why do you need an epg if you don't have a tvserver. So I think we
should merge them.
>>>I have added a ping() to the guide client, and now when
>>>connect()/guide() is called it checks for an already instantiated client
>>>and calls ping() making sure it's there. If not, just start a new one,
>>>log errors. I know not all users check logs but I think it is important
>>>for things to keep running.
>>
>>
>> Maybe stuff like that should be part of kaa.ipc in general. But IIRC
>> there is a callback somewhere for lost connections.
>
> This callback exists on the server side, I'm not sure about the client
> side. There is a ping() in kaa.ipc, and that is what I hooked up to
> GuideClient. On the disconnected exception it (kaa.ipc) returns False.
See mail from Tack.
>>>IDEA: We can create a Freevo messaging service that can send messages
>>>and alerts to UIs like the TV and webserver. Something could look for
>>>errors and notify you.
>>
>>
>> Like mbus messages? Sure there could be a display or message event on
>> mbus.
>
> Yes. I guess what I meant was a process that watches for error then
> sends a message / event over mbus. We could even do this from the
> logging module.
The logging module .... yes, we could send all log.error over the
mbus. But I don't think it will be clear to the user what the problem
is. I would prefer an extra mbus.logging module and the ui can
register to the log message to display and the webserver can register
to it to show the error messages from the last day.
Dischi
--
C makes it easy for you to shoot yourself in the foot. C++ makes that
harder, but when you do, it blows away your whole leg.
-- Bjarne Stroustrup
pgpDiAoEq8OxN.pgp
Description: PGP signature
