want to be a contributer

Hi there,

I am glad you are interested in contributing to Xibo - this is good news!

Before Xibo became an open source project I had written a HTML client for it
- which was also used in a preview mode. We then developed a .NET client for
Xibo so we could have more control in a "long-running" environment.

Alex is currently in the process of created a new client based on a cross
platform technology - maybe Java or libavg.

This is not to say we do not need a HTML viewer - or that people will not
want the "ease" of having a player pointed at the browser. One thing we
definately will be needing is a better preview function for the server
interface - which could be ideal for your project.

Would you mind sharing your code so far and some details of your plan?

Thanks again for contributing!!

Regards,
Dan

2009/3/20 kabil <email address hidden>

> New question #64736 on Xibo:
> https://answers.launchpad.net/xibo/+question/64736
>
> Hi,
>
> 4 days ago I started to develop a html viewer written in php. This viewer
> connects to xibo web servis and gets scheduling data and converts xml data
> to html (I manipulated web servis Schedule function). Now my viewer is
> integrated to xibo. Ofcourse there is lack of functionality.
>
> you can view it here
> http://ds.multipc.com.tr/dsmanager/service/s.php?f=page&serverKey=123456&hardwareKey=444D500500C5&name=izmir&version=1
>
> In html viewer one can see text, image, video, flash, rss likes media,
> developping currently some features. Also because the server is on php,
> rendering html is much simple but checduling is now harder. Bu one can use
> ajax for partial update, am I wrong?
>
> So I want to conribute on developin html viewer for xibo, what do you
> think?
>
> --
> You received this question notification because you are a member of Xibo
> Developers, which is an answer contact for Xibo.
>

Hi Kabil,

1. It is good to know you too are looking at html viewer. Few days ago I was talking to Dan about the same and I was supposed to send my PHP code to Dan which I didn't. I was traveling and I plan to send the code today or tomorrow.

2. I have not looked at the code of Xibo client yet but from what I see, Pla yer and Downloader seems to be tightly integrated. I would really like to see three independent components in the project.
Player component (.NET/Java or HTML Viewer)
Media Downloader/Uploader component - which will download/upload files and change the schedule timings and playlist accordingly.
Server

That is how we are structuring our inhouse DS project.

I still did not completely understand the drawbacks of HTML viewer vis-a-vis .NET or Java client.

I appreciate your thoughts as well as Dan's thoughts? Or should we create a new branch for HTML viewer development?

Thanks
Charan.

Hi Charan;

Firstly the idea came up with a need being lightweight so we created a html
viewer specific to our embedded system but it can be easily refactored to a
standard one.

What makes HTML Client different from the .Net Client or Java Client is it
does not download media to itself. Rather HTML client directly views
configured layout. In .Net or Java clients, firstly the required files are
downloaded to local thereafter layout is rendered.

Also HTML Client is currently less capable than .Net/Java client because it
depends on browser capabilities. But further development make it more
capable.

So in summary a lightweight HTML client will be developed as a need after
talking with Dan (at least I need). Nowadays I could not rework on html
client but in a few days I will be working on it.

Further details will be discussed later.

On Tue, Mar 24, 2009 at 1:49 PM, charan <<email address hidden>
> wrote:

> Your question #64736 on Xibo changed:
> https://answers.launchpad.net/xibo/+question/64736
>
> charan proposed the following answer:
> Hi Kabil,
>
> 1. It is good to know you too are looking at html viewer. Few days ago I
> was talking to Dan about the same and I was supposed to send my PHP code to
> Dan which I didn't. I was traveling and I plan to send the code today or
> tomorrow.
>
> 2. I have not looked at the code of Xibo client yet but from what I see,
> Pla yer and Downloader seems to be tightly integrated. I would really like
> to see three independent components in the project.
> Player component (.NET/Java or HTML Viewer)
> Media Downloader/Uploader component - which will download/upload files and
> change the schedule timings and playlist accordingly.
> Server
>
> That is how we are structuring our inhouse DS project.
>
> I still did not completely understand the drawbacks of HTML viewer
> vis-a-vis .NET or Java client.
>
> I appreciate your thoughts as well as Dan's thoughts? Or should we
> create a new branch for HTML viewer development?
>
> Thanks
> Charan.
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
> https://answers.launchpad.net/xibo/+question/64736/+confirm?answer_id=1
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https://answers.launchpad.net/xibo/+question/64736
>
> You received this question notification because you are a direct
> subscriber of the question.
>
>

Charan

The reason that, at present, the downloader and scheduler are so tightly integrated in to each other is that all these elements really need to communicate and work together. I suppose you could achieve that across multiple applications using RMI, CORBA or something, but I don't really see the need for that extra complexity.

The main issue as I see it with a pure HTML viewer is you will find it increasingly difficult to match the abilities of the "official" player, especially when we start to integrate 3D, alpha blending, video input from capture cards or firewire devices etc in 1.1/1.2.

I think there is a need for a quick preview - which Xibo doesn't currently support well - and it may be that the HTML viewer is ideal for that purpose.

The project has, in the past, had HTA based browser applications (encapsulated Internet Explorer) and they work fine in the short term, but ultimately leak memory over a period of a few weeks and need to be restarted etc. They also had a much higher bandwidth overhead since all media was streamed each time from the server - although a local downloader app would solve this problem.

Cheers

Alex

HI Alex,

I agree with you that browser based player may not be as capable of 'official player', but I do believe browser is increasingly becoming more powerful to support many formats and the code is also easily maintainable.
We did come across memory leaks and yes we had a small script that used to shut down the pc when there is no schedule and wakeup when the schedule starts.
We had a seperate downloader app and we avoided using streaming as there is a chance of connectivity break down as well.

Regarding component seperation what I meant is as follows:

1. Player component typical tasks - Read scheduler and playlist and play files till the end of schedule.
The key configuration files for Player components are: Scheduler file, Playlist file, layout file and data is media files.

2. Downloader App - Download Schedule changes and update scheduler file, layoutfile, playlist file and also download associated media files and any other configuration files as relevant (for eg frequency of download). As long as Downloader app provides the required information to the player app...the seperation can be achieved.

This would also allow multiple teams to work and improve individual apps...just my thoughts...

Look forward to hear about libavg version planned dates.

Hi Charan

If you can handle the separation elegantly, then that would be great. It was one of my goals when I set out to write the Java client - indeed it was something Dan and I very much wanted, but was quickly abandoned because of the complexity of the problem.

Timescales for libavg are a moveable feast.

You'll have seen on the website the post about how we propose to move Xibo development forwards. Basically 1.0 is now feature frozen - ie there will be no significant new features in 1.0.x - Development focus will now move to 1.1.x series which will be a development series to tackle the blueprints we have targeted for it. Once 1.1 is stable, we'll move to 1.2 series which will be a stable release series, and the direct upgrade from 1.0.x

We will of course still bug fix 1.0.x and release as required.

There are alot of new things proposed for 1.1/1.2 so I think we're realistically looking at a 1.2 series towards the end of the year - but that's just a guess!

Cheers

A;ex

Hi Alex...

Regarding decoupling, we will need to ask ourselves few questions?

1. What is the scope of this digital signage project and what kind of locations is digital signage targeted?

   For example: If we say that this project is meant to replace Tube station Tv'S OR Airport terminals there
   are already applications which cater to this.

   I believe the initial scope of this project should be based on providing a solution for the existing set
   of digital signage which are typically not so real time based. For example, stores etc.

2. Why is it going to make a difference?

   If the digital signage network (which typically is a planned network) and can live with a certain broadcast
   delay the decoupling can be achieved.

   For example: A store in the morning at 9 AM decides that it wants to run a sales promotion for the day.
   An ideal application may need to broadcast that particular message immediately. But if we say a delay
   of 30 mins is typically ok, that will allow the downloader app to do its function.

Let us look at from server point of view:

Time schedules:

A scheduler will tell the client start time and end time of the client.

(Any changes to the schedule can be easily downloaded to the client and I believe a delay by few minutes
should not be a problem)

Content Management

Content management can be achieved either via a playlist or can be open ended.

1. Playlist based:

All changes to the content are done via a playlist.

Possible playlist functions:

1. Expand a playlist i.e a playlist loop duration is changed from 5 mins to say 6mins
2. Reduce a playlist i.e a playlist loop duration is changed from 5 mins to say 4:30 mins
3. Change a playlist i.e some or all of the files in playlist have been modified.

If what client has to play is open-ended, i.e each time the client will have to contact the server to
determine the next file to be played, would require to call downloader function from the downloader app.

PS: When is 1.1 scheduled?

Hi Charan

I drew out a class interaction diagram last night for the libavg player. Dan and I are going to go over it on Saturday, and then I'll pop a link in this thread.

You'll see the interaction is quite tightly coupled.

As to target market, I don't see the point of designing in a 30 minute delay when it's so trivial not to have that limitation. I see Xibo in places where commercial DS is too expensive (at least to begin with) - eg schools, colleges, universities, small shops, churches, leisure centres etc. That doesn't mean that we wouldn't ultimately end up with screens in airports, big companies etc

Ideally I'd like to see Xibo running on a push architecture where clients are pushed schedule updates and new content as the changes happen on the server - but there's alot of work there to do with firewall traversal.

We're aiming to have 1.0.0 released this weekend coming.

At that point, we'll branch for 1.1.x series. 1.0.x series will be feature frozen and we will only release in that series for bug fixes. 1.1 will then become an unstable development series where we can get new features incorporated and tested, before releasing 1.2.x which will be the next stable series of releases.

1.2 will be released when it's ready. :D

Cheers

Alex

Hi again Alex and Dan;

I want to contribute on xibo-server side, If you mind . If you please me to
conribute, I will be working on night time.

What do you think?

On Wed, Mar 25, 2009 at 12:53 PM, Alex Harrington <
<email address hidden>> wrote:

> Your question #64736 on Xibo changed:
> https://answers.launchpad.net/xibo/+question/64736
>
> Alex Harrington proposed the following answer:
> Hi Charan
>
> I drew out a class interaction diagram last night for the libavg player.
> Dan and I are going to go over it on Saturday, and then I'll pop a link
> in this thread.
>
> You'll see the interaction is quite tightly coupled.
>
> As to target market, I don't see the point of designing in a 30 minute
> delay when it's so trivial not to have that limitation. I see Xibo in
> places where commercial DS is too expensive (at least to begin with) -
> eg schools, colleges, universities, small shops, churches, leisure
> centres etc. That doesn't mean that we wouldn't ultimately end up with
> screens in airports, big companies etc
>
> Ideally I'd like to see Xibo running on a push architecture where
> clients are pushed schedule updates and new content as the changes
> happen on the server - but there's alot of work there to do with
> firewall traversal.
>
> We're aiming to have 1.0.0 released this weekend coming.
>
> At that point, we'll branch for 1.1.x series. 1.0.x series will be
> feature frozen and we will only release in that series for bug fixes.
> 1.1 will then become an unstable development series where we can get new
> features incorporated and tested, before releasing 1.2.x which will be
> the next stable series of releases.
>
> 1.2 will be released when it's ready. :D
>
> Cheers
>
> Alex
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
> https://answers.launchpad.net/xibo/+question/64736/+confirm?answer_id=7
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https://answers.launchpad.net/xibo/+question/64736
>
> You received this question notification because you are a direct
> subscriber of the question.
>
>

Also how can be access to development branch?

On Wed, Mar 25, 2009 at 12:53 PM, Alex Harrington <
<email address hidden>> wrote:

> Your question #64736 on Xibo changed:
> https://answers.launchpad.net/xibo/+question/64736
>
> Alex Harrington proposed the following answer:
> Hi Charan
>
> I drew out a class interaction diagram last night for the libavg player.
> Dan and I are going to go over it on Saturday, and then I'll pop a link
> in this thread.
>
> You'll see the interaction is quite tightly coupled.
>
> As to target market, I don't see the point of designing in a 30 minute
> delay when it's so trivial not to have that limitation. I see Xibo in
> places where commercial DS is too expensive (at least to begin with) -
> eg schools, colleges, universities, small shops, churches, leisure
> centres etc. That doesn't mean that we wouldn't ultimately end up with
> screens in airports, big companies etc
>
> Ideally I'd like to see Xibo running on a push architecture where
> clients are pushed schedule updates and new content as the changes
> happen on the server - but there's alot of work there to do with
> firewall traversal.
>
> We're aiming to have 1.0.0 released this weekend coming.
>
> At that point, we'll branch for 1.1.x series. 1.0.x series will be
> feature frozen and we will only release in that series for bug fixes.
> 1.1 will then become an unstable development series where we can get new
> features incorporated and tested, before releasing 1.2.x which will be
> the next stable series of releases.
>
> 1.2 will be released when it's ready. :D
>
> Cheers
>
> Alex
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
> https://answers.launchpad.net/xibo/+question/64736/+confirm?answer_id=7
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https://answers.launchpad.net/xibo/+question/64736
>
> You received this question notification because you are a direct
> subscriber of the question.
>
>

Kabil et al,

We are in the process of finalising an article detailing how to best contribute on the Xibo project. This article will detail exactly how you should fix bugs / develop features. It will also give details on code branching, etc.

Sorry for the delay with this document - we will create an announcement on the website when this is done - hopefully it will be this weekend!

Cheers,
Dan

Please refer to this page: http://xibo.org.uk/2009/03/28/guidelines-for-contributing/

Thanks,
Dan