►
From YouTube: ROS WebTools Working Group (2021-07-30)
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
B
A
A
C
A
B
A
Maybe
I
meant
the
build
system,
kinda
accounts
for
it,
and
then
we,
you
know
we're
maintaining
github
actions
that
people
can
plug
into
their
repositories
to
do
builds,
and
so
the
majority
of
our
conversations
in
here
have
been
about
rosbag
and
about
those
github
actions.
That's
what
we're
actually
maintaining,
which
kind
of
fall
on
two
sides
of
this
boundary
and
I've
wondered
if
maybe
we
do
need
a
developer
tools
working
group,
but
I
don't
know
if
there's
anybody
looking
at
those
things
super
actively
right
now
at
all.
A
A
A
A
A
Live
but
we
could
also,
we
could
talk
about
those
things
here.
I
just
I
guess
my
point
was
I
don't
know
if
we
have
much
expertise
in
here,
but
it's
probably
an
okay
spot
for
the
conversation,
and
maybe,
if
you
notify
discourse
ahead
of
time
that
we're
going
to
talk
about
that,
then
we
could
get
some
people
who
are
more
familiar
with
this
code
base
in
here.
Talking
about
it
like
I,
don't
have
any
particular
thoughts.
I
was
just
sort
of.
A
C
A
A
C
So
I've
got
some
very
extremely
rough
prototypes
in
these
two
branches.
Here
on
my
fork,
the
first
one
is
converting
the
reader
class
into
a
a
multiple
bag
reader
and
the
second
one
is
similar.
It's
it's
sort
of
taking
the
separate
aggregator
approach,
but
I
also
did
some
work
to
define
interfaces
separate
from
the
base
reader
interface
for
different
aspects
of
reading.
C
A
C
Yeah
yeah,
I
mean
I,
I
hadn't
had
another
solution
for
this.
That
was
the
hack
to
get
it
to
compile.
Basically,
there's
problems
like
that
in
it,
the
other
diff
is
much
more
complex.
It
doesn't
have
any
of
the
actual
functionality
in
it
yet
because
I
need
to
refactor
that
from
the
first
diff
into
it,
but
it
does
have.
If
you
look
into
reader
interfaces,
you'll
see
a
bunch
of
headers
there's
one
for
the
base
reader
interface.
C
So
I
said
I
decided
that
a
base
reader
is
basically
an
object
that
can
read
from
a
bag
file.
So
it
has,
has
next
read
next
and
get
all
topics
and
types.
So
those
are
the
three
fundamental
aspects
of
three
fundamental
methods
of
a
reader.
I
decided
every
reader
has
to
be
able
to
do
those
others,
it's
not
a
reader.
If
I
can't
do
them
from
that.
There's
an
interface
for
filtered
bags,
filtered
readers
where
you
can
have
a
couple
of
functions
for
setting
filter
and
resetting
filter,
there's
an
interface
for
metadata.
C
A
C
Is
gonna
be
basically
the
same
as
the
changes
to
the
reader
class
than
the
other
diff,
so
I'm
I'm
more
interested
in
the
interfaces
here.
What
this
is
what
the
objects
are
like,
what
the
inheritance
tree
is
going
to
look
like,
and
if
you
look
at
the
sequential
reader,
you
can
see
what
the
inheritance
is
going
to
look
like.
So
this
is
inheriting
the
base
reader
interface
because
it
needs
to
be
it
needs
to
be
a
base
reader.
C
A
C
C
C
Sorry,
it's
very
late.
I
understand
yeah
any
confusive
runtime
tight
identification,
so
the
merge
the
merged
reader
you
see
doesn't
take.
It
doesn't
have,
for
example,
the
the
metadata
reader
interface,
because
that
doesn't
make
much
sense
for
a
merged
reader,
because
it's
metadata
for
a
single
bag.
C
For
example,
it
doesn't
have
the
filtered
reader
interface,
but
it
does
have
the
base
re.
The
base
functions
of
a
reader
in
terms
of
has
next
redneck
schedule,
topics
and
types,
and
because
because
these
are
both
face
readers,
you
can
use
them
interchangeably
for
reading
from
bags,
but
the
the
sequential
reader
sequential
reader
is
capable
of
having
filters
set
and
metadata
read
from
it.
C
A
A
A
C
C
C
A
A
C
Gone
from
there,
the
aggregate
reader
won't
support,
get
metadata
or
the
set
filter,
reset
filter
and
get
implementation
handle
okay.
So
I
get
implementation
handler
will
be
fine
because
it
would
return
the
aggregate
reader,
which
is
okay,
because
there's
only
one
aggregate
reader
but
the
filter
to
filter
methods
and
get
metadata,
wouldn't
work.
A
C
C
A
A
A
B
C
B
C
A
A
It
it
might
very
well
be
yes,
which
is
another
part
of
why
it's
maybe
better,
to
find
a
an
alternative
to
deleting
this.
I
I
mean
I'm
wondering
if
it's
necessary,
like
I,
maybe,
instead
of
the
full
drastic
change
of
deleting
it.
Maybe
all
we
really
need,
let's
see
so
we're
in
the
reader
again
next
has
next.
A
If
we
modified
those
two
which
would
which
make
less
sense,
given
the
possibility
of
reading
multiple
bags,
we
don't
have
to
delete
this
interface.
Most
of
the
testing
infrastructure
doesn't
have
to
change
the
core
api
stays
the
same,
but
we've
just
removed
two
of
the
functions
within
it.
I
feel
like
that's
how.
A
A
B
A
A
Yes
think
that,
like
these,
these
ones
at
the
end
here
are
the
ones
that
are
easy
to
aggregate
between
multiple.
If
effects
this
one,
you
could
just
list
all
of
the
relative
file
paths
from
all
of
the
bags,
but
the
ordering
is
maybe
weird
it
might
not
have
meaning
given
that,
but
maybe
it's
okay
in
that
case,
so
I'm
just
gonna,
say
medium
and
then
yeah.
We
got
easy
medium
and
these
ones
are
really
specific
to
a
single
bag.
A
But
we
could
set
them
to
some
null
value,
you
could
possibly
say
like
equals,
I
don't
know
an
a
or
unknown
and
then
the
output
bag
will
have
a
single
or,
if
you're,
writing
to
a
bag.
As
part
of
this
feature,
you
would
have
a
single
identifier
that
would
go
into
the
metadata
for
the
output,
but
the
input
would
have.
Oh,
you
could
even
just
say
I
don't
know
mixed
and
have
that
be
a
special
case.
I
guess
for
all
of
these.
B
A
C
A
A
C
A
Forget
metadata-
and
I
was
taking
a
look
at
the
metadata
here
where
some
of
this
is
really
easy
to
aggregate
this
relative
file
paths.
We
can
just
give
them
a
list
of
all
of
the
file
paths
between
things
yeah
and
then
we
could
possibly
for
these
ones
just
have
a
value.
That's
not
meaningful!
That
is
a
placeholder.
B
A
C
A
You've
got
multiple
bags,
but
it
could
yeah
just
be
a
placeholder
value
there.
The
the
one
yeah
even
then
set
filter
reset
filter.
These
could
be
global
overrides,
which
then
you
just
have
to
be
careful
to
you
know
not
even
be
careful.
Just
don't
call
that
if
you
want
to
have
separate
filters
on
the
different
writers
that
you've
configured.
A
A
You
would
have
to
deconstruct
and
reconstruct
the
object
to
replay
that
individual
bag
when,
when
we're
looping,
for
example,
yeah
and
right
now
that
wouldn't
be
possible,
be
within
this
or
within
the
player.
I
guess
because,
as
we
call
open
at
the
end
of
the
loop
or
close
at
the
end
of
the
loop
and
then
let's
see,
could.
A
B
B
A
A
B
C
C
A
A
C
C
A
A
So
I
think
that's
fine
as
an
approach.
You
know
you
reopen,
in
which
case
you
know
this.
This
reader
facade
could
just
have
reopen.
No
clothes
has
next
read.
Next,
get
metadata,
get
topics
and
types,
I
think
even
the
set
filter's
fine
as
a
you
know,
as
a
first
step.
If
we
want
to
reconsider
it,
that's
okay
like
it
would.
C
A
C
C
A
B
A
A
And
then
I
have
a
member
of
my
team
who
has
been
in
this
meeting
before
but
isn't
here
today.
Sonia
is
working
on
the
the
seek
api
for
storage
implementations
and
I
think
she
has
an
implementation
working,
but
it
still
needs
testing
so
we'll.
I
think
see
that
next
week,
okay
as
a
review
and
that
should
be
really
useful
as
a
new
api
for
storage.
B
A
Yeah,
I
think
we
can
go.
I
I
I
think
I'd
like
to
make
progress.
We
could
merge
with
what
you've
got
if
it
works,
and
then
we
can
replace
it
once
we
have
something
to
replace
that
that
portion
of
the
logic
with
and
then
I'm
working
on
right
now
the
sleep
for
so
I'm
working
on
sim
simulated
time
use
sim
time.
So
this
is.
A
So
I'm
glad
we're
making
that
progress.
I
think
we
will
have
that.
You
know
long
before
the
humble
release
and
we
can
have
some
testing
on
it
and
have
that
feature
set
fully
functional
and
then
another
thing
that's
going
on
that
I
wanted
to
bring
up,
is
in
the
middleware
working
group
meeting
on
wednesday
morning
or
on
wednesday.
Whatever
time
zone
you're
in,
we
talked
about
being
able
to
get
message-
definitions
on
the
wire
for
for
us
too,
and
here
we
want
to
use
those
to
store
them
in
the
bags.
A
A
A
I
think
we
need
to
maybe
prototype
both
approaches
and
see
which
one
works
better
yeah.
I
don't
really
know
because
right
now,
yeah,
the
x
types
will
give
you
the
idl
information,
which
is
a
it's
a
direct
mapping
from
the
dot
message
to
idl.
But
I
don't
know
if
you
can
reverse
that
transformation,
it
might
be
lossy.
So
so
that
might
not
be
good
enough,
but
maybe
it
is
I'm
not
sure.
C
A
Possibly
we
could
do
if
it's
easier.
We
could
do
a
an
implementation
that
only
supports
dds
based
implementations
and
that
would
at
least
be
helpful
for
a
lot
of
users,
but
I
agree:
it'd
be
nicer
to
get
the
dot
message.
Definition,
we
might
be
able
to
pass
that
as
user
data
on
the
discovery
traffic
yeah
it
just.
B
A
Investigation
anybody
who's
interested,
I'm
gonna,
start
a
thread
on
the
web
tools.
Working
group
mailing
list
about
it
and
adrian
had
asked
you
sent
me
an
email,
and
I
forgot
to
respond
to
it
yesterday
whether
there
was
a
mailing
list
for
this
working
group
and
I
haven't
set
open
up
properly
all
right,
we
hadn't
really
needed
it,
or
at
least
maybe
we
did
need
it
and
we
just
didn't.
B
C
A
B
C
A
Right
now,
okay,
right
now,
it's
only
it's
only
set
to
invite
ross
to
working
groups.
So
let
me
add
this
new
guest
and
then
save
for
this
and
following
events,
okay
and
send,
I
think
that
should
solve
the
problem.
Okay,
if
that
was
the
thing
adrian,
then
I
think
you're
solved
now
you
should
have
gotten
a
new
invite
to
the
ross.
Tooling
working
group
invites
one.
C
A
B
A
A
A
It
will
coordinate
on
there
and
anybody
who's
on
this
call
who
wants
to
get
involved?
Maybe
I
don't
know
probably
joining
that
mailing
list
is
overkill,
but
let
me
know,
and
then
we
can
start
a
side
thread
or
something
or
I
can
include
you
just
on
that
thread
other
than
that.
Is
there
anything
that
we
should
talk
about
before
we
get
going?
Are
there
any
major
feature?
Sets
that
we're
not
discussing
right
now,
we've
got
this
portion
is
talking
about
the
advanced
playback
api
we've
got.
A
A
I
think
that
there's
a
conversation
to
be
had
about
compatibility
like
forward
compatibility
of
ros
bags
figuring
out
a
way
to
ensure
that
bags
we
write
in
say
humble-
are
playable
in
foxy,
which
was
a
feature
of
ross
one
that
I've
been
informed
was
useful
for
people.
I
I
personally
didn't
have
that
experience,
because
I
was
mostly
using
internal
bags,
but
I'm
not
sure
how
to
ensure
that,
but
that's
something
maybe
we
can
just
have
on
our
minds
at
the
moment.
I
think
we
have
enough
other
things
going
on
to
pay
attention
to.
B
A
Basically,
it
covers
some
number
of
the
definitions
of
conversion,
but
not
necessarily
all
of
them.
So
I
think
we
need
to
be
more
more
precise
in
that
issue.
Maybe
we
want
to
close
it
and
reopen
multiple
slightly
more
directed
issues,
because
what
this
it's
part
of
work
that
will,
let
us
do
splitting
storage
format,
changing
merging
compression
format,
changing
yeah,
it's
basically
the.
A
A
A
B
A
C
C
A
A
A
A
A
A
C
C
A
I
would
very
much
appreciate
it
if
you
could
add
doc
strings
to
all
apis
that
you
create
at
least
all
the
the
public
ones.
I'm
gonna
start
running
the
the
documentation
tool
on
rosbeg2
and
see
where
we're
missing
documentation.
Definitely
some
of
the
interfaces
are
are
very
underdocumented,
which
makes
it
unclear
why
they
exist
or
what
how
exactly
they're
meant
to
be
used.
A
B
I
mentioned
I
I
would
like
to
raise.
Maybe
a
question:
can
we
maybe
somehow
agree
to
what
style
to
use
when
documenting,
like
c
or
c
style,
using
the
oxygen
documents
documentation?
Because
I
see
a
proposal
with,
I
would
promote
proposal
to
uc
plus
for
new
descriptions
for
new
files.
If
it's
not
documented,
if
it's
already
a
lot
of
documentation
happened
in
c
style
to
preserve
the
c
style.
But
if
it's
entirely,
you.
B
B
Yeah,
it's
very
undesirable
to
have
it
really
because
it's
it's
it's
better
to
to
sustain
and
support.
Cpas
plaster
is
much
easier,
but
if
your
file
readies
have
this
most
of
them
just
keep
it
in
this
file.
But
if
it's
completely,
you
try
to
use
c
plus
class
really
what
is
the
c
plus
plus
style?
It's
just
three
backslashes.
B
B
B
A
B
B
B
By
the
way,
if
anybody
use
client,
if
you
will
just
type
three
slashes
and
enter
it,
will
actually
pop
up
snippet
for
this
comment
automatically,
you
don't
need
to
write
even
brief
details,
so
it
will
return.
It
will
automatically
insert
all
this
stuff
boilerplate
stuff
great,
it's
easy,
just
three
slashes
and
enter.