PDA

View Full Version : 6.2.2 Release, 6.3 and more.



Dan Sully
2006-04-27, 10:37
All - we've officially released 6.2.2, with lots of fixes - thanks for all
your help. Here's a quick overview of what's to come:

* A 6.3.x branch has been created from the 6.2.x branch.

Any small-medium fixes should go here. Andy will be backporting the
XMLBrowser & Shoutcast code from trunk. We're looking at more minor firmware
fixes here, improved Internet Radio compatibility and the like.

* While the 6.2.x branch will stay around for a while, only if there is a
critical bug fix that we missed will anything be released from there.

Please do not check anything into the 6.2.x branch. Use 6.3.x

* Work on split-scanner continues - I hope to merge those changes back into
trunk/6.5 sooner rather than later, now that we have an official 6.2.2
release which is stable.

* Also for 6.5, I'd like to get the Setup code cleaned up, and move a lot of
the perl into HTML+CSS. I still have the Setup Wizard on my plate, and
getting logging/exception handling under control.

Anything I missed? I know that the Wiki "Software Roadmap" is getting out of
date - I may try and update it, but since we do try and move rapidly on a lot
of things, having a roadmap which targets 6 months out isn't going to be very
useful. I'd like to try and target 2 weeks out for features & fixes, I think
that will provide a more realistic goal.

Thanks, and feel free to let myself, Andy or Dean know of any concerns / questions.

-D
--
Do not panic, do not panic! We are trained professionals!
Now, stay calm. We are going around the leaf.

Grotus
2006-04-28, 12:24
Dan Sully blurted out:
> * Also for 6.5, I'd like to get the Setup code cleaned up, and move a
> lot of the perl into HTML+CSS. I still have the Setup Wizard on my
> plate, and getting logging/exception handling under control.

Do you have anything specific planned for this?

I'm currently investigating removing the setup hash from setup.pm and
moving it into a YAML file, or files (one per category). The two main
blocks right now for that are figuring out how to import a code
reference from the YAML (and not just any code that happens to be
there), and handling composite strings (strings built from multiple
string tokens, or string tokens and other text).

Dan Sully
2006-04-28, 12:51
* Robert Moser shaped the electrons to say...

>>* Also for 6.5, I'd like to get the Setup code cleaned up, and move a
>>lot of the perl into HTML+CSS. I still have the Setup Wizard on my
> > plate, and getting logging/exception handling under control.
>
>Do you have anything specific planned for this?
>
>I'm currently investigating removing the setup hash from setup.pm and
>moving it into a YAML file, or files (one per category). The two main
>blocks right now for that are figuring out how to import a code
>reference from the YAML (and not just any code that happens to be
>there), and handling composite strings (strings built from multiple
>string tokens, or string tokens and other text).

I would like to see as much code removed as possible, including moving
anything it YAML. I'd really like to see all of the display logic moved into
TT+CSS under EN. A minimal Setup.pm would populate the required fields.

Ideally, validation would be done in JavaScript, and we wouldn't need any
code references floating around.

-D
--
They're techno trousers, ex-NASA, fantastic for walkies!

Grotus
2006-04-28, 13:21
Dan Sully blurted out:
> * Robert Moser shaped the electrons to say...
> I would like to see as much code removed as possible, including moving
> anything it YAML. I'd really like to see all of the display logic moved
> into
> TT+CSS under EN. A minimal Setup.pm would populate the required fields.

I agree. There's some pretty hairy logic in there now, so it isn't
exactly straightforward to convert. But we'll get there.

> Ideally, validation would be done in JavaScript, and we wouldn't need any
> code references floating around.

We would still need to validate in SlimServer, JavaScript validation
does not prevent hand crafted requests from being sent. And there are
other code references besides the validation stuff.

Dan Sully
2006-04-28, 13:24
* Robert Moser shaped the electrons to say...

>>* Robert Moser shaped the electrons to say...
>>I would like to see as much code removed as possible, including moving
>>anything it YAML. I'd really like to see all of the display logic moved
>>into
>>TT+CSS under EN. A minimal Setup.pm would populate the required fields.
>
>I agree. There's some pretty hairy logic in there now, so it isn't
>exactly straightforward to convert. But we'll get there.

Right.

>>Ideally, validation would be done in JavaScript, and we wouldn't need any
>>code references floating around.
>
>We would still need to validate in SlimServer, JavaScript validation
>does not prevent hand crafted requests from being sent. And there are
>other code references besides the validation stuff.

Well I see things that currently have validators that are code refs turn into:

<input type="hidden" name="audiodir.validate" value="isDir">

See http://search.cpan.org/~bowmanbs/CGI-Expand-2.02/Expand.pm and:

http://search.cpan.org/~nuffin/Catalyst-Plugin-Params-Nested-0.02/lib/Catalyst/Plugin/Params/Nested.pm

for examples of the nested params / ror syntax.

-D
--
It does not do to leave a live Dragon out of your calculations..

Grotus
2006-04-28, 13:39
Dan Sully blurted out:
> * Robert Moser shaped the electrons to say...
>
>>> * Robert Moser shaped the electrons to say...
>>> I would like to see as much code removed as possible, including moving
>>> anything it YAML. I'd really like to see all of the display logic
>>> moved into
>>> TT+CSS under EN. A minimal Setup.pm would populate the required fields.
>>
>>
>> I agree. There's some pretty hairy logic in there now, so it isn't
>> exactly straightforward to convert. But we'll get there.
>
>
> Right.
>
>>> Ideally, validation would be done in JavaScript, and we wouldn't need
>>> any
>>> code references floating around.
>>
>>
>> We would still need to validate in SlimServer, JavaScript validation
>> does not prevent hand crafted requests from being sent. And there are
>> other code references besides the validation stuff.
>
>
> Well I see things that currently have validators that are code refs turn
> into:
>
> <input type="hidden" name="audiodir.validate" value="isDir">
>
> See http://search.cpan.org/~bowmanbs/CGI-Expand-2.02/Expand.pm and:
>
> http://search.cpan.org/~nuffin/Catalyst-Plugin-Params-Nested-0.02/lib/Catalyst/Plugin/Params/Nested.pm
>
>
> for examples of the nested params / ror syntax.
>
> -D

http://slimserver:9000/setup.html?page=SERVER_SETTINGS&audiodir=bogus&audiodir.validate=acceptAll

There still needs to be a validation in the server which cannot be
influenced from the client.

Dan Sully
2006-04-28, 13:41
* Robert Moser shaped the electrons to say...

>http://slimserver:9000/setup.html?page=SERVER_SETTINGS&audiodir=bogus&audiodir.validate=acceptAll
>
>There still needs to be a validation in the server which cannot be
>influenced from the client.

Why? Who is actually going to mess with it? I am not worried about security
issues. If you are, run behind a password protected SSL version of Apache.

Specififying the validation in the template removes tons of code and makes it
simpler for the common case.

-D
--
It does not do to leave a live Dragon out of your calculations..

dean
2006-04-28, 13:44
On Apr 28, 2006, at 1:41 PM, Dan Sully wrote:
> I am not worried about security
> issues.
You should be and you should say so. A bad reputation about security
will hurt the company. It's less about how secure it is and more
about how secure it's perceived to be.

Dan Sully
2006-04-28, 13:47
* dean blackketter shaped the electrons to say...

>On Apr 28, 2006, at 1:41 PM, Dan Sully wrote:
>>I am not worried about security
>>issues.
>You should be and you should say so. A bad reputation about security
>will hurt the company. It's less about how secure it is and more
>about how secure it's perceived to be.

I am worried about security. But changing a pref is hardly secure. If you've
already have access to the Settings screen, there are much greater things to
worry about.

-D
--
"My pockets hurt." - Homer Simpson

dean
2006-04-28, 14:06
On Apr 28, 2006, at 1:47 PM, Dan Sully wrote:

> * dean blackketter shaped the electrons to say...
>
>> On Apr 28, 2006, at 1:41 PM, Dan Sully wrote:
>>> I am not worried about security
>>> issues.
>> You should be and you should say so. A bad reputation about
>> security will hurt the company. It's less about how secure it is
>> and more about how secure it's perceived to be.
>
> I am worried about security.
I know you are. But that's not what you said.

> But changing a pref is hardly secure. If you've
> already have access to the Settings screen, there are much greater
> things to
> worry about.
Yes and no. It's reasonable to have a technical discussion about
validation and making sure that the server doesn't do bad things
(crash the machine, erase the hard disk, hand over root) based on
packets from outside the machine.

Look through our www logs to see how many people have their servers
(accidentally or on purpose) open to the outside world. A well
publicized security bulletin about SlimServer would be a VERY BAD THING.

mherger
2006-04-28, 14:24
> We would still need to validate in SlimServer, JavaScript validation
> does not prevent hand crafted requests from being sent. And there are
> other code references besides the validation stuff.

I think we're not only talking about security. But you can't always expect
Javascript to work, and even less to work as you expect it to. Some even
turn off JS for security reasons. And there are still quite a few users
out there using Handheld skins and others on devices that definitely won't
work with javascript.

Skins like the Nokia770 are a different thing as they're designed for a
well defined platform.

--

Michael

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

Dan Sully
2006-04-28, 14:32
* Michael Herger shaped the electrons to say...

>I think we're not only talking about security. But you can't always expect
>Javascript to work, and even less to work as you expect it to. Some even
>turn off JS for security reasons. And there are still quite a few users
>out there using Handheld skins and others on devices that definitely won't
>work with javascript.

That's fine. But defining the validation type in the HTML is not a big issue.

And if we decide that it is, that is much more self contained, and shouldn't
hold Robert up from moving the data driven setup hash into the Template,
where layout and data can be in one place.

-D
--
<dr.pie> 31336.5: the neighbor of the l33t