[Standards-JIG] Fwd: proto-JEP: SVG Whiteboarding

[Peter Saint-Andre]

Joonas Govenius wrote:
> Oops, I sent this to Mats only when I meant to send it to the list...
> 
> ---------- Forwarded message ----------
> From: Joonas Govenius <joonas.govenius at gmail.com>
> Date: Aug 26, 2006 7:31 PM
> Subject: Re: proto-JEP: SVG Whiteboarding
> To: Mats Bengtsson <matben at privat.utfors.se>
> 
> 
> Thanks for the comments Mats.
> 
> On 8/26/06, Mats Bengtsson <matben at privat.utfors.se> wrote:
>>
>> My comments to Joonas whiteboarding JEP version 0.0.1.
>>
>> First, I think there is a fundamental difference between whiteboarding
>> in general, and this JEP in particular, from most (all?) other JEP
>> protocols
>> due to the sync issue which is nontrivial.
>>
>> There are two essential parts to such a protocol, the actual protocol
>> description, which Joonas has provided, and the theoretical basis for
>> solving the sync issue. I know that you guys are less interested in the
>> theoretical part, but without a solid basis with proofs of all
>> assumptions, we wont have an acceptable protocol.

Maybe Mats can write up his sync document as an informational JEP?


>> Specific comments:
>>
>> 4.2: I really don't see the need for a session attribute. We already
>> have this
>> notion; normal messages are just sent off as complete xml, for chat
>> messages we have the thread attribute which serves this purpose, and
>> for groupchat each room JID specifies a session.
> 
> I think session identifier of some kind is necessary so that the
> number of sessions between two parties is not limited to one. Whether
> it's the <thread/> in the <message> or a session attribute in the
> <wb/> doesn't make a whole lot of difference to me.

Yes that seems important.

>> 4.3: If the initiation shall be used at all it should be placed as
>> a separate protocol (JEP) which handles invitiations generically and
>> not specifically for whiteboarding.
> 
> Some kind of initiation is certainly needed in order to get the
> "state" of the whiteboard to the user wanting to join. This is the
> major difference to regular chats whose functioning is not dependent
> on previous messages in the same way.
> 
> The details of this delivery process brings up the question of the
> value of masterless whiteboarding session (i.e. without a custom
> server component). This is something I would really like to hear some
> opinions on. I know that Boyd is against requiring support for them
> but what about others. What is the value, if any, of having sessions
> without serverside support?

IMHO we need to be able to support both masterless and masterful (?) modes.

>> I'm not so happy about using negotiotions
>> at all since we don't use them for ordinary chats or normal messages.
>> And groupchats we enter by free will. Perhaps the features could
>> instead be obtained by discoing the user. I think it is better for a
>> client
>> to just accept any whiteboarding without any feature constraints and
>> then have resonable fallbacks for things it doesn't understand.
>> This is how the web works. Instead there is a great risk that we end
>> up in a combinatorical explosion where a client must satisfy a lot
>> of constraints for a whiteboard session be possible. I suggest one
>> single protocol with client fallbacks.
> 
> I can see the value of this and I certainly agree that something like
> disco or entity capabilities should be used to find out the supported
> features if that's possible. At the same time, I can see the
> usefulness of recommending which features are used in some particular
> session. E.g. a client can support some proprietary extension like
> embedded sound clips and advertise that through disco but it can still
> have "standard sessions" as long as it knows that it's not supposed to
> send out those sound clip elements in that particular session.
> 
>> 4.4+4.5: Here is where the theory kicks in. Theory is perhaps best kept
>> as separate documents from the JEP, but must nevertheless be placed
>> in some more "formal" place than my memos are.
> 
> I agree that a separate JEP would be the best place for theory that's
> not necessary for implementation.

+1

>> If anyone have read my sync memo I have a fundamental assumption that all
>> element edits are independent of each other. This assumption is broken
>> in two cases as far as I can see:
>>
>>   1) The stacking (display) order is all relative which makes any edits
>>      that affect this dependent.
>>   2) Grouping of elements since this is relative to a group element.
>>
>> Case 1 can be given a solution if instead of a relative stacking order
>> and order in absolute terms is kept, which the stacking order then must
>> reflect. This is where the index attribute comes in.
>>
>> Just as a sidenote: even the creation of new elements is not an
>> independent
>> operation, surprisingly, since new elements must be placed somewhere in
>> the xml tree which makes element creation like raise and lower edits,
>> a dependent operation.
>>
>> Having an absolute z-scale (the index attribute serves like one) all
>> raise/lower/new operations are all commutative which is very nice.
>> If they were not it would be necessary to impose a locking mechanism for
>> the complete document, and have a document history in addition to the
>> element history we have now to solve the sync issue. That would be
>> extremely
>> messy.
>> Perhaps I should eleborate on these ideas in a separate memo.
>>
>> Joonas likes this z-scale because the Qt widget has methods for it.
> 
> That's certainly not the primary reason why I like it though it's a
> nice benefit :) IMHO, it's simply the most flexible and elegant
> situation and doesn't require any master to decide the correct order.
> 
> BTW, calling it 'index' was probably a mistake from me as it seems to
> get confused with the term index used for the ordinal number
> representing the position of the element (as in 1st, 2nd, 3rd).
> Perhaps just 'z' would be better.

And brief. :-)

>> However, keeping separate structures for one and the same thing is
>> error prone as all programmers know. I'd like to see some alternative
>> methods fail before I accept it fully.
> 
> Of course other suggestions are welcome but I  think I'm personally
> too happy with this to be able to come up with a different solution
> right now.
> 
>>
>> 4.5.1: "The value of the 'id' attribute MUST be of the form
>> "m/JID/resource""
>> I'd like to keep the attributes as syntax free as possible and have
>> a separate id attribute.
> 
> I think this is the case already, The 'id' attribute that the sentence
> refers to is not the 'id' attribute of the SVG namespace but of the
> whiteboarding namespace. At the moment it's done like this <new id='x'
> index='y'><path .../></new> but I think it'd probably be better to do
> this <new><path wb:id='x' wb:index='y' .../></new>.
> 
> As for the format of the id, the proposed format was my idea for
> making sure they are unique in the session. However, I chatted with
> Boyd and Michael yesterday and agreed that using GUIDs (Globally
> Unique Identifiers) makes sense.

What's the algorithm for creating these?

>> 4.6.1+2+3: Joonas likes the idea of having a single tag for everything,
>> like 'configure'. We have discussed this extensively and come up with
>> many
>> alternative solutions which can be discussed. Most bandwidth generated
>> the
>> 'move' tag versus <configure transform='translate(30,20)'/>.
>> Perhaps a balance between his view and the "one tag for each thing" view.
>> Also, alternative syntax for configure is
>> <configure attrname='value' attrname='value' .../> which makes the xml
>> schema
>> more difficult to define but is perfectly acceptable.
> 
> Like we've discussed before with Mats, it'd probably be a good idea to
> get some "XML expert opinions" on the different alternatives for
> syntax.

I'm no XML expert, but I'll take a look.

>> One last thing: <wb xmlns='http://jabber.org/protocol/svgwb' is suggested
>> but isn't our Jabber custom using x-tags here?
> 
> Remko suggested that I use <wb/> instead of <x/> in the very beginning
> of the summer but I don't feel strongly one way or the other...

There is no hard convention of <x/>, that was just an early community
usage that we've mostly discarded now.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20060828/83b24f7b/smime.bin