[bongo-devel] Stream metadata (was: Re: Drivel)

[Daniel Brockman]

[Sorry, this is a little long.]

address@hidden (Daniel Jensen) writes:

> Daniel Brockman <address@hidden> writes:
>
>>    Notice how there is no coherent `track object' in sight.
>>    This is what I propose to change.
>
> For my definition of coherent:
>
>     (text-properties-at (bongo-point-at-eol))
>
> There's a track object.

Good point.

> Do you want to work with anything that is radically
> different from a property list? And in that case, how?

My thought was to introduce the notion of non-buffer-bound
tracks, which could exist independently of any Bongo buffers.

I don't know if this is a good idea, and I don't feel like
thinking about it now because it is a pretty deep structural
change of dubious value and there are more important issues.

Another related thought I've been having is to replace the
notion of infosets with something more flexible.  Right now
the most important thing infosets do is specify how tracks
may be joined together; I believe the strictly hierarchical
joining is insufficient.

This is a perhaps even deeper structural change whose value
is slightly less dubious to me; nonetheless, it is dubious,
so I don't feel like thinking about this right now either.

So I will drop all this and try to think clearly about the
metadata code.  (I should have done this from the start.)

I think it overuses hooks.  This may be what caused me to
consider structural changes: the mechanism seems fragile.

In general, I believe programs should not use hooks for
their normal operation.  Hooks are good for customization,
but to avoid COME FROM-programming I prefer not to use them
for things that could just as well be done directly.

Programs that are divided into separate modules often use
hooks as a low-coupling interface between different modules.
Since this lets programs work without modules explicitly
calling into each other, it superficially reduces coupling
(in fact replacing GO TO-coupling with COME FROM-coupling).

In my experience, this usually leads to architecture bloat.
Since you are stylistically forbidden from calling into some
parts of the program, basically you end up spending time
figuring out how to interface the program with itself.

That was a digression, really not that relevant here, and
maybe you don't agree to it all.  It just came to my mind.

Anyway, to make this concrete, I suggest introducing a
function `bongo-stream-metadata-changed' and moving into it
some of the functionality currently hanging off of hooks:

binh891TVYvAB.bin
Description: application/emacs

I would merge the following functions into the above function:

   `bongo-use-stream-song-title'
   `bongo-use-stream-title-as-track-title'
   `bongo-use-stream-title/genre-tooltip'
   `bongo-replace-uri-title-with-stream-title'

(Simple things like `bongo-show' can stay on
`bongo-stream-metadata-changed-hook'.)

Any needed customization possibilities should then be
provided using customization variables.

If a feature is hanging off of a hook, it is easy to neglect
it by thinking of it as `not part of the core'.  I don't want
some features to be poorly integrated in Bongo because of this.

So let's go through the hook functions one by one.

The first and second ones are both compromises, I think.
I'd like to have both, so the player infoset would have both
the stream title and the title of what's currently playing.
Furthermore, I believe this is always desirable, so we can
hard-code it.  Any objections?

The third can also be hard-coded, but I would modify it to
show the URL if the buffer already displays the stream title.
Come to think of it, in fact, maybe all file tracks should
show the file name in a tooltip (especially URI tracks).

If so, we could simplify this by always showing in the
tooltip only the URI --- not the stream title.  Then this
code could be put elsewhere.

If we take that path, it makes sense to hard-code the fourth,
since the URI would be available in the tooltip anyway.

Here is my proposal:

bin571jBFJT4c.bin
Description: application/emacs-lisp

If you think this is good, I will install it.

>> My life has been a bit weird lately.  Basically, the upshot
>> has been that I have neglected a lot of things I care about,
>> including some friends, my mom, Bongo, and eating properly.
>
> Okay. Those other things are more important than Bongo.
> I'm not in a hurry with anything here, so please take your
> time. I appreciate that you're talking about it.

Thank you. :-)

I appreciate that you're listening and responding.

>> Do you think the current setup is good, with me maintaining
>> some kind of --- in effect --- official repository, and you
>> and everyone else sending me patches?
>>
>> I don't mind it much, except that I feel bad when I end up
>> not applying patches that are sent for a long while simply
>> because I have some undisclosed `ideas' about the code.
>
> So you have the infrastructure that works with you being a
> control freak ... It is good. (And there's nothing wrong
> with being a control freak in this position.)

This is a quite new experience for me.  I have never before
maintained anything that is both actively developed and used
by a lot of people I don't know personally.

The infrastructure has sort of just sprung up on demand ---
of course, that's a good sign.  I just want to emphasize
that I'm not married to any part of it.

> You only need to communicate better with contributors.
> Does that sound reasonable?

Okay.  Yes, that does sound reasonable.  The other day a
friend of mine told me I should write more short mails.

> Remember, you'll have the final word anyway in all cases,
> but people would know better what's going on and you'd
> hopefully not feel bad about not installing stuff.

Then I will try to better myself in this regard.

>> Anyway, if you want we could each maintain our own personal
>> repositories and pull patches from each other, instead of
>> having a bottleneck configuration where you shower me with
>> awesome stuff and I try to keep up with installing it all.
>
> Code would still have to go through you to the official Bongo,
> so it wouldn't be that different.

Well, unless we abandon the concept of an `official Bongo'.

I'm suspicious of authority and in this case I'm a little
bit of an authority so that makes me even more suspicious.

But of course in the end all the code is free so maybe this
is a little moot.  Just know that I'm an anarchist by heart.

> And I have to say that "shower" and "awesome" are quite exaggerating
> words. At least that's how I feel about my contributions!

I was just expressing how _I_ felt about it. :-)

-- 
Daniel Brockman <address@hidden>