Thanks all for your replys! At least I feel heard by the community.
 
Yes, you are right - I can not address my thoughts without emotions. So we
get into ITIL terminology. I will not do it 100% correct, as we need the
application of ITIL to the current problem.
 
Okay, here it comes. Some call it "features", some would call it "services".
The VDR "suite" is providing vertical and horizontal services. Vertical
Services are most of the time "end user services", whereas horizontal
services are "platform services". To get into detail:
Vertial:
* Show a live DVB stream
* Record a DVB stream
* Time-Shift-View
* Show a recording
* .. you name it, we have it .. there's a lot more!
 
-> When we would build up a service catalogue, we would also have to make
SLA's on it. This would be the case, when a service provider (that's
actually me!) is providing serivces to customers (my beloved!). And here
comes the story: everybody wants to have 100% availability, that's clear. I
do regular service updates with my VDR, where all services are down. This I
can schedule so, that there is no interference with my end customers. Okay,
all services are seen as single instances. End-Users do not understand, why
recording a DVB stream is linked to showing a recording! -> Please Klaus,
explain - in words that my Granny will understand!
 
Second: There is something that's called "höhere gewalt". Examples: I want
to watch TV, but there is a power outage. Nobody would blame me -
personally. When I want to go across the alps with my car and it snowed 2
meters over night, nobody would blame me, that i was not able to go across.
When I want to get tanned by sun and it's raining, it's simply impossible.
When there is a huge cloud over my sat dish, even my 85cm is too small. I
can not influence the weather. Everboy will understand!
 
 
Horizontal:
* The socalled API
   It's a platform, that is not visible to the endcustomer, but totally
necessary as a good software is always open for new vertical services! The
hassle with this is, that end-users do not care about the API. Modules must
simply link in. Klaus had a long nightmare behind about this. So API is
necessary, but also a lot of work with almost no refund.
 
Something out scope for ITIL - Patching:
And then we have the BigPatch fraction. I love those guys, they do also
great job. They are not building on an API, they are modifying the source.
Why are they doing this - should some of you ask yourself? Answer for me is
simple: I did also do a feature request, something that was already
developed, Klaus only needed to include in his source. But people started
discussing, that we don't need. -> If we don't need, why is there a
BigPatch. So no new feature (again a vertical service), which is
frustrating. 

-> ".. inaction is a weapon of mass destruction." If you like musik, check
your mp3 library for:
http://www.lyricstop.com/m/massdestruction-faithless.html
 
So: what would be the next steps: it's clear, VDR is not able (willing or
what ever, again I don't care) to split up the services, so i must find
workarrounds. Make many instances of VDR running on my machine. One is doing
recording, one EPG search, the other is providing "Show" Sevice. -> do I
really have to do this? And how to do it? Next would be that i have to split
up physically into seperate boxes .. *puh*
 
Finally - Business Economics:
Talking about the "Cost of Service" and the "Total Cost of Ownership". When
I split up VDR instances, the costs increase and over the lifetime the costs
get multipied. Do I take Windows or Linux -> it's just a cost fact: Linux
costs me, in my environment less. Do I buy a DVB-Recorder or do I build up
(custom made). Also simple: I need to compare the service catalogue. All
commercial services do not offer me "noad", "vdradmin", "epgsearch",
"femon". This is the reason for me to use VDR. So: I use a lot of the API, I
use BigPatch to get the 10 seconds jumps. This is what make VDR unique and
worth using it. But writing such a long mail is frustrating :(
 

Martin
Thanks all for your replys! At least I feel heard by the community.
 
Yes, you are right - I can not address my thoughts without emotions. So we
get into ITIL terminology. I will not do it 100% correct, as we need the
application of ITIL to the current problem.
 
Okay, here it comes. Some call it "features", some would call it "services".
The VDR "suite" is providing vertical and horizontal services. Vertical
Services are most of the time "end user services", whereas horizontal
services are "platform services". To get into detail:
Vertial:
* Show a live DVB stream
* Record a DVB stream
* Time-Shift-View
* Show a recording
* .. you name it, we have it .. there's a lot more!
 
-> When we would build up a service catalogue, we would also have to make
SLA's on it. This would be the case, when a service provider (that's
actually me!) is providing serivces to customers (my beloved!). And here
comes the story: everybody wants to have 100% availability, that's clear. I
do regular service updates with my VDR, where all services are down. This I
can schedule so, that there is no interference with my end customers. Okay,
all services are seen as single instances. End-Users do not understand, why
recording a DVB stream is linked to showing a recording! -> Please Klaus,
explain - in words that my Granny will understand!
 
Second: There is something that's called "höhere gewalt". Examples: I want
to watch TV, but there is a power outage. Nobody would blame me -
personally. When I want to go across the alps with my car and it snowed 2
meters over night, nobody would blame me, that i was not able to go across.
When I want to get tanned by sun and it's raining, it's simply impossible.
When there is a huge cloud over my sat dish, even my 85cm is too small. I
can not influence the weather. Everboy will understand!
 
 
Horizontal:
* The socalled API
   It's a platform, that is not visible to the endcustomer, but totally
necessary as a good software is always open for new vertical services! The
hassle with this is, that end-users do not care about the API. Modules must
simply link in. Klaus had a long nightmare behind about this. So API is
necessary, but also a lot of work with almost no refund.
 
Something out scope for ITIL - Patching:
And then we have the BigPatch fraction. I love those guys, they do also
great job. They are not building on an API, they are modifying the source.
Why are they doing this - should some of you ask yourself? Answer for me is
simple: I did also do a feature request, something that was already
developed, Klaus only needed to include in his source. But people started
discussing, that we don't need. -> If we don't need, why is there a
BigPatch. So no new feature (again a vertical service), which is
frustrating. 

-> ".. inaction is a weapon of mass destruction." If you like musik, check
your mp3 library for:
http://www.lyricstop.com/m/massdestruction-faithless.html
 
So: what would be the next steps: it's clear, VDR is not able (willing or
what ever, again I don't care) to split up the services, so i must find
workarrounds. Make many instances of VDR running on my machine. One is doing
recording, one EPG search, the other is providing "Show" Sevice. -> do I
really have to do this? And how to do it? Next would be that i have to split
up physically into seperate boxes .. *puh*
 
Finally - Business Economics:
Talking about the "Cost of Service" and the "Total Cost of Ownership". When
I split up VDR instances, the costs increase and over the lifetime the costs
get multipied. Do I take Windows or Linux -> it's just a cost fact: Linux
costs me, in my environment less. Do I buy a DVB-Recorder or do I build up
(custom made). Also simple: I need to compare the service catalogue. All
commercial services do not offer me "noad", "vdradmin", "epgsearch",
"femon". This is the reason for me to use VDR. So: I use a lot of the API, I
use BigPatch to get the 10 seconds jumps. This is what make VDR unique and
worth using it. But writing such a long mail is frustrating :(
 

Martin
Thanks all for your replys! At least I feel heard by the community.
 
Yes, you are right - I can not address my thoughts without emotions. So we
get into ITIL terminology. I will not do it 100% correct, as we need the
application of ITIL to the current problem.
 
Okay, here it comes. Some call it "features", some would call it "services".
The VDR "suite" is providing vertical and horizontal services. Vertical
Services are most of the time "end user services", whereas horizontal
services are "platform services". To get into detail:
Vertial:
* Show a live DVB stream
* Record a DVB stream
* Time-Shift-View
* Show a recording
* .. you name it, we have it .. there's a lot more!
 
-> When we would build up a service catalogue, we would also have to make
SLA's on it. This would be the case, when a service provider (that's
actually me!) is providing serivces to customers (my beloved!). And here
comes the story: everybody wants to have 100% availability, that's clear. I
do regular service updates with my VDR, where all services are down. This I
can schedule so, that there is no interference with my end customers. Okay,
all services are seen as single instances. End-Users do not understand, why
recording a DVB stream is linked to showing a recording! -> Please Klaus,
explain - in words that my Granny will understand!
 
Second: There is something that's called "höhere gewalt". Examples: I want
to watch TV, but there is a power outage. Nobody would blame me -
personally. When I want to go across the alps with my car and it snowed 2
meters over night, nobody would blame me, that i was not able to go across.
When I want to get tanned by sun and it's raining, it's simply impossible.
When there is a huge cloud over my sat dish, even my 85cm is too small. I
can not influence the weather. Everboy will understand!
 
 
Horizontal:
* The socalled API
   It's a platform, that is not visible to the endcustomer, but totally
necessary as a good software is always open for new vertical services! The
hassle with this is, that end-users do not care about the API. Modules must
simply link in. Klaus had a long nightmare behind about this. So API is
necessary, but also a lot of work with almost no refund.
 
Something out scope for ITIL - Patching:
And then we have the BigPatch fraction. I love those guys, they do also
great job. They are not building on an API, they are modifying the source.
Why are they doing this - should some of you ask yourself? Answer for me is
simple: I did also do a feature request, something that was already
developed, Klaus only needed to include in his source. But people started
discussing, that we don't need. -> If we don't need, why is there a
BigPatch. So no new feature (again a vertical service), which is
frustrating. 

-> ".. inaction is a weapon of mass destruction." If you like musik, check
your mp3 library for:
http://www.lyricstop.com/m/massdestruction-faithless.html
 
So: what would be the next steps: it's clear, VDR is not able (willing or
what ever, again I don't care) to split up the services, so i must find
workarrounds. Make many instances of VDR running on my machine. One is doing
recording, one EPG search, the other is providing "Show" Sevice. -> do I
really have to do this? And how to do it? Next would be that i have to split
up physically into seperate boxes .. *puh*
 
Finally - Business Economics:
Talking about the "Cost of Service" and the "Total Cost of Ownership". When
I split up VDR instances, the costs increase and over the lifetime the costs
get multipied. Do I take Windows or Linux -> it's just a cost fact: Linux
costs me, in my environment less. Do I buy a DVB-Recorder or do I build up
(custom made). Also simple: I need to compare the service catalogue. All
commercial services do not offer me "noad", "vdradmin", "epgsearch",
"femon". This is the reason for me to use VDR. So: I use a lot of the API, I
use BigPatch to get the 10 seconds jumps. This is what make VDR unique and
worth using it. But writing such a long mail is frustrating :(
 

Martin
Thanks all for your replies! At least I feel heard by the community.
 
Yes, you are right - I cannot address my thoughts without emotions. So we
get into ITIL terminology. I will not do it 100% correct, as we need the
application of ITIL to the current problem.
 
Okay, here it comes. Some call it "features", some would call it "services".
The VDR "suite" is providing vertical and horizontal services. Vertical
Services are most of the time "end user services", whereas horizontal
services are "platform services". To get into detail:
Vertical:
* Show a live DVB stream
* Record a DVB stream
* Time-Shift-View
* Show a recording
* .. you name it, we have it .. there's a lot more!
 
-> When we would build up a service catalogue, we would also have to make
SLA's on it. This would be the case, when a service provider (that's
actually me!) is providing services to customers (my beloved!). And here
comes the story: everybody wants to have 100% availability, that's clear. I
do regular service updates with my VDR, where all services are down. This I
can schedule so, that there is no interference with my end customers. Okay,
all services are seen as single instances. End-Users do not understand, why
recording a DVB stream is linked to showing a recording! -> Please Klaus,
explain - in words that my Granny will understand!
 
Second: There is something that's called "höhere Gewalt". Examples: I want
to watch TV, but there is a power outage. Nobody would blame me -
personally. When I want to go across the alps with my car and it snowed 2
meters over night, nobody would blame me, that i was not able to go across.
When I want to get tanned by sun and it's raining, it's simply impossible.
When there is a huge cloud over my sat dish, even my 85cm is too small. I
cannot influence the weather. Everybody will understand!
 
 
Horizontal:
* The so-called API
   It's a platform, that is not visible to the end customer, but totally
necessary as good software is always open for new vertical services! The
hassle with this is, that end-users do not care about the API. Modules must
simply link in. Klaus had a long nightmare behind about this. So API is
necessary, but also a lot of work with almost no refund.
 
Something out scope for ITIL - Patching:
And then we have the BigPatch fraction. I love those guys, they do also
great job. They are not building on an API, they are modifying the source.
Why are they doing this - should some of you ask yourself? Answer for me is
simple: I did also do a feature request, something that was already
developed, Klaus only needed to include in his source. But people started
discussing, that we don't need. -> If we don't need, why is there a
BigPatch. So no new feature (again a vertical service), which is
frustrating. 

-> ".. inaction is a weapon of mass destruction." If you like music, check
your mp3 library for:
http://www.lyricstop.com/m/massdestruction-faithless.html
 
So: what would be the next steps: it's clear, VDR is not able (willing or
what ever, again I don't care) to split up the services, so i must find
workarounds. Make many instances of VDR running on my machine. One is doing
recording, one EPG search, the other is providing "Show" Service. -> do I
really have to do this? And how to do it? Next would be that i have to split
up physically into separate boxes .. *puh*
 
Finally - Business Economics:
Talking about the "Cost of Service" and the "Total Cost of Ownership". When
I split up VDR instances, the costs increase and over the lifetime the costs
get multiplied. Do I take Windows or Linux -> it's just a cost fact: Linux
costs me, in my environment less. Do I buy a DVB-Recorder or do I build up
(custom made). Also simple: I need to compare the service catalogue. All
commercial services do not offer me "noad", "vdradmin", "epgsearch",
"femon". This is the reason for me to use VDR. So: I use a lot of the API, I
use BigPatch to get the 10 seconds jumps. This is what make VDR unique and
worth using it. But writing such a long mail is frustrating :(
 

Martin


_______________________________________________
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Reply via email to