Extended Event model

Hi,

 This is very rough but having looked at various blueprint proposals I started to think out-of-the-box slightly. I have no doubts you've all got a gameplan already sorted but I noticed a lot of dev work was being done on specific requests and I wondered if some pipe dream ideas would be good to think about :-)

 A number of Blueprints request a specific feature or support for XYZ. Many of those facilities could be designed but eventually it'll build up a massive list of things to support. A design to implement plug-ins works well to alleviate this but I wondered if it might be cool to think even more abstract than that.and use some design pattern ideas. (Yep, you can kill me later for mentioning patterns!)

  I've had experiences on a number of occaisions programming devices that were based on real time event programming. I've always found them to be really bespoke and wierd. Many of them have been to easy work out, once you work out their direction, but it's always a bit awkward to work out how to think about them. The one thing I've noticed though, is that many real-time systems rely much more heavily on interaction between items than they do on the items themselves.

 This is a pipe dream of course but I'm hoping that it's a pipe dream you all already have:-)

 Imagine that, rather than have a single transition or plugin for a particular content item, you extended the idea of objects being filled and handled abstractly by "actions" and "reactions".

 A transition, for instance, might be better thought of as a decorator pattern on an object and the content could be given a list of decorations to apply as it arrives, resides or leaves the screen. Say, you want an RSS feed to "dissolve" in, scroll it's contents and then "fade" out. It would be logical to pitch those as enter, resident and exit functions that apply dissolve, scroll and fade effects to a "virtual" region.

 Perhaps this could be extended to a visitor pattern so that an object can be altered as well. That would lead to regions that can float around or zoom their content just by changing their own co-ordinates according to a modular function.

 I think stuff like that could actually be a great way to think about many aspects of Xibo. It might make things a lot easier to plan and lead on to some natural ways to plan plugin architecture's and the xcmd definitions needed to describe it all.

 In my mind, looking at blueprints like the proposal for RS-232 support (which I'd be very interested in!) hammers home that it would be easier to think of plug-ins working to a well defined command structure and avoidng a bespoke function. I feel that an RS-232 function would just natural evolve out of this idea in a better way.

 I'm conscious I've probably just jumped the gun here. All this is probably already lodged firmly in your plans for future version of xibo. I just wanted to say it incase it helped. Please don't flame me too hard :-}

 Have fun,

 Keith

 AH:
Keith. There's some good ideas in there. The problem with huge fundamental changes like this are that we simply don't have the developer time to do it. We could stall the project for 3 or 4 years doing a fundamental rework.

The plugin system for things like interactive lift, RS232, transitions etc I've designed to be as flexible as possible whilst still protecting the core client code as best I can from poorly behaving plugins. The intension long term is that plugins could be delivered to the clients via XMDS so it's quite possible malicious plugins could be delivered.

We're kind of already doing some of it too. The XLF describes the media item, its entry and exit transitions and any animation that should run on it while it's on the screen. Ditto for a region.

Keith: Thanks again Alex! When I say the words "Thanks for entertaining me", I do mean it in the nicest sense. I truly appreciate that this is all borne from hard work and scrapeing time to deliver something really positive for people to use whilst balancing work and actually having a chance to have a real life!

. I truly understand commitment time at the moment. If it's any consolation (and a fair comment to make about about understanding time commitments and pressure) I became a dad for the second time 4 weeks ago. I have a new definition of how little space I have to spend doing stuff that inpires me personally (as Xibo's concept does!). Geez, if you know of a good supplier of matchstick's please let me know!

 I understand what I was talking about was a big revamp. I feel very guilty! I guess it was just one of those moments when you look back with 20:20 hindvision over your own experiences and cherry pick the best and it all fits together in a plan that an ideal world would allow you to deliver :-}

 Xibo is a brilliant concept and I really should be slapping you guys on the back with a hearty congratulatory message. I'm sorry I jumped the gun wth all the pipe dream :-(

 I'll do my best to have a look at XLF/XCMDS. What I've seen so far really sells your understanding of what I pitched and how you've taken it one step further! Eeek, double helpings of humble pie today!

 I've got some experience in C# but I'm conscious that ideally you want a cross-platform client. Python isn't something I've approached yet so I'm a bit useless at the moment. (If you'd picked c# with mono then I'd probably be a bit more useful!)

 I'm due to go and feed junior so I'll cut this short! I'll be back to annoy you later :-)

AH:
Congrats on the Dad thing :D

We did look at porting the C# client to Mono, but the python client uses libavg which you can think of as similar to WPF. And mono just isn't there for that kind of work yet. libavg basically uses OpenGL to render content to the screen in 3D, which gives us loads of scope for doing very clever things like output image warping, transition effects, wrapping content around 3D objects - the list goes on and on.

Python itself is easy once you get used to the whitespace delimiting - I come from a PHP/Java background so it took me a while! The future of the C# client isn't set in stone. Dan works on it when he has time, but he is desperatly needed to work on the server side of things so it tends to get neglected. It also needs a big overhaul as at the moment it's a Windows forms app and is single threaded - and we're at the point now where it's beginning to get like a house of cards when it comes to making changes.