liblo-devel Mailing List for LibLO

On Tue, Mar 11, 2008 at 9:46 PM, Martin Habets
<err...@mp...> wrote:
> Just as a background you may want to have a look at some work I did
>  on this a while back, to show where extending liblo with service
>  discovery and namespace exploration may lead to.
>  http://liboscqs.sourceforge.net/

Wow, thanks I hadn't heard of this one.
I'll take a better look at it soon.

>  In short, it turned out to be more work than I expected initially.
>  Off course I think this is a worthwhile direction to take, although I
>  would implement some issue differently now.

Fair enough. :)

I think the first step I guess is to include a simple mechanism for
enabling avahi/bonjour announcement.  The query stuff I guess can wait
a bit, but I'd like to keep it on the table.

There are a few bug fixes and whatnot in the svn right now so I'm
thinking about 0.25, and I might wait on making decisions related to
avahi for 0.26.

It may even be the case that using an extended library to handle query
and such things is actually the right approach, allowing us to keep
liblo itself as simple as possible.


Steve

Just as a background you may want to have a look at some work I did
on this a while back, to show where extending liblo with service
discovery and namespace exploration may lead to.
http://liboscqs.sourceforge.net/

In short, it turned out to be more work than I expected initially.
Off course I think this is a worthwhile direction to take, although I
would implement some issue differently now.
Martin

On Sun, Feb 24, 2008 at 03:27:33PM -0500, Stephen Sinclair wrote:
> Hi,
> 
> Some really good points here.
> Sounds like everyone's interested in this functionality.
> 
> On Fri, Feb 22, 2008 at 5:40 AM, Steve Harris
> <S.W...@ec...> wrote:
> >  I think I would want an advertising API, something like
> >
> >  lo_server_thread_advertise(st, id, ...)
> >  eg, for jamin:
> >   char *extra = g_strdup_printf("file=%s", file_name);
> >   lo_server_thread_advertise(st, "http://jamin.sf.net/osc_control",
> >  extra);
> >
> >  MDNS records have a field for putting ID information, like
> >  uri=http://... file=...
> 
> I definitely like the idea of providing a URL for information on the
> expected OSC namespace.
> This might be a very useful alternative (or even in addition to)
> automatic namespace querying.
> 
> 
> >  That implies we'd also want a lo_server_discover() function that scans
> >  the available MDNS records, find the OSC ones, does some pattern
> >  matching and returns an array of lo_addresses and "extra data" strings
> >  or something similar.
> 
> Could be useful, sure.  I think it's a distinct functionality though,
> being discoverable, and doing the discovering.
> But certainly the two go together.
> 
> >  lo_server_thread_stop and _start could implicitly publish and
> >  unpublish the advert, and lo_server_thread_free() implicitly free the
> >  associated data.
> 
> It's probably how I'd do it.  I guess the question is more whether it
> should be done by default, or if it should require enabling by the
> user.
> And should it be enabled on a per-server basis, or globally?
> 
> I think I'd vote on doing it automatically, unless explicitly disabled
> at run-time.  (or configure-time of course.)
> 
> 
> >  > The patch makes avahi support optional with a configure flag.
> >
> >  It's probably a good idea to autodetect, and have -enable and --
> >  disable flags, it doesn't really cost anything if it's compiled in but
> >  not used.
> 
> Sure.
> 
> 
> >  > - if an OSC service is announced, does this imply that it should
> >  > respond to certain standard messages? as far as I know no such
> >  > standard exists.
> >
> >  Not as far as I know wither, it would have to be per-application and/
> >  or emerging consensus.
> 
> I guess that discussion belongs on the OSC list.
> It's about time someone brought it up again anyway.. :)
> Namespace discovery is really is an outstanding issue with OSC, and
> the longer it remains unattended, the more people will implement
> various incompatible solutions.
> 
> 
> >  > Since it's optional at configure time, would it be harmful to have
> >  > lo_servers simply always announce on zeroconf if this option is
> >  > enabled?
> >
> >  I think to be useful you have to give them some ID information, so a
> >  dedicated client can find a (set of) dedicated server(s). You can
> >  imagine for eg. the superlooper client autoconnecting if there's only
> >  one server on the local network and put up a request dialogue if there
> >  more than one.
> >
> >  Just knowing that there's some OSC server at osc.udp://
> >  192.168.0.1:9999/ is not terribly useful.
> 
> Absolutely.  I'll have to read up a bit on avahi/zeroconf to figure
> out how to add more information to the announce.
> Patches would be accepted here .. ;-)  But it's on my todo list, for sure.
> 
> 
> 
> On Fri, Feb 22, 2008 at 5:44 AM, Camille Troillard
> <ca...@os...> wrote:
> > Is there a specific reason to add "overload" methods to server
> > instantiation?
> > I think Bonjour service publication is relatively independant from server
> > creation, and I would suggest something like:
> >
> > lo_zeroconf_publish (lo_server *)
> > lo_zeroconf_unpublish (lo_server *)
> 
> I think your idea looks cleaner, admittedly, but liblo is (in general)
> organized such that functions affecting a particular data structure
> start with the name of that data structure.  So, since a zeroconf
> announce is tied to a lo_server, the function should start with that
> in the name, I think.
> 
> (Yes, lo_send_message() is a exception to this rule!  arrr..)
> 
> On the other hand, if it were made into a global flag that all
> lo_servers respect, perhaps the functions could be:
> 
> lo_zeroconf_init();
> lo_zeroconf_free();
> 
> The extra information requested by Steve could be passed to
> lo_zeroconf_init()... no wait that doesn't work because each lo_server
> will have its own URI.  I guess some lo_server_* function will have to
> exist to support this.
> 
> 
> > > - Is adding an extra function to initialize zeroconf announcement
> > > adding extra complexity?
> >
> > IMHO, I think so.
> > It also adds the need for the developper to learn another API calls, etc.
> > I guess the default behaviour would be to publish Bonjour service every a
> > server is created.
> >
> > It would be great to configure the liblo library with a function to disable
> > Bonjour.
> > The configuration could be done like a global register.
> 
> Agreed on both counts.
> Well, whether or not configuration should be global is unclear to me.
> 
> 
> > If it is not desired to publish every servers (which I think needs to be
> > debated), then the default value for the global parameters would be to NOT
> > publish the service.  The user would just have to change that switch to
> > publish the subsequently created servers.
> 
> I'm having a hard time coming up with situations where one would not
> like to publish the service.. ;-)
> I think doing it by default is probably okay.
> Users who are aware of the zeroconf functionality may wish to disable
> it, but otherwise I think it's probably safe to use.
> 
> 
> 
> On Fri, Feb 22, 2008 at 6:35 AM, Lars Luthman <lar...@gm...> wrote:
> >  If someone does decide to implement namespace querying it might be a
> >  good idea to make it as similar to the D-Bus Introspection API as
> >  possible (see
> >  http://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-introspectable ).
> >
> >  D-Bus and OSC are already very similar, and lots of programs for Linux
> >  (and other GNOME/KDE-using systems) already use D-Bus, so having the
> >  introspection methods use the same concepts would be nice.
> >
> >  Yeah, XML is ugly, but it's there and it obviously works reasonably
> >  well.
> 
> 
> I don't know enough about D-Bus to make an intelligent comment here,
> but your comparison with OSC is interesting.
> I think I'll re-post some of this stuff on the OSC list and see if
> anyone has any comments there.
> What I've read so far about the proposed namespace querying stuff
> actually does already look very similar to that introspection XML,
> since it's basically a set of names and parameter types.
> 
> Another thing to consider is making zeroconf support compatible with
> Rémy Müller's "oscbonjour" object for Max/MSP.
> (I think the proposed patch is already fairly compatible, but I'd have
> to verify.)
> 
> 
> Steve

Hello all,

I agree with the comments by Kentaro and Steve; our oscSend is a very  
simple, limited utility, but could easily be extended to support  
optional type strings (if the address token in argv[3] contains a  
comma).

stp

--
    Stephen Travis Pope  --  Santa Barbara, California, USA
    http://HeavenEverywhere.com     http://FASTLabInc.com
  
  

Hi,

On Mon, Mar 10, 2008 at 6:31 AM, Kentaro Fukuchi <fu...@me...> wrote:
>
>  I quickly checked the difference between oscsend (I wrote) and oscSend
>  (yours) and found that oscSend automatically defines the types of values.
>  In contrast, oscsend requires the user to specify the types such as "iiiii".
>  In my opinion, to avoid confusion of type matching, it would be better to
>  ask the user the types (besides, you can send various primitive values
>  supported by liblo. e.g. true/false).
>  On the other hand, typing a sequence of types is annoying. I'm interested
>  in your design decision. Please let me know what do you think.

I think it's pretty important to have the type string available so you
can specify these types such as T and F.  However, yes, always
including the type string is sometimes annoying.

It might be nice to find a way to make it optional.
For example, include the type string with the address after a
delimiter, and but generate it automatically if it is not specified:

oscsend localhost 9000 /some/address,ifTs 0 1.2 hello
oscsend localhost 9000 /some/address 5 6.7 hello

The second case would not have the T type.


Steve

On Sat, 8 Mar 2008 22:01:41 -0800
Stephen Travis Pope <st...@he...> wrote:

> Hello all,
> 
> As part of a course I teach here, we also wrote minimal OSC send/dum  
> programs using liblo.
> The source is attached.

Hello Stephen,

I made very similar utilities to yours and they are now merged to the
main source tree of liblo. 0.25 will include them. You can download them
by using subversion, or from my web page:

http://megaui.net/fukuchi/works/oscsend/index.en.html

I quickly checked the difference between oscsend (I wrote) and oscSend
(yours) and found that oscSend automatically defines the types of values.
In contrast, oscsend requires the user to specify the types such as "iiiii".
In my opinion, to avoid confusion of type matching, it would be better to
ask the user the types (besides, you can send various primitive values
supported by liblo. e.g. true/false).
On the other hand, typing a sequence of types is annoying. I'm interested
in your design decision. Please let me know what do you think.

regards,

Kentaro Fukuchi

Hi Stephen,

On Sun, Mar 9, 2008 at 2:25 AM, Stephen Travis Pope
<st...@he...> wrote:
>
>  Hi all,
>
>  In the documentation of the liblo function
>  lo_server_thread_add_method(), it describes the typespec coercion
>  policy as, "Incoming messages with similar typespecs (e.g. ones with
>  numerical types in the same position) will be coerced to the typespec
>  given here."

That's right.  The idea, in general, is that the message itself should
be self-describing, and the handler should describe what kind of data
it can handle.  But a handler designed for floats should also work
okay if it is sent an integer, in most cases it will have to cast this
integer to a float, but liblo does it.

This is particularly important if you look at the implementation, for
example, in PureData, where it sends integers if the Pd message
contains a float that rounds off with no decimals, but sends a float
message if the number happens to have decimals.

See a thread on the OSC list here:
http://www.nabble.com/floats-vs.-ints%2C-how-to-deal-td8894913.html

I do agree with you that there are times where this may not be wanted.
 Making it optional, and runtime or compile time, is a possibility.
However, please keep in mind that LibLo is designed to make handling
OSC as simple as possible.  Type coercion is part of that.  If that
fits very badly into the system you are designing, it's possible that
liblo is just not for you.

[snip]
>  We stumbled across this because we have an OSC client running on an
>  iPhone that sends the message "/event" with typespecs "iiiiii" and
>  'iiiiif" for 2 completely different controllers; it took me a whole
>  afternoon to determine that it wasn't a bug in my code!

Sorry to hear about the wasted time.  However, I do think it's strange
that you are mixing up messages based on type like that.  Typically if
two messages have different semantics or whatnot, they should have
different address strings.


>  Has anyone ever made this coercion be a run-time switch, or at least a
>  conditional compilation flag?

Not yet as far as I know.  Feel free to submit a patch, or at least a
bug report so I can look at it in the future.  (The bug tracker is on
the sourceforge page.)


>  Should we add it as a conditional compilation flag in the 0.24
>  sources, or is 0.25 coming soon?

I'm thinking about doing 0.25 sometime soon, since there have been a
few bug fixes and added features, but probably not for a few more
weeks because I've got to finish up a few other projects before I can
get back to liblo.  If you submit a patch I might be able to get
something like this into 0.25.   Hopefully we can come to a consensus
on the list first about whether or not it's a good idea.


Steve

Hi all,

In the documentation of the liblo function  
lo_server_thread_add_method(), it describes the typespec coercion  
policy as, "Incoming messages with similar typespecs (e.g. ones with  
numerical types in the same position) will be coerced to the typespec  
given here."

I'm teaching a course this quarter here at UCSB, and frankly, we're  
confused as to when this would ever be a good idea. Are there OSC  
clients that send the same messages with varying typespecs and want  
the server to coerce them to the same handler? We've developed a set  
of OSC tests and benchmarks, and this is a deal-breaker for us Ii.e.,  
we want to test the overhead of "ffffffff" vs "iiiiiiii" in the same  
server.

We stumbled across this because we have an OSC client running on an  
iPhone that sends the message "/event" with typespecs "iiiiii" and  
'iiiiif" for 2 completely different controllers; it took me a whole  
afternoon to determine that it wasn't a bug in my code!

Has anyone ever made this coercion be a run-time switch, or at least a  
conditional compilation flag?

Should we add it as a conditional compilation flag in the 0.24  
sources, or is 0.25 coming soon?

...any reply appreciated...

stp

--
    Stephen Travis Pope  --  Santa Barbara, California, USA
    http://HeavenEverywhere.com     http://FASTLabInc.com
  
  

Hello all,

As part of a course I teach here, we also wrote minimal OSC send/dum  
programs using liblo.
The source is attached.

stp