Skip to main content

Posts

Showing posts from 2013

Point of view on TV Application Layer

With the internet everywhere, content aggregators, broadcasters, and content producers are compelled to find new delivery channels. SMART TV happens to be the next trend riding the wave. Ofcourse, we need to see how SMART TV concept catches up in India as there is cost barrier.  SMART TVs are finding their ways in west, however, it remains to be seen whether they can double up as an effective delivery medium. In my view, the major concern is that, the user still has to switch to TV application from main screen to access. As a viewer, I don't find it convenient to navigate, every time I need to access TV app, rather I user my tablet to access app. I wished, TV applications being displayed alongside main screen, more as a companion one and had access to the context of the content being broadcast. This is the tricky place to be in and I am not sure, it is going to be reality because of content protection policies. However, one thing is for sure, the broadcasters are sitting on

Object orientation and Service orientation

Object orientation is all about modeling the real world information mainly through encapsulation, abstraction, polymorphism, containment, inheritance and so on. In simple words, an object contains the data structures and methods to change the content state. A typical OO run-time manages the life cycle of objects. You can create as many objects as required as long as the run-time does not over run its memory. Service orientation requires you to encapsulate a process. The operations of a services are interaction points with the particular process. Data structures are the arguments for these operations. Service run-time shall validate the correctness of the process. Service can have multiple invocation instances, not multiple instances of service itself. Example: TrainTicketBookingService involves a process. - Check the train timings //  interaction point - Check the seat availability // interaction point - Issue ticket // interaction point There could be many ticket cou

Service oriented architecture - 1

SOA, Yes, it expands to Service oriented architecture. What is it? Keep these things in mind during design and analysis. 1. Whenever you design a service, you are designing a service for a business task. 2. These services can be linked to achieve bigger business goals. Let us understand 'Service': In my view, a service is an expectation fulfillment for a service consumer, without service consumer actually worrying about how is it fulfilled. For example: A student opts of 'Data structures' lesson. The delivery of a lesson is a service for the student. The professor does his homework, examples and makes sure that student understands the lesson. Student and the professor are the different entities, yet there is a well defined service contract between them which enabled two entities exchange the expectation without student actually worrying about the service implementation aspects of the professor. So, to be called a service, it should be meaningful. It

Dangling references

I picked up my data structures book and started reading it. First thing that came to my mind is, If I were a teacher, how would I explain to students on pointer concepts. Believe me, it is still a challenging concept to comprehend. Pointer is a like a phone number to reach a person. Pointer points to address of the object that holds the data. Now, what is dangling reference. It is possible that there can be many pointer variables pointing to same address. For example, You, myself, someone else can have the same phone number of the person to reach. Question: What if the person dies? :) I still will have phone number, but cannot reach him or her. On top of that, what if that phone number gets assigned to some other person. In that case, I will reach the wrong person. The phone number I have is a dangling reference. Pointer pointing to the address, but address does not hold the desired object anymore ... Simple, isnt it?

TV Application layer from BBC

BBC has open sourced its TV Application layer to enable TV application developers to create browser based TV apps. TAL is an abstraction layer that contains generally used widgets and Javascript that aid the developer to focus on providing consumption logic across many connected TVs. TAL comprises of various TV device configurations and settings that would free the developer from worrying about the specific settings that a particular TV brand demands.  TAL requires community support to extend its capability and have more widgets. BBC's sports app, news app and even I believe, iPlayer uses TAL. While BBC was implementing iPlayer in its antie framework, they hit upon the idea of abstracting the application layer and coined TAL. To encourage open source participation, they have recently open sourced it. In my view, there is a good potential for TV apps and TAL provides a platform for writing common consumption layer that can wrapped by native TV SDKs without tampering logic with n

Key to adopt open source product

Friends, I am working on business solution implementation on open source product called Kaltura. Kaltura is a media management solution and has loads of features that compel any business to take a peek into it. More-over this is the only complete end-to-end open source software available to handle digital assets. But it comes with its own head ache. Considering its open source, its understandable. I feel, handling these would ensure you the success in your open source product implementation. 1. In my opinion, before adopting any open source software, build the capability to deal with the inconsistency bundled in the open source software. 2. I would avoid involving external consultants for 2 reasons.      a. I am not sure, they would bring necessary expertise on to table      b. I fear that there would be little ownership, they will not see big picture of my business (neither I am interested to share it all) 3. Alternative to that is to build the team that is capable of debuggin