PDA

View Full Version : Smooth AJAX interface blows away any slimserver skin I've seen



PoW
2005-12-12, 23:20
So I think somebody needs to get in contact with this guy[http://www.mp3act.net/]. Take a look at this interface he has put together. It is so much faster and smoother than any slimserver interface I've used. I know most of the delay that is part of an interface comes from the database side of things. Even so this is amazingly clean and worth a serious look. I would use a skin like this in a second over any of the slimserver ones I've seen. If only it had the cool song moving feature on playlists like ExBrowse3...

What do you guys think?

bernt
2005-12-13, 04:15
http://www.jinzora.com/pages.php?pn=products&sub=jukebox

radish
2005-12-13, 08:47
mp3act looks horribly broken in my IE install here, I imagine the AJAX is FF specific. As for jinzora, nice that it supports slim, but other than potted (and pointless) bio pages for the artists I don't see what it has over the regular slimserver skins. Browsing doesn't seem any faster or easier.

JJZolx
2005-12-13, 11:22
Doesn't look that bad in my IE on XP Pro. Far from horribly broken. Some CSS layout issues, maybe, but everything seems to work.

I think an interface similar to this would be wonderful. One thing about AJAX, though, is that you need a very responsive server. SlimServer just isn't there yet, and certainly on many of the hardware platforms where it finds itself running, it probably never can be.

I also doubt you're going to see this type of rich interface until the page scripting language moves to something more powerful, such as php. It will be interesting to see how long it takes SlimServer to move to an Apache/MySQL/PHP platform. I have a feeling it will inevitably get there, even though it isn't on the current roadmap.

Alex Twisleton-Wykeham-Fiennes
2005-12-13, 11:37
On Tue 13 December 2005 18:22, JJZolx wrote:
<snip>

> I think an interface similar to this would be wonderful. One thing
> about AJAX, though, is that you need a very responsive server.
> SlimServer just isn't there yet, and certainly on many of the hardware
> platforms where it finds itself running, it probably never can be.

Generally the complexity of queries that are being generated by an AJAX
interface is considerably simpler per request than what is required to render
and entire page or frame. So I wouldn't necessarily assume that the response
latency with the current codebase would be the same as the latency in an AJAX
style situation.

<snip>

Alex

radish
2005-12-13, 11:45
Well it doesn't work at all here, IE6/XP/SP2. I guess it's pretty fragile - a lot of AJAX apps are in my experience.

As for PHP, the day Slimserver runs on PHP is the day I buy a Roku.

m1abrams
2005-12-13, 11:54
Well it doesn't work at all here, IE6/XP/SP2. I guess it's pretty fragile - a lot of AJAX apps are in my experience.

As for PHP, the day Slimserver runs on PHP is the day I buy a Roku.

Just curious whats the beef with PHP? In my experience coding with it, it is rather nice. I would rate it no worse or better than perl. Just different. I have a decent amount of experience with both lang.

radish
2005-12-13, 12:57
I'll admit up front that I don't have a huge amount of PHP experience, I wrote a simple CMS in it a couple of years ago as an experiment, and yes, as a tool for hacking up quick web sites it's not bad. However, a tool for building high performance multi-threaded streaming media servers it is not. No seperation of data and presentation (ala MVC), no strict typing - I don't even know if it has good threading support. Given the time and inclination I'm sure I could come up with more :)

It's all about the right too for the job, not whether one language is "better" than another. Perl is a great language for scripting, and was the original web development language because of it's aptitude for processing text in a stdio environment with very rapid development/test cycles (no compilation). PHP improves on Perl in a web scripting environment, no questions, but I still don't think it's right for Slimserver, and I question it's suitability for any large scale complex app.

In short I guess, if there's going to be the huge effort spent to move Slimserver to some other platform, I would hope it would be to one more suited for the task at hand that Perl, not less so. If, as was suggested, the move is to PHP, it would be a sign to me that whoever is leading the effort is not on what I consider a sensible path, hence why I'd bail.

Anyway this is all offtopic and rather academic seeing as I haven't contributed anything to Slimserver yet! My opinions are my own, but I defer to the amazing devs doing the real work to make the decisions :)

JJZolx
2005-12-13, 13:12
However, a tool for building high performance multi-threaded streaming media servers it is not.
I was suggesting the use of PHP only for the web interface. The underlying SlimServer engine might continue to be done in Perl, or perhaps even a compiled language if server performance is critical (which I'd think it would be). The SlimServer roadmap suggests moving to Apache at some point, instead of trying to implement an HTTP server as a part of SlimServer. I imagine only then could PHP even be considered, but I think it would encourage a lot more outside development and more creative web interfaces.

m1abrams
2005-12-13, 13:21
Hey radish wont argue with you there. However I would not call perl as having strict typing. ;)

I personally think slimserver should be split into a server binary with an API for a presentation layer. Then write the web interface in PHP or whatever you want.

fuzzyT
2005-12-13, 13:30
JJZolx wrote:
> The SlimServer roadmap suggests moving to Apache at some point,
> instead of trying to implement an HTTP server as a part of
> SlimServer. I imagine only then could PHP even be considered, but I
> think it would encourage a lot more outside development and more
> creative web interfaces.

of course, you could say the same thing about Apache/modPERL, and that
would seem to be a much more likely scenario.

--rt

radish
2005-12-13, 14:57
I was suggesting the use of PHP only for the web interface.
Fair enough, sounds a lot more reasonable.

If you're gonna write the backend in something a little meatier (for example, Java) then there are some very nice web scripting systems available which would plug right in - Velocity for example. I don't know how well PHP integrates to other platforms (are there PHP implementations to run within a JVM for example?). I know the designers here love Velocity because it is _so_ simple for non-programmers - much more so than JSP or ASP.

Jacob Potter
2005-12-13, 15:25
On 12/13/05, ron thigpen <ron (AT) fuzzsonic (DOT) com> wrote:
> of course, you could say the same thing about Apache/modPERL, and that
> would seem to be a much more likely scenario.

I remember hearing something about moving to mod_perl and Catalyst
(MVC framework) for 7.0, keeping Template Toolkit for the front end.
Don't know if that's still the plan, though.

- Jacob

Alex Twisleton-Wykeham-Fiennes
2005-12-13, 15:58
On Tue 13 December 2005 21:57, radish wrote:
> > I was suggesting the use of PHP only for the web interface.
>
> Fair enough, sounds a lot more reasonable.
>
> If you're gonna write the backend in something a little meatier (for
> example, Java) then there are some very nice web scripting systems
> available which would plug right in - Velocity for example. I don't
> know how well PHP integrates to other platforms (are there PHP
> implementations to run within a JVM for example?).

I would definitely second that - only I work primarily in webmacro rather than
velocity (not that there is that much difference). However, I would be very
happy to assist on a velocimacro / java front-end to slim server if such a
project was started.

> I know the designers
> here love Velocity because it is _so_ simple for non-programmers - much
> more so than JSP or ASP.

Where is here? (velocity isn't a name that I see that often...)

Alex

kdf
2005-12-13, 16:42
Quoting Jacob Potter <jacobdp (AT) gmail (DOT) com>:

> On 12/13/05, ron thigpen <ron (AT) fuzzsonic (DOT) com> wrote:
>> of course, you could say the same thing about Apache/modPERL, and that
>> would seem to be a much more likely scenario.
>
> I remember hearing something about moving to mod_perl and Catalyst
> (MVC framework) for 7.0, keeping Template Toolkit for the front end.
> Don't know if that's still the plan, though.

Seems to be the case, as the dynamic roadmap has not been updated recently:
http://wiki.slimdevices.com/index.cgi?SoftwareRoadmap

-kdf

radish
2005-12-13, 17:32
Where is here? (velocity isn't a name that I see that often...)


A large "unnamed" investment bank :) We're moving to use more and more velocity in place of existing jsps.

Ultramog
2005-12-14, 09:36
Would be great. I'd love to work on a Flash presentation layer. Stateful, higher performance than rendering page views for every click, and all that.

dSw
2005-12-14, 11:34
Would be great. I'd love to work on a Flash presentation layer. Stateful, higher performance than rendering page views for every click, and all that.

Flash?!?

I'd prefer a DOS interface to that rubbish! ;-)

kdf
2005-12-14, 11:38
Quoting dSw <dSw.201m0b (AT) no-mx (DOT) forums.slimdevices.com>:

>
> Ultramog Wrote:
>> Would be great. I'd love to work on a Flash presentation layer.
>> Stateful, higher performance than rendering page views for every click,
>> and all that.
>
> Flash?!?
>
> I'd prefer a DOS interface to that rubbish! ;-)
>
there once was a flash skin included, called Gordon. It was not
updated by the author (no idea who that was). No one was willing to
take it on, and no one seemed all that interested in it. It went away.

-kdf

mherger
2005-12-14, 12:02
> I'd prefer a DOS interface to that rubbish! ;-)

It's been there for ages:
telnet slimserver 9090

:-)

--

Michael

-----------------------------------------------------------
Help translate SlimServer by using the
StringEditor Plugin (http://www.herger.net/slim/)

dean
2005-12-14, 12:34
Ultramog,

Despite some of the negative feedback you may hear regarding Flash, I
can say that a really slick Flash interface would be most welcome.

How can we help you out with this?

-dean

bklaas
2005-12-14, 12:52
Just to clarify, I think it's important to note that a really well crafted Flash interface/skin is quite a different animal than a AJAX/DHTML/CSS/DOM-based interface/skin. I wouldn't develop anything in Flash because of its proprietary nature, but that's a question of taste and philosophy.

Both, IMO, would be welcomed by a non-trivial portion of the SlimCommunity.

AJAX has huge potential for a slimserver front-end. More than anything, I would be psyched to see a non-frames based page that could update itself without a full browser refresh. That is what an AJAX interface could do. If I can ever dig myself out of the bottomless pit that is My Real Job, maybe I'll start work on one...

#!/ben

dSw
2005-12-14, 13:59
My comment about Flash was half-joking.

I agree that there is a place for Flash.. but I think that an AJAX solution could be a lot better for a browser environment - if well designed.

However, I do agree that new ideas for user interfaces should be encouraged.

Steve Baumgarten
2005-12-14, 14:36
> My comment about Flash was half-joking.
>
> I agree that there is a place for Flash.. but I think that an AJAX
> solution could be a lot better for a browser environment - if well
> designed.
>
> However, I do agree that new ideas for user interfaces should be
> encouraged.

I'm not generally a Flash proponent, but anyone with misgivings about
Flash should try:

http://www.pandora.com

In addition to being a very cool new music streaming service (based on
the Music Genome Project), the user interface is superb. Perhaps
something as smooth, fluid and elegant could be achieved using AJAX;
regardless, it's a good example of what Flash can do when used correctly
and when the goal is to provide the best user experience possible rather
than to cram the most unneeded animation possible into a web page (which
sadly is how it is most often used).

SBB






Visit our website at http://www.ubs.com

This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.

dean
2005-12-14, 15:09
On Dec 14, 2005, at 1:36 PM, Steve Baumgarten wrote:
> I'm not generally a Flash proponent, but anyone with misgivings
> about Flash should try:
>
> http://www.pandora.com
>
> In addition to being a very cool new music streaming service (based
> on the Music Genome Project), the user interface is superb. Perhaps
> something as smooth, fluid and elegant could be achieved using
> AJAX; regardless, it's a good example of what Flash can do when
> used correctly and when the goal is to provide the best user
> experience possible rather than to cram the most unneeded animation
> possible into a web page (which sadly is how it is most often used).
I understand that it was built using the (extremely cool) OpenLazlo
flash technology:

<http://www.laszlosystems.com/>

fuzzyT
2005-12-14, 15:40
I'd encourage those with negative preconceptions about Flash UI to
withhold judgement. That platform has been radically upgraded and we're
probably just a few months away from seeing a wave of web applications
with very nice Flash-based user interfaces.

Granted AJAX has the lead currently, and is more a standards track
approach. The drawbacks to AJAX are the development resources required
and user-agent (browser) compliance issues.

Developing to the AJAX target currently requires pretty top drawer
skills in a number of departments: XML, CSS, Javascript, DOM, DHTML,
etc. Tools are certainly coming along, but it's hardly an operation for
the meek at this point. Flash is proprietary, but the proprietary
owners have gone to the trouble of creating some pretty nice tools.

As for user-agents, well, AJAX is still basically DHTML and that means
much suffering over browser compliance. Flash apps have the advantage
of being able to update their container (the Flash engine) pretty much
seamlessly.

And there are going to be other candidates in the not-HTML,
rich-client-over-the-web technology runoff. Like XUL. And that other
XULish thing coming from Redmond.

For another nice demo of some Flash rich-client UI, get yerself a test
account here:
<http://www.laszlomail.com/lzmail/>

It's a full webmail client, and pretty darn slick. Made with OpenLazlo,
an open-source toolkit for producing Flash-based rich client apps.

--rt

bklaas
2005-12-14, 15:52
rt-- fantastic summary of the State of Things.

lots of uber-cool stuff to look forward to. XUL, etc. are going to have some really exciting applications to slimserver in the months/years to come.

dSw
2005-12-15, 01:54
This is an interesting read (Flash is at no. 3) - http://www.useit.com/alertbox/designmistakes.html

The articles mentioned in the Flash entry are worth reading as well . The guy makes some good points (for and against).

My main beef with it is that it just tramples all over web-standards within the web browser environment. It's a right pain in the a** when you naturally hit the 'back' button only to be taken right back to the start!

I would quite like to see a standalone Flash interface, however i.e. not within a browser.

fuzzyT
2005-12-15, 10:12
bklaas wrote:

> lots of uber-cool stuff to look forward to. XUL, etc. are going to have
> some really exciting applications to slimserver in the months/years to
> come.

yeah, like SongBird:
<http://www.songbirdnest.com/roblord/story/what_is_songbird>

can't wait to play with this. it's XUL based. some CLI glue code to
allow this app to control a houseful of SBs, now that would be cool.

--rt