Extended Xibo media data services?

Why not help us improve the web interface?

I think broadly that blueprint is more about mulitiple file uploads, display management etc not scheduling and design.

Alex

This email carries a disclaimer, a copy of which may be read at http://learning.longhill.org.uk/disclaimer

I agree with Alex. The web interface is (in my view) well thought out, and has all functionality needed. I certainly want to see Xibo develop, and push forward, but I don't want to see this rate of development slower than it could be due to multiple methods to achieve the same thing.

The power of the web interface is being able to administer from anywhere! I think the purpose of an upload application is slightly different as uploading multiple files could benefit from format conversion before upload, resolution modification, transcoding etc, and large files need to be handled in a slightly different way than would be possible / easy from within a web browser.

I am currently looking at developing an upload tool written in Python. More information will be on the Xibo wiki as it becomes available.

Matt

Let's discuss it, why not, as long as it's only 100% theoretical subject :)

Every user have different needs, You need everywhere access, we for example thinking about offline desinging capabilites.

There are pros and cons of web access conception, in long term view there is much more problems for us in developing web in compare to separate app.

For example we exactly need what we need to work more efficient, it's probably quite different that Your particulatr needs.

I don't know where you see some slowdown there? Maybe the time needed to export required function to xmds, later web development should be almost unrelated to out conceptional app.

I really think that a gui with some used drag drop library for c# / similar could be much more functional that web iface. For example i can't agree that google docs is easier than locally installed ms word, ever as old as word 97.
But ofcorse there is no multiuser everywhere access. Something lost, something works better.

Right now in present interface every little thing must be coded or there is a usability problem - for example long time bar with 70-100 pces on every layout, when adding single element, scrollbar is again on beginning.
You can say it's not very important but think what is happening when our designer need to create 30 layouts with 70 elements :)
Yes, i know, it could be fixed, but there is a lot of such little details that require coder atention all the time, i can only guess that when using some timebar control in gui oriented IDE (almost) don't need such atention.
And what if we're thinking of having everything related to layout desing on screen on one time, for example on left side layout preview and some dir stucture with materials, on center a lot of timebars related to particular regions, on right parameters to selected block etc.
It's totally different vision that current webiface, and probably you won't like it becouse your needs are different. Other thing is it possible to organize it in some web abstaction lib? probably much harder han organizing elements in some Visual* language, wxwindows, etc.

Last thing- we like to make changes more often than one time / 3 months without loosing stability. In separated model, when server is stable and unmodified without need (reorganizing buttons on gui or changing some windows dimension don't force us to change every single thing in server)- desing client could be changed everyday without problem, and without touching the server. If there some problem it client server should respond - your layout if broken, sorry - and there is no problem with whole system stability.

Of couse i don't wont to say that desing stuff should be removed from server. It's a great value to be able to desing layouts in web if there is no other tool, also making some hotfixes in layouts etc.

HTML 5 could give you all that functionality offline too.

You say that keeping the server stable is preferable but experience shows
we get far more bugs from changes in the output from the designer breaking
the clients than the designer itself breaking.

Alex

Bartek <email address hidden> wrote:

Question #101319 on Xibo changed:
https://answers.launchpad.net/xibo/+question/101319

Bartek posted a new comment:
Let's discuss it, why not, as long as it's only 100% theoretical subject
:)

Every user have different needs, You need everywhere access, we for
example thinking about offline desinging capabilites.

There are pros and cons of web access conception, in long term view
there is much more problems for us in developing web in compare to
separate app.

For example we exactly need what we need to work more efficient, it's
probably quite different that Your particulatr needs.

I don't know where you see some slowdown there? Maybe the time needed to
export required function to xmds, later web development should be almost
unrelated to out conceptional app.

I really think that a gui with some used drag drop library for c# /
similar could be much more functional that web iface. For example i can't
agree that google docs is easier than locally installed ms word, ever as
old as word 97.
But ofcorse there is no multiuser everywhere access. Something lost,
something works better.

Right now in present interface every little thing must be coded or there
is a usability problem - for example long time bar with 70-100 pces on
every layout, when adding single element, scrollbar is again on beginning.
You can say it's not very important but think what is happening when our
designer need to create 30 layouts with 70 elements :)
Yes, i know, it could be fixed, but there is a lot of such little details
that require coder atention all the time, i can only guess that when
using some timebar control in gui oriented IDE (almost) don't need such
atention.
And what if we're thinking of having everything related to layout desing
on screen on one time, for example on left side layout preview and some
dir stucture with materials, on center a lot of timebars related to
particular regions, on right parameters to selected block etc.
It's totally different vision that current webiface, and probably you
won't like it becouse your needs are different. Other thing is it possible
to organize it in some web abstaction lib? probably much harder han
organizing elements in some Visual* language, wxwindows, etc.

Last thing- we like to make changes more often than one time / 3 months
without loosing stability. In separated model, when server is stable and
unmodified without need (reorganizing buttons on gui or changing some
windows dimension don't force us to change every single thing in
server)- desing client could be changed everyday without problem, and
without touching the server. If there some problem it client server
should respond - your layout if broken, sorry - and there is no problem
with whole system stability.

Of couse i don't wont to say that desing stuff should be removed from
server. It's a great value to be able to desing layouts in web if there
is no other tool, also making some hotfixes in layouts etc.

--
You received this question notification because you are a member of Xibo
Developers, which is an answer contact for Xibo.

This email carries a disclaimer, a copy of which may be read at http://learning.longhill.org.uk/disclaimer

I think the ultimate goal should be to provide a comprehensive API which
supports all of Xibo's key transactions. This would give the most open and
extensible solution.

"The Extend Xibo media data services" blueprint for 1.1.1 was intended to
begin this process by implementing the transactions involving
adding(uploading)/editing/deleting file based media. By necessity it would
also involve implementing the authorization transactions.

I will being drafting a list of transactions that are used in Xibo and put
them on the wiki. I will indicate the ones I was thinking of doing for
1.1.1.

I am not particularly against people wanting to design their own GUI for key
transactions, however I think we are a long way off having an API that
supports enough transactions for this to happen.

HTML5 - you're right, but it's theory right now, no programmers knowing html5, no good libs. But maybe i'm wrong?
And what with slower computer with old browsers..

Stability - I was thinking about conversation with server like command sequence:

- make regiion a x b on c,d
- put file a on timetable
- put file b on timetable

with verification on each step on server side if it is possible et.
definitly no: there is a xml layout for you, put it on all clients immediality :)

But i don't know if it would be ever possible. That's the reason why i'm asking today not 6 months later :)

I think that generally speaking it will be possible, and it is what we want
to do (have a full API). However it is a way off and the blueprint you saw
only relates to the file based media transactions.

It will be interesting for me to explore all the transactions in Xibo, so I
will do so anyway and make the list available on the Wiki.