[Standards-JIG] proto-JEP: SVG Whiteboarding

[Bishop, Michael W. CONTR J9C880]

Some comments on the JEP:

 

Configure (4.6.1):  I read this as an "update" to an element.  When we
perform updates, we always send the entire element and simply replace or
fully update the element if it exists.

 

Attribute (4.6.3):  The "attribute" section lacks the ability to specify
a namespace on the changes.  How can you "unset" or remove an attribute?

 

History   (4.3.4):  How does this work?  It's obvious for the entire

document, but how does it work for partial documents?  Does the end user
receive a cumulative set of actions (creates/updates/deletes)?  If not,
how does the user request a partial history?  If I ask for elements 5
through 7 and someone updated element 3, I won't have the latest version
of the document.  How do I know which elements I need the latest
"version" of?

 

Changing the Stacking Order of the Elements (4.5.2):  We've used a more
fine-grained approach.  To rearrange an element's place in the tree, we
use a combination of "beforeId", "afterId", and "parentId".  If
"beforeId" is specified and "afterId" is not, the element must be the
first element in a group before the element with the given "beforeId".

If "afterId" is specified and "beforeId" is not, the element must be the
last element in a group after the given "afterId".  If both "afterId"

and "beforeId" are specified, the element must become the only element
between the two elements with the specified IDs.  If "parentId" is
specified, the element becomes the first child of that parent.  These
rules help with potential synchronization issues.

 

Hope some of that is helpful and makes sense.

 

Michael Bishop

 

 

-----Original Message-----

From: Fletcher, Boyd C. GS-13 J9935

Sent: Thursday, August 24, 2006 9:54 AM

To: Jabber protocol discussion list; Matt Tucker; Lirette, Keith J.

CONTR J9C618; Bishop, Michael W. CONTR J9C880

Subject: Re: [Standards-JIG] proto-JEP: SVG Whiteboarding

 

 

 

 

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.

>>>> 

>>> 

>> 

>> 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/standards/attachments/20060824/c5448632/attachment.htm