No subject

Fri Feb 11 05:14:17 PST 2011

would be set. But since that is draft we can change that so that it makes <BR>
more sense.<BR>
&gt; <BR>
&gt; &gt; ofdT.Channel.Interfaces.Securable.EncryptionState(u)=0 {PROPOSED}<BR>
&gt; <BR>
&gt; Moved from the Encryptable proposal, presumably?<BR>
Yes and this may be better than the other methods above.<BR>
&gt; <BR>
&gt; &gt; ofdT.Channel.Interfaces.Securable.AuthenticationChannel(o)=ofdT.Channel.Interface.OTRAuthentication {PROPOSED}<BR>
&gt; <BR>
&gt; I assume you mean &quot;the object path of a channel implementing<BR>
&gt; OTRAuthentication&quot;?<BR>
Yes, how would I properly show that for the spec?<BR>
&gt; <BR>
&gt; For generic E2E support, this would in fact have to be the object path of<BR>
&gt; a channel implementing both ofdT.Channel.Type.PeerAuthentication and the<BR>
&gt; interface mentioned in the EncryptionInterface property (which would<BR>
&gt; be either OTR or XTLS to start with).<BR>
OK, thank you, but how should it look?<BR>
&gt; <BR>
&gt; &gt; Please note: I am recommending that ofdT.Channel.Interfaces.Encryptable<BR>
&gt; &gt; {DRAFT} be renamed, or that some of the properties and methods be moved<BR>
&gt; &gt; to ofdT.Channel.Interfaces.Securable as DRAFT properties.<BR>
&gt; <BR>
&gt; Encryptable should indeed be called Securable - I made that change while<BR>
&gt; adding a partial version of it to the spec. For E2E support, you'll probably<BR>
&gt; need the rest of the interface.<BR>
I agree and I like what you had added so far, just hoping to enhance it further.<BR>
&gt; <BR>
&gt; The DRAFT thing only works at a per-interface granularity, so the way to do<BR>
&gt; this would be to have something like this:<BR>
&gt; <BR>
&gt; ofdT.Channel.Interface.Securable (stable)<BR>
&gt; ofdT.Channel.Interface.Securable.DRAFT (not stable)<BR>
&gt; <BR>
&gt; and move properties from the draft to the stable one as they become stable.<BR>
OK I appreciate that insight and will make sure I type it correctly in the spec.<BR>
&gt; <BR>
&gt; &gt; 1. git://; My git branch for Spec, re-based with Origin.<BR>
&gt; <BR>
&gt; For those following along at home, the web interface for that branch is<BR>
&gt; &lt;<A HREF=""></A>&gt;. Some quick notes about that:<BR>
&gt; <BR>
&gt; Your commits that say &quot;Re-basing the file forward&quot; seem to have lost their<BR>
&gt; original commit messages? Commit messages should briefly describe what changed<BR>
&gt; (first line) and why (subsequent lines, after an empty line). Browse<BR>
&gt; through the git history to see how they work in practice.<BR>
I fixed much of this by not rebasing.<BR>
&gt; <BR>
&gt; You seem to have committed the conflict marker lines (starting with &lt;&lt;&lt;&lt;&lt;&lt;&lt;,<BR>
&gt; =======, &gt;&gt;&gt;&gt;&gt;&gt;&gt;), which isn't how they're meant to work (and will break<BR>
&gt; processing of the XML). When you get conflict markers, it means that changes<BR>
&gt; made in one commit conflicted with changes from another commit, and git<BR>
&gt; couldn't work out what the desired result is. The intention is that you work<BR>
&gt; out how to merge the two sets of changes (&quot;resolve the conflict&quot;), delete<BR>
&gt; the conflict markers and commit the result.<BR>
&gt; <BR>
&gt; For instance, if a commit from you and a commit from Cosimo both added some<BR>
&gt; text, the right conflict resolution might be to add both bits of text - unless<BR>
&gt; your text and Cosimo's text contradict each other or are redundant, in which<BR>
&gt; case you might choose one and delete the other.<BR>
OK I understand a little better, but as you have seen GIT is not my strong suite,<BR>
perhaps in the future I will get better with GIT.<BR>
&gt; <BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; S<BR>
-----------Next is the second Email from Sjoerd----------------<BR>
&gt; On Mon, 2011-01-03 at 11:48 +0000, Simon McVittie wrote:<BR>
&gt; &gt; On Wed, 22 Dec 2010 at 03:11:19 +0430, WolfRage wrote:<BR>
&gt; &gt; &gt; My purpose here is to patch this bug #296867 (Launch Pad) which is bug<BR>
&gt; &gt; &gt; #16891 on the Free Desktop Bugzilla.<BR>
&gt; &gt; <BR>
&gt; &gt; FWIW, Telepathy's official bug tracking is via, so we generally<BR>
&gt; &gt; consider fd.o bug numbers to be the important one; Launchpad bugs are<BR>
&gt; &gt; specific to Ubuntu (or other projects hosted on Launchpad, which we're not).<BR>
&gt; &gt; <BR>
&gt; &gt; We usually do this sort of discussion on a fd.o bug report so it's easier to<BR>
&gt; &gt; find (mailing list archives split by month aren't very useful for long-running<BR>
&gt; &gt; projects). If you don't mind, I'll direct subsequent discussion to the<BR>
&gt; &gt; relevant bugs - anyone who's interested in following it can add themselves to<BR>
&gt; &gt; the bugs' Cc lists.<BR>
&gt; &gt; <BR>
&gt; <BR>
&gt; Yeah, but people don't. I'd really prefer it if we used the mailing-list<BR>
&gt; to get at least a rough consensus and afterward have the details worked<BR>
&gt; out on bugreport. Mailinglists really have a much higher visibility for<BR>
&gt; people so are easier to take part in for the casual observers that don't<BR>
&gt; want to subscribe to lots of bugs :)<BR>
Hopefully posting in both areas will suffice and will not bloat the bug too much. <BR>
&gt; <BR>
&gt; -- <BR>
&gt; Sjoerd Simons &lt;<A HREF="mailto:sjoerd.simons at">sjoerd.simons at</A>&gt;<BR>
&gt; Collabora Ltd.<BR>
In closing, I will be updating cosimoc's spec and will post that to my <BR>
GIT in the coming days, and we will change it as we go. Because <BR>
I have enough of a start that I should begin putting it all into writing.<BR>
Looking forward to all replies and thank you all for your help. <BR>
-- <BR>
- -<BR>
Quote: &quot;Opportunities multiply as they are seized.&quot; &quot;Can you imagine what I would do if I could do all I can?&quot; Sun Tzu, The Art of War. <BR>


More information about the telepathy mailing list