Le dimanche 28 novembre 2010 15:42:32, David Baelde a écrit :
> On Sat, Nov 27, 2010 at 3:54 PM, Romain Beauxis <[email protected]>
wrote:
> > In the spirit of an object-like system, I figured out that we need a
> > source.insert_metadata that applies to any source. The other alternative
> > would have been something of the type:
> > source.insert_metadata: source -> (metadata -> unit) * source
> > which I find not really attractive..
> > So, I have backported the method mentioned above to the main source class
> > and added a method #insert_metadata.
>
> I prefer the alternative: it may not look very attractive, but I don't
> think we should compromise our source model for a feature like that.
I understand your concern particularly in times of beta releases. However, I
do not think the change is so intrusive and it also makes sense to change the
API before a final 1.0. The changes on the source model are:
@@ -435,7 +442,15 @@
assert (Frame.is_partial buf) ;
if not caching then begin
let b = Frame.breaks buf in
+ let p = Frame.position buf in
self#get_frame buf ;
+ begin
+ match metadata with
+ | Some m ->
+ Frame.set_metadata buf p m ;
+ metadata <- None
+ | None -> ()
+ end ;
if List.length b + 1 <> List.length (Frame.breaks buf) then begin
self#log#f 2 "#get_frame didn't add exactly one break!" ;
assert false
And the associated metadata method and variable..
> Think about it: why add #insert_metadata as a fundamental method for
> all sources, and not #on_track, #on_metadata, and even #on_blank,
> #map_metadata or #source_dynamic? To push the point even further, why
> not add support for instantiation for all variables and not only
> references?
Well, why not :)
More seriously, I could also remark that we already have source.skip,
source.stop and other similar ones.
It just looked more natural to me to have an operator of the type:
metadata -> source -> unit
for this because, intuitively, you "push" metadata. On the contrary,
on_metadata and the like are callbacks so the current API makes more sense --
also, having a on_metadata method would be kind of confusing if, for instance,
one want to stack callbacks.
Unless we can agree on something, I'll stick to the second choise, though.
> > I think this gives a nice generalization:
> > * insert_metadata on sources inserts metadata directly during s#get
> > * insert_metadata on buffered sources inserts metadata into the buffer
> > * insert_metadata on encoded outputs inserts metadata in the encoded
> > stream All 3 functions have the same type and may or may nor filter
> > metadata. Filtering is configured according to "metadata.export" (list
> > of fields).
>
> For the encoded outputs, I don't think this makes a difference with
> the old behaviour (or the behaviour of the alternative new version of
> it). However, I'm wondering about the subtlety regarding buffered
> sources. It looks like there is a choice, but I'm not sure which one
> is the right one.
Yeah, I might have gotten it wrong on this one. Intuitively, one want to
insert metadata at the current time not in the buffer.
> Finally, one remark about the bigger picture. I totally support the
> generalization of insert_metadata so that it can be used directly from
> the script without going through server commands. However, I'd be
> cautious about inciting people to use them. Also, what does it have to
> do with harbor? One answer to this question is "nothing, so we'll add
> a distinct web server feature to liquidsoap" but another answer is
> that an external web server relying on our existing server may be more
> solid.
These are different changes. Support for in-script insert_metadata could be
used in many different situations. Harbor stuff is just one way to use it --
and
other. For instance, one thing that is possible now is to use harbor's HTTP
GET/POST to implement a JSON/AJAX-based callback to get the current metadata,
which I am sure will be useful to our users.
Romain
------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Savonet-devl mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/savonet-devl
