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