[Standards-JIG] proto-JEP: SVG Whiteboarding

[Boyd Fletcher]

On 8/24/06 8:02 AM, "Joonas Govenius" <joonas.govenius at gmail.com> wrote:

> Hi Boyd,
> 
> I don't see your requirements as conflicting with the proposed JEP,
> rather they are complementary. An idea I kept in mind when thinking of
> the protocol was that it should be self-contained in a way that the
> <wb/> elements can be delivered using any method, which satisfies the
> "seriality" condition (i.e. any two clients receive elements _not_
> sent by them in the same order). Hence a specialized server component
> could function as the JID to relay the messages just as well as a MUC
> component can.
> 
> This whiteboarding server component could also take care of the three
> other issues with MUC based whiteboarding:
> 1. implement a more reasonable karma scheme from whiteboard usage perspective
> 2. Keep and deliver the necessary history of the whiteboard to new
> users joining the session. This could be easily done by intercepting
> the <connect-request/> elements.
> 3. keeping the history would also allow persisting sessions
> 
> As for permissions, I think that's also the job of the underlying
> transport method, e.g. the MUC room. Each user just needs to be aware
> whether they have voice in the session; perhaps an additional <voice
> enabled='0/1' />, sent by the "target JID", is necesary for non MUC
> based sessions.

we felt that it would better to make the Whiteboarding protocol
self-sufficient just like MUC is. That we who could have a whiteboarding
session without text chat/MUC.


> 
> As for pages and layers and such, I don't see what the problem is with
> implementing these as part of the XML document, though you would
> obviously have to use some other profile that SVG 1.1 Tiny. At the
> moment there is an implicit expectation that the root element is
> <svg/> though but that could, and probably should, be changed.

layers are not support in SVG 1.1 or less. 1.2 isn't official yet.
Pages are not in SVG at all.

We are treating pages as separate SVG documents. The layer create we are
advocating basically uses <g> elements internally but it formalizes the that
the <g> are layers (i.e. it adds some extended attributes to SVG to mark
certain <g> tags as a layer).

> 
> As for embedding images and all other binary data in the whiteboard, I
> think encoding them in base64 is reasonable so they can also be part
> of the XML document just as all other content in the whiteboard, e.g:
> 

agree. basically use a modified version of IBB.

> <image x="0" y="0" xlink:href="data:image/png;base64,[data]"
> xmlns:xlink="http://www.w3.org/1999/xlink"/>
> 
> The ability to request for a certain item to be visualized (e.g. a
> page) should probably be added to this JEP. I just didn't have time
> time to do this yet.
> 
> I think the beauty of this "transport independent" approach is that if
> a client supports this JEP, it makes _very_ little difference to it
> whether the session it participates in is 1-to-1, MUC or specialized
> server component based.
> 

I still needs security and robust error handling. The Mats sync protocol
stuff is not needed for a server component.

> One controversial question may be what profiles or features we
> recommend should be supported. However, I think it might make sense to
> specify these in a separate JEP. I described a simple way for the
> initiator of the session to decide what features will be used in the
> session but perhaps someone can come up with a better way of doing it.

We think minimum compliance should be SVG 1.1 Tiny with the addition of
layers and pages.

> 
> In fact, it might make sense to remove all references to whiteboarding
> from this JEP and refer to an XML document instead and describe how
> this protocol could be used for whiteboarding in another JEP. You
> could then use this protocol to modify an XML document describing a
> chess game for example ;)
> 

we disagree. Whiteboarding needs things beyond that of a straight XML
document like layers, pages, GOTO pages, robust whiteboard specific error
handling, speaker control, etc....


> As for submitting this JEP, Peter recomended that a 0.0.1 of the JEP
> be published now so I agreed. It makes sense to me too since it
> shouldn't stop it from being modified and it makes the process more
> public.


we want to submit ours as well.


> 
> Joonas
> 
> On 8/24/06, Boyd Fletcher <boyd.fletcher at je.jfcom.mil> wrote:
>> Our version is also designed to handle both one-to-one users and scale up to
>> 1000+ users in a single session. And yes there are lots of government and
>> commercial users of whiteboarding systems that frequently hit 1000+ users in
>> a single session. Albeit, they are usually using the whiteboard as the basis
>> of a presentation system when they get too very high numbers  - but any user
>> can raise their hand to request write access to the whiteboard.
>> 
>> Joonas' well written JEP seems to us to focus on small group collaboration
>> and if combined with ours could potentially meet most users requirements.
>> 
>> We feel that in order for SVG whiteboarding to really be a success in the
>> XMPP world and be able to really replace T.120 and the large number of
>> proprietary whiteboarding systems, the JEP needs to support the following
>> modes:
>> 
>> 1) One-to-One mode
>> 2) Small Group chat mode  (< 25 persons) in Free-4-All type of editing
>> 3) Presentation mode when one person is driving the whiteboard (including
>> page changes) to a very large audience. The audience can watch and if they
>> raise their hand can be granted permission to modify the whiteboard
>> 4) auditorium mode - basically presentation mode except with 25-50 people
>> are on a "virtual stage" in a free-4-all session while a large audience
>> participates. Participants (those watching the presentation or virtual
>> discussion) can raise his/her hand and request permission to change the
>> whiteboard. Granting of raise hand permission is accomplished by the use of
>> a dynamic role change.
>> 
>> 
>> It also important to be able to support the following capabilities:
>> 
>> 1) multiple concurrent whiteboards in a client
>> 2) a strong permission structure similar to MUC except with the addition of
>> a new affliation (speaker) and role (presenter)
>> 3) pages & layers
>> 4) embedded images as IBB or URL (with a refresh interval)
>> 5) ability to request that users change to a specified page (useful in
>> presentation modes).
>> 
>> boyd
>> 
>> 
>> 
>> On 8/23/06 10:57 PM, "Boyd Fletcher" <boyd.fletcher at je.jfcom.mil> wrote:
>> 
>>> I think there is still considerable disagreement in the community on what
>>> the right approach is. Perhaps it should be withdrawn and formal committee
>>> created to draft a combined whiteboarding specification. We sent a draft of
>>> ours to Peter last week.
>>> 
>>> We are currently rewriting our whiteboard JEP to be based on a model similar
>>> to MUC. It has a robust permissions capability, multiple layer and page
>>> support, and the ability to use whiteboards as a presentation mechanism.
>>> 
>>> boyd
>>> 
>>> 
>>> 
>>> On 8/23/06 4:45 PM, "JEP Editor" <editor at jabber.org> wrote:
>>> 
>>>> The JEP Editor has received a proposal for a new JEP.
>>>> 
>>>> Title: SVG Whiteboarding
>>>> 
>>>> Abstract: This JEP defines a protocol that allows clients to share a common
>>>> whiteboard.
>>>> 
>>>> URL: http://www.jabber.org/jeps/inbox/wb.html
>>>> 
>>>> The Jabber Council will decide within 7 days (or at its next meeting)
>>>> whether
>>>> to accept this proposal as an official JEP.
>>>> 
>>> 
>> 
>>