[Standards-JIG] proto-JEP: SVG Whiteboarding

[Boyd Fletcher]

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

> On 8/24/06, Boyd Fletcher <boyd.fletcher at je.jfcom.mil> wrote:
>> On 8/24/06 8:02 AM, "Joonas Govenius" <joonas.govenius at gmail.com> wrote:
>>> 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.
> 
> You can, just implement your own server component that acts as
> "realying entity". I.e. all wb elements sent to it are forwarded to
> all other participants.

we have implemented a Jive Wildfire component and it seems to work well. But
I still haven't heard of a good why not to make it work like MUC which has
proven itself to be quite good over the years.

> 
>>> 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).
> 
> So if not SVG 1.2, then why not something like this:
> 
> <customroot>
>     <svg>
>         <circle/>
>     </svg>
>     <svg>
>         <rect/>
>     </svg>
> </customroot>
> 
> That would still be a single XML document.
> 

I'm not sure most SVG engines would handle that well. We think it is cleaner
to treat the pages a separate docs.

>>> 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.
> 
> You can implement  those on the transport method level, in your server
> component.
> 

but it  needs to be part of the specification just like it is with MUC.
Whiteboard collaboration without access control is not very useful in the
corporate world.


> In any case, the negotiation process and error conditions was
> something I spent less time on so improvements are welcome.
> 
>> The Mats sync protocol
>> stuff is not needed for a server component.
> 
> I agree that this is perhaps a bit of an overkill for situations where
> there is a server. However, if you remove the version system you need
> to replace it with some kind of undos that are sent by the server. In
> any case, since Mats' sync protocol is anyway needed for 1-to-1
> sessions, I think it's simpler to use it in all cases.
> 

we still do versioning, but the server does must of the work as it should.

Have ya'll actually implemented Mats protocol and tried with dozens of
current users  to see if really works and what the impacts on performance
and network utilization are?


>>> 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....
> 
> See my previous answers.

?