Hiya

[Yuval K. <not...@wo...>]

Hi people...

Being the big dictator of things in general, i've taken the liberty of
bugging nearly all of you. I've since collected some thoughts, and have
some goals and ideas, most of them yours.

I must admit I have not given this a fraction of the time I thought I
would, but I was getting impatient.

It's all on paper right now. As a sort of graph, and outline document
beside it.

Does anybody object to it being in dot/tex, to be munged into pretty
graphics by graphviz, and PDFs/whatever else?

If that's the case I should probably get it over with in the weekend,
and the flame-war I've been so anxious to start can finally begin.


In case you haven't heard the usual speech:

	ID3 is crap. Music programs are crap. They limit you with pointless
technical constraints instead of dealing well with how the logic of
music really works. In ID3 you define an artist with a string, a "name".
If it's several artists, you find a quirky solution like putting in
slashes. Even worse, the data is stored inside the song itself. If you
had a typo in the song name, you have to fix it everywhere. Aggregate
functions help, but it's still an issue. Also, this data, being
encapsulated in the media format, is not shared between the medias.
PCM/WAV/AIFF have no such data. MPEG implements it with out of band
frames - ones with invalid headers. OGG and FLAC are supposed to be
better, but i think my point is made out.

	The idea is to create a data oriented application, which knows about
music. It's runtime is set up by letting the user mix and match objects,
fusing them together using a framework I wrote: Object::Meta::Plugin.
These objects will let the user choose the technical aspects of the data
- which persistence backend to use, what interface to play songs into,
add a web GUI, use a certain codec implementation that's hardware
optimized for their platform (uh, not in Perl), and so forth. These
objects will be independant, and the O::M::P way solves this well in
theory, encouraging atomic feature sets, and good interoperability, with
few limiting conditions.

	What we lack is a data model which is stable, and flexible, so that
we do not waste efforts later. This is a harder problem than it sounds,
but those of you which I've bugged have shown an incredible amount of
insight on how this should be solved, or what the problem actually is.

	The draft spec which will be typed up soon enough should provide the
basis for something that can be ironed out, discussed to bits,
refactored and maybe even eventully implemented.

That's the agenda.
Ciao!

P.S.
I never meant there to be so much hooplah about it all - but I think it
adds to the general atmosphere around fryTunes, so it's not /that/ bad.
I'm still sorry though.. =3D)

P.P.S
I'm working on the website a bit, from time to time. It will probably be
done in Maypole, because I'm working on learning it right now. It will
also be done using Petal, because I like Petal, and I've only put some
work into it.
The layout needs help, though.
http://nothingmuch.woobling.org/frytunes-new/.
It will also /not/ be hosted on sourceforge, because they don't give us
mod_perl, which is no fun.
The goals were standard compliance for ease of maintaince and better
user experience, fiddling with stuff I haven't before (RSS
reaggregation, MVC, SVG, CSS), and being informative. The last part will
be resolved at some point in the future, perhaps.

--=20
 ()  Yuval Kogman <not...@wo...> 0xEBD27418  perl hacker &
 /\  kung foo master: /me tips over a cow: neeyah!!!!!!!!!!!!!!!!!!!!!!