Last week I spent my time working on the fallout from my frontend-backend work. It was actually not that bad. Janet filed several bugs, but they all required one or two lines to fix them. I also worked a few 1.2 bugs that I didn’t cause.
In between bugfixing I worked on trying to create a CLI frontend just to see if it could be done. It was actually pretty straight forward. That’s pretty exciting to me since it suggests it can be pretty easy to create alternative frontends. Also I found out that the python cmd module rocks.
This week I hope to start on the database changes and do 1.2 bug fixing.
13 comments ↓
+1 for a alternative interfaces
We all love the Miro. Love the message, love the interface.
But at least on Linux, most people seem to dislike anything xul-based. They tolerate Firefox because of the extensions, install thunderbird just for recently converts, complain about Miro and pretty much puke at Songbird.
My biggest gripe about Miro?
- the interface is too slow.
- the interface can’t be changed.
- the interface makes it impossible to read more about an item. If i click the see more, it gets bigger, but so does the damn image. Where’s the rest of the text?
- half of my torrents have no names. Sounds like l10n issues to me.
All of these usability issues have one common source: XUL
So, +1 alternative interface. If it’s controllabel from the command-line; maybe i’ll bake some GTK and QT interface.
Wow, my first real comment to the dev blog. It’s nice to see that folks arre reading. I know a lot of folks think the same thing. Also we are currently working on a non-HTML interface, it’s just difficult to make one that works as well cross-platform as our current design.
Don’t be so suprised!
A large part of the miro users are actual ‘believers’. Off course we are occasionally checking in on the developments.
As to a cross-platform interface. Creating one isn’t difficult. Creating one as beatiful as the current is difficult though. There are two possible paths:
- choose a crossplatform widget toolkit
- create separate front-ends for each platform
But you might end up doing both.
Currently there are usability and performance problems. The usability problems can be solved, although not easily, but the performance problems are likely going to stay.
As for platform-non-specific toolkits, that don’t start a flamework. Something that will allow you to make an even prettier crossplatform interface:
http://www.clutter-project.org/
The question really becomes which direction is it going to go? Will Miro become more like a media-center type of software, or more like a desktop tool? For the latter native interfaces are always preferred, whereas the media-center approach suggests Miro should have its own look and feel, with more bling than the average desktop-tool. In that case, these toolkits might be more appropiate.
The interesting thing is that you don’t have to either-or. If you seperate the back-end and front-end cleanly, you can have both native interfaces (perhaps even maintained outside of Miro, for example by becoming part of Gnome and/or KDE) as well as a bling-media-center-style-interface.
I at least think, that a libmiro, as a sort of layer on top of libtorrent, would be the right direction.
From there on, you can see where the community takes it.
They might integrate it with already existing media-center-solutions. They might integrate it into a mobile-device. Like with libtorrent, the actual usage is not easily predictable. Who would have thought of Miro when making that library?
Anyways, good luck!
[...] - Backend reorganization (devs can check out Ben’s blog on [...]
I’ve thought some about having something like libmiro. One challenge is that the miro backend isn’t just sitting there doing nothing it’s downloading feeds, downloading videos, etc. So if two apps want to use libmiro, how would those tasks get done without duplicate work.
I think it might make more sense to have a miro daemon that runs in the background constantly. Then applications would connect to that. This solves the problem of background work, although it introduces more complexity since now there are 3 processes (the app, the background daemon and the downloader daemon). Maybe we could merge the background daemon and the downloader daemon somehow, but there are some real challenges on windows there.
The other challenge is to design an interface that allows the frontend and backend to communicate over a socket. This means rethinking a lot of our current code.
I think this would all be a lot of work, but possibly worth it in the end. If anyone has ideas on a way to get this done with less work, I’d love to hear it. Anything that eases the work of a frontend coder is awesome.
I just want to drop a line here…
I like the XUL Interface, I think XUL is the future in cross-platform development.
I think the miro interface is very functional on GNU/Linux and I think it serves its purpose without being slow or cluttered. The choice of having an alternative frontend cannot hurt, though…
On linux the communication could be done using dbus at least. A socket would indeed be a lot of work, but has the advantage that we could run the backend on a local server. There are even some linux-based routers that could possible run it.
I would however love to see the downloader integrated as the one separate deamon. It makes more sense to have a lean downloader launch at system-startup than the resource-hungry frontend that loads all kinds of libs (xine,xul) not needed when all we want is download.
The downloader and miro-db manager go hand-in-hand, but the front-end should be separate. There could even be a simple web-frontend this way.
The official front-end would just be prism running the web-frontend. I can’t image that being any slower than the current interface.
And it would be killer for the integration with other 3rd party apps (mythtv, totem, etc.).
Just a restfull web-service that is run locally, with an optional web-frontend.
Having the downloader and backend code run together would be ideal from a architectural standpoint. The really annoying problem is windows XP. One of the “features” is that it limits the number of half-open connections that any process can have to an incredibly low number (10 I think). BitTorrent easily eats up that many processes and that hoses all our other network activity (feed downloading, HTTP downloads, checking for updates, etc). I would guess it’s a problem with vista as well.
This is the entire reason the downloader was split off in the first place and I don’t know a good way around it.
[...] or Elisa…. He made the split between the two much cleaner and at the end wrote a sample command line interface. In the process of doing that work, he did a bunch of other things that affected the entire code [...]
@bdk
does that mean that you are actually spawning several proccesses that each have about 10 connections? Or just several threads?
One of the benefits of the seperation might be that is becomes easier for people to contribute as well.
Considering the width usage of technology (xul, python, libtorrent, xine) it is kind of scary.
I also wonder what kind of api’s are being considered for the separation to interface with the supposed miro-deamon? Esspecially if it’s a http-based network transparent system. Perhaps something restfull? Although that might be the hype du jour, this actually sounds like the perfect architecture for something like this.
That sort of gives a very basic, but functional, interface straight in the browser. Esspecially if the channels can just be requested using GET and return an rss feed with links to the video’s.
That sort of makes every rss-feed-reader tool out there a possible miro front-end. Not very functional, but still.
Subscribing to a channel could be done with a POST request.
And enabling the download of a certain video, or marking it as viewed, etc. could be done using PUT requests.
Also, what is the current database backend? What would be most cool, if the front-end could decide to attach extra tags to video’s if it wants to. This would give the front-end builders some freedom to experiment with different ways of organizing the video’s.
Last question: would it be wise to store (or backup) the meta information of a feed (url of the feed and the association between files in the folder and entries in the feed, etc.) in the folder of the feed?
This way when i move a bunch of video’s (burn certain directories to disc) and give them to somebody else that uses miro, that registers those video’s in his library. They would get the same meta-data and the associated feed.
Just a braindump though. There might be some performance issues with all of this.
so what happened? Did the Miro daemon ever see a light? Just want to let you know that there is still a strong need for a back-end front-end solution.
Wow, reading this post makes me think of how far miro has gone.
A lot has changed, but miro still doesn’t have a backend daemon. The issues that I talked about are still basically the same as above.
However, the frontend-backend separation has happened and several other frontends have been written: a CLI frontend, a debugging frontend, an attempt at a clutter frontend, etc. I don’t think any of them are frequently used, but I know some people are playing around with them.
What needs would a daemon fill for you? Maybe it would be possible with a specialized frontend. I could definitely see a frontend that runs in the background.
Leave a Comment