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@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
