I have looked at this thread, trying to figure out the best place to
interject my experience last November, and figure that this last will
work as good as any place...
Last November I was in a hospital bed trying to get Meetecho to work.
Between the challenges of the hospital firewall rules for patients,
being out of data on my cellular wifi account and on slow mode, besides
pecking left-handed, I did not get in.
I would have been happy with an audio feed, the slides, and jabber. But
probably jabber would not work through the hospital firewall either.
Realtime, interactive web apps like the etherpad probably would have
been miserable on that hospital wifi. At simple web form that shows the
conversation up to now and the ability to add some to the conversation
in a RESTFUL mode (hint, hint).
We have become so use to big bandwidths and lots of data in the pipe
(see the energy saving thread here) that we have forgotten those that
want to connect with bad connectivity.
In my case, it was probably better that I went to sleep rather than
connect in when the hospital expected me to be asleep. But still...
Perhaps remote participation instructions for those with low bandwidth
or unruly firewalls would be important to add.
Bob
As a totally side note about RESTFUL, I recently tried to explain to one
youth what I did back in '83 on the American Motors (AMC) Honeywell
mainframe with DMIV-TP online transaction processor and CODASYL database
backend, and realize that I created a RESTFUL environment (actually
forced in on the programmers) back then. Each screenful was a separate
event and there was 'cookie' support through hidden fields on the
screen. All code was fully reenterent, with no carry-over state. This
was very unusual approach back then. Considerable resistance from the
programmers.
Couching things in web terms understandable to today's youth almost made
it a ho-hum talk. ;)
On 8/8/19 4:32 PM, Brian E Carpenter wrote:
On 08-Aug-19 21:36, Meetecho IETF support wrote:
Il 07/08/19 02:00, Brian E Carpenter ha scritto:
On 07-Aug-19 11:37, Linda Dunbar wrote:
Pete,
Thanks for the pointer.
There are so many very easy messaging Apps, Slack, Wire, etc. why it is mandatary to have Jabber?
Besides, remote people who want to post questions should register with the Remote Participation, and can raise their hands if they want to ask questions (i.e. posting their questions to the Etherpad).
If there are no remote participants, can WG go on without Jabber scriber?
Jabber is integrated with Meetecho, so I don't think we can drop it unless...
Remote people can also access Etherpad. It is kind of nice to have questions captured in the Etherpad.
....Etherpad could also in some way be integrated with Meetecho. But I don't see how that would work, whereas instant messaging fits in quite naturally.
Etherpad is already integrated with Meetecho:
http://ietf105.conf.meetecho.com/index.php/Remote_Participation#GUI
Ah, good.
fwiw, my opinion is that a separate instant messaging channel is better for
remote participants; anything useful in the jabber log can be inserted into
the minutes later. It's not as if raw Etherpad generally satisfies the
RFC2418 requirement that "minutes should include the agenda for the session,
an account of the discussion including any decisions made..." without
some manual editing.
Brian
(BTW, I've found Jabber very reliable using Gajim on Windows, with an account @jabber.org. But apart from IETF weeks, very few people seem to use it now.)
Brian
.
