SPAM regression testing

I'd like to report that I have been working on some of the spam 
processing issues discussed in 
http://wiki.mozilla.org/Thunderbird:SummerOfCode2006:SPAM

Right now, I have the ability to read in the TREC 2005 Spam corpus, and 
process it through the TB junk mail processing. This is done using a TB 
extension. Soon though I'll need to customize the C++ code so that I can 
get to the junkscore, which I will need to develop ROC curves for the 
filter.

In the short run, the main issues I am interested in implementing are 
token pruning, and improved tokenization. Regression testing is a key 
piece of any attempt to improve the spam filtering.
0
Kent
12/13/2007 7:32:04 PM
mozilla.dev.apps.thunderbird 3464 articles. 0 followers. Post Follow

89 Replies
1459 Views

Similar Articles

[PageSpeed] 2

Kent James wrote:
> 2) It really takes dedicated effort in TB to train routinely on ham, 
> but really the main value of a local spam filter is the 
> characterization of ham. Junk is common over many users, but each 
> person has their own unique ham signature. Some methods need to be 
> developed to automatically do this. Maybe, for example, we could 
> consider each message ham that the user replies to.
I like that. I'd also suggest that senders to whom one replies should 
probably be special-cased in the addressbook as well.  They're likely to 
be special.  It might even make sense to consider some whitelisting hints.
> 3) There are now multiple text characterization schemes (starred, 
> junk/nonjunk, tags) that could be unified into a single system, with 
> possible benefits such as expanding Bayesian analysis to determination 
> of tags for example (to say nothing of much-needed refactoring).
Agreed.
> 4) As I mentioned on another list, centralized reporting of spam from 
> TB users would go a long way toward improving spam filter performance. 
> Recent work such as http://www.ceas.cc/2007/papers/paper-74.pdf show 
> how important that is. Local Bayes analysis is only going to be able 
> to effectively reject about 90% of spam (plus or minus 5%). To get to 
> the 99.5% rejection that we really need, requires interactions with 
> other users.
Where was that other list?  I'd love to brainstorm about ways that 
MailCo/Mozilla could facilitate such a collaborative system.

--david

0
David
12/13/2007 10:01:48 PM
Kent James wrote:
>
> David Ascher wrote:
>> Where was that other list?  I'd love to brainstorm about ways that 
>> MailCo/Mozilla could facilitate such a collaborative system.
>>
>> --david
>>
> I was referring to this thread:
>
> https://labs.mozilla.com/forum/index.php/topic,334.0.html
Ah, right.  Yes, I haven't been hanging out on the forums enough.

I've just posted a followup on that thread, FYI.
> Anything that you could do to build some community brainstorming would 
> be welcome. I've never really figured out how to do that productively 
> in the TB environment. It really is sorely needed.
I'm hoping to find the time and mental space to start organizing some of 
the wiki pages to facilitate just that.  I find wikis tend to elicit 
slightly less negative energy than discussion lists/fora, and they 
"remember" better. At the same time, it's hard to build energy in a wiki.

I know, we should build a new communication/collaboration tool =).  
Kidding aside: I'm slightly jealous of people who get to use tools like 
Campfire, which has the interactivity of IRC, but also more 
institutional memory and better usability for non-simultaneous users.  
If anyone knows of technology which could help bring those things to 
IRC, let me know.

In the short term, however, I'm happy to use a combined approach of some 
wiki pages, and an associated IRC channel that didn't get in the way of 
either the support discussions on #thunderbird or the very pragmatic 
stuff going on in #maildev.

--david

0
David
12/13/2007 11:33:44 PM
David Ascher wrote:
> In the short term, however, I'm happy to use a combined approach of some 
> wiki pages, and an associated IRC channel that didn't get in the way of 
> either the support discussions on #thunderbird or the very pragmatic 
> stuff going on in #maildev.
Well, once something interesting gets going, I guess that this list will 
not remain that "pragmatic"...maybe somebody has to start putting some 
fire (speak positive energy) into this place? Just my two cents...

-- 
Regards 
 
Signer:  	Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber:  	startcom@startcom.org <xmpp:startcom@startcom.org>
Blog:  	Join the Revolution! <http://blog.startcom.org>
Phone:  	+1.213.341.0390
 

0
Eddy
12/13/2007 11:41:21 PM
David Ascher wrote:
> I find wikis tend to elicit 
> slightly less negative energy than discussion lists/fora, and they 
> "remember" better. At the same time, it's hard to build energy in a wiki.
>  
> --david
> 

If I look at the wiki page 
http://wiki.mozilla.org/Thunderbird:2.0_Product_Planning there are lots 
of discussion comments there. But it is still just a long list of 
features that people would want added, and not really any kind of firm 
discussion of what will or will not be done. In that since, it 
duplicates bugzilla. As you say, no energy. Also, I can't easily tell 
who is making what comment. Authority of the poster matters a lot in 
public places.

Really right now there are too many places to discuss things, not too 
few. We have David Ascher's blog comments, new Mozilla lab forums, 
bugzilla, mozilla wikis, mozillazine forums, and perhaps other that I am 
not aware of (there must be some irc channel as well). Even you (David) 
are not reliably monitoring the forums that you yourself setup for the 
purpose of discussing Thunderbird!

For the discussions to work, it is important that the movers and shakers 
are clearly present and participating in the discussions. I find this 
forum (mozilla.dev.apps.thunderbird) to be the most reliable place where 
names of people that I recognize as active will routine participate. Why 
not just start here? I guess I'm seconding Eddy Nigg's posting. Let's 
inject some positive energy into this forum.

rkentjames
0
Kent
12/14/2007 12:22:49 AM
Eddy Nigg (StartCom Ltd.) wrote:
> David Ascher wrote:
>> In the short term, however, I'm happy to use a combined approach of some 
>> wiki pages, and an associated IRC channel that didn't get in the way of 
>> either the support discussions on #thunderbird or the very pragmatic 
>> stuff going on in #maildev.
> Well, once something interesting gets going, I guess that this list 
> will not remain that "pragmatic"...maybe somebody has to start putting 
> some fire (speak positive energy) into this place? Just my two cents...

This place here feels more quiet than pragmatic =).

Message received, though.  I haven't spammed this newsgroup because I do 
feel like a recent immigrant, and I'm learning the local customs. 

I'll throw ideas here, see what happens to them.

--david
0
David
12/14/2007 12:24:29 AM
David Ascher keyboarded, On 12/13/2007 6:33 PM :
> Kent James wrote:
>>
>> David Ascher wrote:
>>> Where was that other list?  I'd love to brainstorm about ways that 
>>> MailCo/Mozilla could facilitate such a collaborative system.
>>>
>>> --david
>>>
>> I was referring to this thread:
>>
>> https://labs.mozilla.com/forum/index.php/topic,334.0.html
> Ah, right.  Yes, I haven't been hanging out on the forums enough.
>
> I've just posted a followup on that thread, FYI.
>> Anything that you could do to build some community brainstorming 
>> would be welcome. I've never really figured out how to do that 
>> productively in the TB environment. It really is sorely needed.
> I'm hoping to find the time and mental space to start organizing some 
> of the wiki pages to facilitate just that.  I find wikis tend to 
> elicit slightly less negative energy than discussion lists/fora, and 
> they "remember" better. At the same time, it's hard to build energy in 
> a wiki.
>
> I know, we should build a new communication/collaboration tool =).  
> Kidding aside: I'm slightly jealous of people who get to use tools 
> like Campfire, which has the interactivity of IRC, but also more 
> institutional memory and better usability for non-simultaneous users.  
> If anyone knows of technology which could help bring those things to 
> IRC, let me know.
>
> In the short term, however, I'm happy to use a combined approach of 
> some wiki pages, and an associated IRC channel that didn't get in the 
> way of either the support discussions on #thunderbird or the very 
> pragmatic stuff going on in #maildev.
>
> --david
>

David, For an add-in to Fx and Tb for IM/Chat there is Same Place that 
uses the Jabber/XMPP protocols.  Permits cut & paste of content like a 
white board and there is an option for remote annotation.  No idea what 
Campfire is, so can not draw a contrast.

Wiki is nice for being a collaborative editing medium with persistence 
bordering on permanence.  A Wiki is clearly deliberative and a bit 
intimidating.  Obviously not free wheeling like NNTP, where I prefer a 
server with a 14 day retention and no propagation to Google Groups. I 
view group brainstorming to be a group conversation that should stay 
within the circle of subscribed participants. I do not want my ideas 
being harvested from an archive by an outsider.

I have a dislike for Web Forum sites.  They are slow, and lack tight 
threading and ease of branch visualizing which I like about news. I have 
used Mozillazine Forums, mostly when that was the only official site for 
reporting Tb bugs, before Bugzilla use was authorized to receive reports 
from Tb alpha testers.

Personally I see no reason why MailCo should not set up its own NNTP and 
XMPP IM/Chat servers.

-- 
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported BSOD use by Major Error to msg the enemy!
0
Ron
12/14/2007 12:38:10 AM
Kent James keyboarded, On 12/13/2007 7:22 PM :
> David Ascher wrote:
>> I find wikis tend to elicit slightly less negative energy than 
>> discussion lists/fora, and they "remember" better. At the same time, 
>> it's hard to build energy in a wiki.
>>  
>> --david
>>
>
> If I look at the wiki page 
> http://wiki.mozilla.org/Thunderbird:2.0_Product_Planning there are 
> lots of discussion comments there. But it is still just a long list of 
> features that people would want added, and not really any kind of firm 
> discussion of what will or will not be done. In that since, it 
> duplicates bugzilla. As you say, no energy. Also, I can't easily tell 
> who is making what comment. Authority of the poster matters a lot in 
> public places.
>
> Really right now there are too many places to discuss things, not too 
> few. We have David Ascher's blog comments, new Mozilla lab forums, 
> bugzilla, mozilla wikis, mozillazine forums, and perhaps other that I 
> am not aware of (there must be some irc channel as well). Even you 
> (David) are not reliably monitoring the forums that you yourself setup 
> for the purpose of discussing Thunderbird!
>
> For the discussions to work, it is important that the movers and 
> shakers are clearly present and participating in the discussions. I 
> find this forum (mozilla.dev.apps.thunderbird) to be the most reliable 
> place where names of people that I recognize as active will routine 
> participate. Why not just start here? I guess I'm seconding Eddy 
> Nigg's posting. Let's inject some positive energy into this forum.
>
> rkentjames

Yes, we are fragmented in part because I view the Tb community has been 
forced to adapt to the Firefox business model.  Having worked with Eddy 
on a report in August, I am familiar with his enthusiasm. My 
recommendation to David A. is to say "These are the places we will do 
business" because I feel MailCo needs to flesh out it's identity and 
community. I pointed out to David that Same Place is a Jabber IM/IRC 
solution that has presence so we can see at a glance who is busy, away, 
or available. It is both Fx and Tb 2.0+ compatible. Nit is it lacks 
persistance.

-- 
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported BSOD use by Major Error to msg the enemy!
0
Ron
12/14/2007 12:50:29 AM
Ron K. wrote:
> 
> David, For an add-in to Fx and Tb for IM/Chat there is Same Place that 
> uses the Jabber/XMPP protocols.  Permits cut & paste of content like a 
> white board and there is an option for remote annotation.  No idea what 
> Campfire is, so can not draw a contrast.
> 

That brings up a question I have had for a long time. Is there any 
process or philosophy by which add-ins get incorporated into the main 
code? Philosophies like, "we want the minimum base program, with most 
new features as add-ins" Or, "we want a full-featured product, and will 
merge quality add-ins into the trunk."

What I might propose as a compromise is that TB agree on certain add-ins 
that will be fully supported (translated, kept updated). As part of TB 
installation, the user would select which to include. That would provide 
a compromise between bloat and feature set.

Kent
0
Kent
12/14/2007 12:50:43 AM
David Ascher keyboarded, On 12/13/2007 7:24 PM :
> Eddy Nigg (StartCom Ltd.) wrote:
>> David Ascher wrote:
>>> In the short term, however, I'm happy to use a combined approach of 
>>> some wiki pages, and an associated IRC channel that didn't get in 
>>> the way of either the support discussions on #thunderbird or the 
>>> very pragmatic stuff going on in #maildev.
>> Well, once something interesting gets going, I guess that this list 
>> will not remain that "pragmatic"...maybe somebody has to start 
>> putting some fire (speak positive energy) into this place? Just my 
>> two cents...
>
> This place here feels more quiet than pragmatic =).
>
> Message received, though.  I haven't spammed this newsgroup because I 
> do feel like a recent immigrant, and I'm learning the local customs.
> I'll throw ideas here, see what happens to them.
>
> --david


One thing I like is to hear from my leadership once in a while.  Builds 
moral and community. Actually I am hoping MailCo could set some of it's 
own customs. We work in a different culture where direct 
person-to-person communication is the name of the game.

-- 
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported BSOD use by Major Error to msg the enemy!
0
Ron
12/14/2007 12:56:59 AM
Kent James wrote:
> Really right now there are too many places to discuss things, not too 
> few. We have David Ascher's blog comments, new Mozilla lab forums, 
> bugzilla, mozilla wikis, mozillazine forums, and perhaps other that I am 
> not aware of (there must be some irc channel as well). Even you (David) 
> are not reliably monitoring the forums that you yourself setup for the 
> purpose of discussing Thunderbird!
>   

Guilty as charged.  Working on fixing it, but yes.

> For the discussions to work, it is important that the movers and shakers 
> are clearly present and participating in the discussions. I find this 
> forum (mozilla.dev.apps.thunderbird) to be the most reliable place where 
> names of people that I recognize as active will routine participate. Why 
> not just start here? I guess I'm seconding Eddy Nigg's posting. Let's 
> inject some positive energy into this forum.
>   

I'll try to start with a topic I was just discussing on IM which 
hopefully isn't going to start a flamewar, as soon as I get a caveat out:

** I'm not setting direction here -- I'm just speaking as a thunderbird 
user who would like to foster creative discussions.  In particular, if 
anything I say in this mode shows up in a blog as "mailco mover and 
shaker thinks blah blah blah", I'll be frustrated =). **

I find the RSS UI in Thunderbird just painful enough that it stops me 
everytime I want to switch to it from Shrook, which is my current RSS 
reader of choice.  So I've been thinking about what it could become.

There are some "obvious" problems, which I suspect are in bugzilla 
already, like:
  - can't actually use TB as a feed subcriber from Firefox. 
  - can't drag and drop URLs into the News & Blogs container to have 
them added
  - no auto-discovery of feeds from web page URIs
  - some bugs w/ import of hierarchical OPML files (can't recall details)
  - in the add dialog, there's a folder per feed, which certainly 
confused me at first.

But all of those are important, but catch-up.  Let's maybe talk a bit 
about how we could take it beyond the current system.  Here are some 
thoughts:

 1) There are lots of RSS readers out there, and lots of blog authoring 
software, but very few integrated solutions.  Thunderbird has the 
capability of being both a blog reader and an authoring system in one.  
In particular, we could explore ways of integrating a commenting UI in 
the communications client. I'm not familiar with the state of commenting 
APIs in Atom Publishing, but someone must be =)

 2) If we're thinking of reviewing the marking of messages 
(starred/junk/tags/priority/etc.) as you mentioned, let's think about 
tagging of folders and feeds as well.  One of the things I liked about 
Shrook is that it has a clean UI for creating dynamic folders based on 
tags, giving one the hierarchical power of folders, with the overlapping 
data set of tags.  I wouldnt' be surprised if that stuff was possible in 
TB from an architectural POV, with some (probably significant) UI work.

3) I'd like to explore ways that we can learn from and correct some of 
the weaknesses that Thunderbird inherits because it's a desktop app. In 
particular, I find it frustrating that some state is held server-side, 
and some is held client-side, even when using stateful serverside 
systems like IMAP.  I'd love to talk more about what the right 
evolutionary path of Nick Kreeger's work should be.  In the world of RSS 
readers for example, OPML is used for data import/export, but it seems 
too little -- it specifies what feeds I subscribe to, but not what 
messages I've read, or which ones I think are important.  It's also not 
geared towards synchronization.  Would it make sense to think about what 
protocol should be used to synchronize client state across channels, so 
that there could be a "thunderbird metadata server" which would hold all 
appropriate data, from "bookmarked" rss items to address book data, etc?

-david




0
David
12/14/2007 1:02:15 AM
Kent James keyboarded, On 12/13/2007 7:50 PM :
> Ron K. wrote:
>>
>> David, For an add-in to Fx and Tb for IM/Chat there is Same Place 
>> that uses the Jabber/XMPP protocols.  Permits cut & paste of content 
>> like a white board and there is an option for remote annotation.  No 
>> idea what Campfire is, so can not draw a contrast.
>>
>
> That brings up a question I have had for a long time. Is there any 
> process or philosophy by which add-ins get incorporated into the main 
> code? Philosophies like, "we want the minimum base program, with most 
> new features as add-ins" Or, "we want a full-featured product, and 
> will merge quality add-ins into the trunk."
>
> What I might propose as a compromise is that TB agree on certain 
> add-ins that will be fully supported (translated, kept updated). As 
> part of TB installation, the user would select which to include. That 
> would provide a compromise between bloat and feature set.
>
> Kent

 From the early 0.1alpha days my understanding was that Tb would be as 
light weight as possable core, mail/news application relying on 
extensions to provide features on an as needed basis.  Some extension 
code has been incorporated over time when there features were seen as 
more core than user customization.  I like that philosophy. I think a 
good suite of API interfaces, that permit plug-in and add-on expansion, 
will aid keeping pace with new related technologies.

My understanding is that extension/add-on projects are third party 
driven.  A user with expertise has an idea and builds something for 
personal use and then offers it to the global user base. Has some 
weakesses, like the Dev is snowed under and postpones updating his 
project.  One that comes to mind is Newsworthy which is still needed 
with Tb 2.0 but is capped at 1.5 and lacks a needed update. However I 
believe that add-on is one that needs to be rolled into Tb is the 
functionality was not added to the Tb 3 future.  So here is a case for 
your argument for MailCo to adopt an orphaned add-on if leadership views 
it as in the community's interest.

-- 
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported BSOD use by Major Error to msg the enemy!
0
Ron
12/14/2007 1:22:04 AM
David Ascher wrote:
> Kent James wrote:
>> Anything that you could do to build some community brainstorming would 
>> be welcome. I've never really figured out how to do that productively 
>> in the TB environment. It really is sorely needed.
> I'm hoping to find the time and mental space to start organizing some of 
> the wiki pages to facilitate just that.  I find wikis tend to elicit 
> slightly less negative energy than discussion lists/fora, and they 
> "remember" better. At the same time, it's hard to build energy in a wiki.
> 
> I know, we should build a new communication/collaboration tool =).  
> Kidding aside: I'm slightly jealous of people who get to use tools like 
> Campfire, which has the interactivity of IRC, but also more 
> institutional memory and better usability for non-simultaneous users.  
> If anyone knows of technology which could help bring those things to 
> IRC, let me know.
> 
> In the short term, however, I'm happy to use a combined approach of some 
> wiki pages, and an associated IRC channel that didn't get in the way of 
> either the support discussions on #thunderbird or the very pragmatic 
> stuff going on in #maildev.
> 
> --david
> 

My opinion on the various means of discussion:

Wiki: Ideal for information /a posteriori/; notification of updates is 
haphazard and clumsy at best, impossible at worst, so a good 
communication via this means wouldn't work very well.

Web forum: Once again, update notification is problematic. The best 
place for these are for those who are more wary of other means for 
communication (i.e., newsgroups, IRC).

IRC: Update notification is easy--but there is poor-to-nonexistent 
archival ability, and being on all the time is necessary. Difficult to 
have discussions, since everyone must be present for it to work, and we 
have some potential time zone problems (I know of at least an 8-zone 
shift...)

Newsgroup: These tend to have the best archival, and work well for 
discussions. All competent newsreaders (i.e., everything not a WITUN) 
show messages in a threaded hierarchy, which makes detailed discussions 
easy to follow. Unfortunately, this method of communication would tend 
to exclude neophytes more than others.

Mailing list: Similar in many respects to newsgroups. The largest 
difference is that they come in the same stream as many other types of 
messages, and require filtering. Also, joining one late makes historical 
information difficult to access. Finally, it is easier to mess up a 
reply (hit "Reply" instead of "Reply to All").

Bugzilla: Update notification is somewhat problematic, but is more 
configurable than the Wiki/Web forum styles. Conversations persist, but 
fragmented discussions can occur and become difficult to merge. Also 
problematic in that searching for specific information easily fails to 
often (try looking for `@page' in the quick search. It doesn't work).

Blogs: Conversation is nuanced in this format, but it is ideal for 
announcements.

With respect to TB, these are my preferences:
* The wiki would be used to inform developers of extensions or as a 
springboard for would-be developers of TB.
* The web forum is a support channel for people who need help with TB.
* IRC has a few channels:
   @ Support, a la web forum
   @ Developer information, like #developers or #maildev
   @ A planning channel for when two people need to have instantaneous 
communication.
* Newsgroup or mailing list (prefers newsgroup): main method of 
communicating planning decisions.
* Bugzilla would be used as it is now, for detailing bugs and 
works-in-progress
* Blogs would be used mostly for announcing decisions, such as 
resolutions on a newsgroup/mailing list debate
* Where to put RFEs? Newsgroup (like mozilla.wishlist), Bugzilla, or Web 
forum? There should be one standard place; ideally, it would be 
cross-referable so that all interested parties would know about them.

With respect to IRC, perhaps we could have a configurable extension that 
could store logs of rooms in a searchable-archive manner.

P.S. The TB dictionary has `unsearchable' but not `searchable'!?
0
Joshua
12/14/2007 1:22:19 AM
Ron K. wrote:
>> This place here feels more quiet than pragmatic =).
>>
>> Message received, though.  I haven't spammed this newsgroup because I 
>> do feel like a recent immigrant, and I'm learning the local customs.
>> I'll throw ideas here, see what happens to them.
To David: Satisfied? You just have to drop a small stone into the right 
waters and it's making waves... ;-)
>
>
> One thing I like is to hear from my leadership once in a while.  Builds 
> moral and community. Actually I am hoping MailCo could set some of it's 
> own customs. We work in a different culture where direct 
> person-to-person communication is the name of the game.
>   
Agreed, so there are different preferred medias for different tasks as 
we all know. Discussions on general issues belong to here (mailing list) 
whereas communication between developers can be very dynamic (IM, phone, 
mailing list or just email). Wiki is good to nail down decisions, plans, 
road maps and other such stuff...and than there are the status meetings 
(usually by phone) and at last but not least bugzilla...

But since you mentioned last August..what me concerns not much happened 
since then. Except if there is somewhere something elsewhere 
maybe....But I'd expect the crowned leader to hang out with the right 
people :-\

....or is Thunderbird a ship sailing without a captain to nowhere? 
Somebody knows? I don't so far....

-- 
Regards 
 
Signer:  	Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber:  	startcom@startcom.org <xmpp:startcom@startcom.org>
Blog:  	Join the Revolution! <http://blog.startcom.org>
Phone:  	+1.213.341.0390
 

0
Eddy
12/14/2007 1:42:28 AM
David Ascher wrote:
> In 
> particular, I find it frustrating that some state is held server-side, 
> and some is held client-side, even when using stateful serverside 
> systems like IMAP.  
Yes, yes and yes! This is a key issue in every respect...
> Would it make sense to think about what 
> protocol should be used to synchronize client state across channels, so 
> that there could be a "thunderbird metadata server" which would hold all 
> appropriate data, from "bookmarked" rss items to address book data, etc?
Absolutely! I'm not sure if there is such a protocol, but I think the 
people from XMPP could help us thinking into the right directions a 
little bit...

-- 
Regards 
 
Signer:  	Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber:  	startcom@startcom.org <xmpp:startcom@startcom.org>
Blog:  	Join the Revolution! <http://blog.startcom.org>
Phone:  	+1.213.341.0390
 

0
Eddy
12/14/2007 1:58:23 AM
Kent James wrote:
> That brings up a question I have had for a long time. Is there any
> process or philosophy by which add-ins get incorporated into the main 
> code? Philosophies like, "we want the minimum base program, with most 
> new features as add-ins" Or, "we want a full-featured product, and will 
> merge quality add-ins into the trunk."
>   
That has to some part been the policy of Mozilla with Firefox. Some 
features which seem to be essential are integrated, others are excellent 
add-ons (and will remain as such). But there certainly needs to be a 
policy, "vision' and road map, which seems to be still lacking...

(By-note: Better heated discussions around these subjects (even 
flame-wars if needed) than just void. Perhaps David and others could 
outline where we are heading with the risk of opposing opinions....which 
in turn could adjust the direction...

-- 
Regards 
 
Signer:  	Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber:  	startcom@startcom.org <xmpp:startcom@startcom.org>
Blog:  	Join the Revolution! <http://blog.startcom.org>
Phone:  	+1.213.341.0390
 

0
Eddy
12/14/2007 2:12:20 AM
Eddy Nigg (StartCom Ltd.) keyboarded, On 12/13/2007 8:58 PM :
> David Ascher wrote:
>> In particular, I find it frustrating that some state is held 
>> server-side, and some is held client-side, even when using stateful 
>> serverside systems like IMAP.  
> Yes, yes and yes! This is a key issue in every respect...
>> Would it make sense to think about what protocol should be used to 
>> synchronize client state across channels, so that there could be a 
>> "thunderbird metadata server" which would hold all appropriate data, 
>> from "bookmarked" rss items to address book data, etc?
> Absolutely! I'm not sure if there is such a protocol, but I think the 
> people from XMPP could help us thinking into the right directions a 
> little bit...
>

Would LDAP or SQL-Lite have the flexibility and adaptability for such a 
task ?  The extensibility of XMPP might be an object model.

-- 
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported BSOD use by Major Error to msg the enemy!
0
Ron
12/14/2007 2:20:11 AM
Ron K. wrote:
> Eddy Nigg (StartCom Ltd.) keyboarded, On 12/13/2007 8:58 PM :
>
> Would LDAP or SQL-Lite have the flexibility and adaptability for such a 
> task ?  The extensibility of XMPP might be an object model.
>
>   
Let me get some advice before answering that one...To be continued...

-- 
Regards 
 
Signer:  	Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber:  	startcom@startcom.org <xmpp:startcom@startcom.org>
Blog:  	Join the Revolution! <http://blog.startcom.org>
Phone:  	+1.213.341.0390
 

0
Eddy
12/14/2007 2:25:26 AM
David Ascher wrote:
> I'll try to start with a topic I was just discussing on IM which 
> hopefully isn't going to start a flamewar, as soon as I get a caveat out:
> 
> ** I'm not setting direction here -- I'm just speaking as a thunderbird 
> user who would like to foster creative discussions.  In particular, if 
> anything I say in this mode shows up in a blog as "mailco mover and 
> shaker thinks blah blah blah", I'll be frustrated =). **

And I almost always talk about everything from a developer's point of 
view, or, sometimes, when I play Devil's Advocate on a topic (mostly in 
relation to a development stance, though).

> I find the RSS UI in Thunderbird just painful enough that it stops me 
> everytime I want to switch to it from Shrook, which is my current RSS 
> reader of choice.  So I've been thinking about what it could become.
> 
> There are some "obvious" problems, which I suspect are in bugzilla 
> already, like:
>  - can't actually use TB as a feed subcriber from Firefox.  - can't drag 
> and drop URLs into the News & Blogs container to have them added

I found this and immediately had the "huh?" reaction.

>  - in the add dialog, there's a folder per feed, which certainly 
> confused me at first.

Yes, the subscribe dialog here is very confusing.

> But all of those are important, but catch-up.  Let's maybe talk a bit 
> about how we could take it beyond the current system.  Here are some 
> thoughts:
> 
> 2) If we're thinking of reviewing the marking of messages 
> (starred/junk/tags/priority/etc.) as you mentioned, let's think about 
> tagging of folders and feeds as well.  One of the things I liked about 
> Shrook is that it has a clean UI for creating dynamic folders based on 
> tags, giving one the hierarchical power of folders, with the overlapping 
> data set of tags.  I wouldnt' be surprised if that stuff was possible in 
> TB from an architectural POV, with some (probably significant) UI work.

The account/folder/element is, IMHO, a mess right now. I tend to prefer 
Outlook's style somewhat, in that it is the folder that has the 
intrinsic type information (e.g., task list, message folder) in some 
cases, and not the account. I am envisioning a pseudo-server that might 
mix a blog feed with a newsgroup and a POP folder; that would certainly 
help organization.

That said, the primary problem, as I see it, is that large parts of code 
are in need of an overhaul in the APIs and cross-object coordination; I 
expect some of that may come through in the near future with my 
implementation of bug 11050, but the account manager is not part of that...
0
Joshua
12/14/2007 2:46:36 AM
Joshua Cranmer wrote:
> The account/folder/element is, IMHO, a mess right now. I tend to prefer 
> Outlook's style somewhat, in that it is the folder that has the 
> intrinsic type information (e.g., task list, message folder) in some 
> cases, and not the account. I am envisioning a pseudo-server that might 
> mix a blog feed with a newsgroup and a POP folder; that would certainly 
> help organization.
>
> That said, the primary problem, as I see it, is that large parts of code 
> are in need of an overhaul in the APIs and cross-object coordination; I 
> expect some of that may come through in the near future with my 
> implementation of bug 11050, but the account manager is not part of that...
>   
I have heard the same comments about the codebase needing overaul.  And 
certainly sometimes refactoring can be done in absence of specific 
features.  Still, it'd be good to know where we're heading. 

For example, I know that some wanted to be able to merge event info and 
mail info, and that right now that's (unsurprisingly) hard.  Figuring 
out what the right data model is is a lot easier if we think about what 
uses we want to allow. 

--david

0
David
12/14/2007 6:00:33 AM
Eddy Nigg (StartCom Ltd.) wrote:
> But since you mentioned last August..what me concerns not much happened
> since then. Except if there is somewhere something elsewhere 
> maybe....But I'd expect the crowned leader to hang out with the right 
> people :-\
>   
> ...or is Thunderbird a ship sailing without a captain to nowhere? 
> Somebody knows? I don't so far....
>   

I can appreciate that people are impatient and want to see a plan in 
place now.  At the same time, I know that a deliberative and 
collaborative process is a lot more likely to build a true community 
with a shared goal than if I just dumped by raw thoughts and declared 
them policy.

So please be patient -- feel free to poke me as often as you need, though.

I'll contribute more on this newsgroup, and we'll see how things evolve.

--david


0
David
12/14/2007 6:39:23 AM
Ron K. wrote:
>  From the early 0.1alpha days my understanding was that Tb would be as 
> light weight as possable core, mail/news application relying on 
> extensions to provide features on an as needed basis.  Some extension 
> code has been incorporated over time when there features were seen as 
> more core than user customization.  I like that philosophy. I think a 
> good suite of API interfaces, that permit plug-in and add-on expansion, 
> will aid keeping pace with new related technologies.
>   

Roughly, I agree.

I phrase the choice of what goes in the product vs. what should be an 
extension slightly differently.  In my mind, the core product should 
provide that magical, subjective, and elusive blend of features which 
provides the best experience for the largest number of people possible.  
Add-ons then provide a wonderful vehicle for providing additional bits 
that either don't provide enough value yet -- for example features that 
aren't quite polished enough yet -- or to enough people -- because 
different people have different needs.

The distinction is important.  In particular, I don't subscribe to the 
notion of Thunderbird being defined as "the most lightweight mail/news 
client possible, with some extensions available".  I think it's more 
complicated and changing than that.

As an example, every interaction I have with "real users" who aren't in 
the inner circles of Thunderbird development get very agitated at the 
lack of any scheduling capability within Thunderbird.  To what feels 
like a _large_ number of people, calendaring functions are much, much 
more important than, say, news reading or RSS integration, or LDAP 
integration.  Which isn't to say that I want to take those features out, 
just that the blend of what features belong in a client like Thunderbird 
is subject to reconsideration as things change -- as technologies 
available change, as adoption of different technologies change, as 
people's habits change.  I also think that we can lead, not just follow 
well established trends.

It would be a shame to look back on Thunderbird in ten years and see a 
piece of software that lost a chance at having huge impact because it 
didn't know how to evolve.  There is _huge_ opportunity for Thunderbird 
to become more than a good mailnews client that a few million people 
use.  I estimate that Thunderbird is used by less than 1% of email users 
-- that's *a lot* given how many resources were dedicated to it!  it's 
also *not enough* given what we could and should do. 

I believe that if we figure out together where we want to go, 
Thunderbird could help change the way lots and lots and LOTS of people 
feel about email, communication, computer work, work in general, social 
interactions, and more.  We won't do that by just being a mail/news 
client.  We need to think of the system in a different way.  We have a 
mindshare and impact because of Mozilla and Firefox's success that we 
should use to our best advantage.  Let's not squander it.

I'm still working on how to express my hopes for Thunderbird, but 
hopefully the above gives a little window into my current thoughts, and 
why I took this job.  I'm keen to refine how I can explain this stuff, 
in particular to this group, because you are the people who will help 
get this thing jump-started.

Feedback welcome!

--david

0
David
12/14/2007 7:02:59 AM
David Ascher wrote:

> I believe that if we figure out together where we want to go, 
> Thunderbird could help change the way lots and lots and LOTS of people 
> feel about email, communication, computer work, work in general, social 
> interactions, and more.  We won't do that by just being a mail/news 
> client.

In my comment on your blog entry at 
http://ascher.ca/blog/2007/10/17/i-just-really-want-to-know-what%e2%80%99s-going-on-with-thunderbird/ 
I suggested that TB focus on a single Big Idea (and suggested some 
possibilities), rather than try to be all things to all people. But that 
would not be an easy path. Your existing users are primarily interested 
in a better email client - scheduling, LDAP, RSS, HTML editing, better 
search, etc, etc. Also, if you spend much time browsing bugzilla you 
will see many bugs that really should have been fixed a long time ago 
that are still out there. So there is a long grind of incremental 
improvement to existing features, along with bug fixes, that is clearly 
the path of least resistance for moving TB forward.

Yet an open source project like TB really needs to attract developers. I 
don't see the long grind as being very attractive. (Though, strangely 
enough, I personally find the esoterica of spam filter token pruning as 
an interesting subject. That clearly is a "long grind" topic.) Somehow 
we need to move forward on the basic improvements that the product 
needs, while at the same time leaving some space to try wild-eyed, 
innovative things (or to at least provide Mozilla-style open leadership 
to things that everyone is talking about, like unified communication or 
open social networks).

What is sorely needed, and perhaps would be well-served by a Wiki, is to 
start to identify and categorize both the wild-eyed and conventional 
topics so that we could perhaps congregate around areas of interest, and 
maybe see what the Thunderbird forest starts to look like. Perhaps it 
would then be clear if there are a few Big Ideas that could develop a 
critical mass of people interested in making them happen.

- Kent





0
Kent
12/14/2007 9:48:55 AM
David Ascher keyboarded, On 12/14/2007 2:02 AM :
> Ron K. wrote:
>>  From the early 0.1alpha days my understanding was that Tb would be 
>> as light weight as possable core, mail/news application relying on 
>> extensions to provide features on an as needed basis.  Some extension 
>> code has been incorporated over time when there features were seen as 
>> more core than user customization.  I like that philosophy. I think a 
>> good suite of API interfaces, that permit plug-in and add-on 
>> expansion, will aid keeping pace with new related technologies.
>>   
>
> Roughly, I agree.
>
> I phrase the choice of what goes in the product vs. what should be an 
> extension slightly differently.  In my mind, the core product should 
> provide that magical, subjective, and elusive blend of features which 
> provides the best experience for the largest number of people 
> possible.  Add-ons then provide a wonderful vehicle for providing 
> additional bits that either don't provide enough value yet -- for 
> example features that aren't quite polished enough yet -- or to enough 
> people -- because different people have different needs.

In my reply to Kent I boiled my perception of the philosophy expressed 
4.5 years ago down to simple statements. At the time Tb was carrying 
some unneeded baggage.  An example was program folder file pathways 
filled with empty nested folders ending with a small overlay file.  That 
had to be causing excessively long path strings in the code. 
Progressively deadwood and unneeded baggage were pruned and Tb became 
lighter thus fulfilling the "as light as possable" concept.  The context 
of my statement of "Features on an as needed basis" is as perceived by 
third parties to bring solutions to special needs.  This includes Stock 
Tickers, Weather Forecast monitors, etc.

> The distinction is important.  In particular, I don't subscribe to the 
> notion of Thunderbird being defined as "the most lightweight mail/news 
> client possible, with some extensions available".  I think it's more 
> complicated and changing than that.

I am very much in agreement with you.

> As an example, every interaction I have with "real users" who aren't 
> in the inner circles of Thunderbird development get very agitated at 
> the lack of any scheduling capability within Thunderbird.  To what 
> feels like a _large_ number of people, calendaring functions are much, 
> much more important than, say, news reading or RSS integration, or 
> LDAP integration.  Which isn't to say that I want to take those 
> features out, just that the blend of what features belong in a client 
> like Thunderbird is subject to reconsideration as things change -- as 
> technologies available change, as adoption of different technologies 
> change, as people's habits change.  I also think that we can lead, not 
> just follow well established trends.

Here we also are thinking in similar ways.  My input to the Road Map 
report, that I understand influenced your decision to accept the MailCo 
job, was how to position Tb to be the best possible hub for a "Personal 
Communications Platform" that could capitalise on emerging technologies. 

> It would be a shame to look back on Thunderbird in ten years and see a 
> piece of software that lost a chance at having huge impact because it 
> didn't know how to evolve.  There is _huge_ opportunity for 
> Thunderbird to become more than a good mailnews client that a few 
> million people use.  I estimate that Thunderbird is used by less than 
> 1% of email users -- that's *a lot* given how many resources were 
> dedicated to it!  it's also *not enough* given what we could and 
> should do.
> I believe that if we figure out together where we want to go, 
> Thunderbird could help change the way lots and lots and LOTS of people 
> feel about email, communication, computer work, work in general, 
> social interactions, and more.  We won't do that by just being a 
> mail/news client.  We need to think of the system in a different way.  
> We have a mindshare and impact because of Mozilla and Firefox's 
> success that we should use to our best advantage.  Let's not squander it.

I have several times referred to the Same Place Jabber/XMPP add in 
bundle,not as a pet add in, but as a currently available technology that 
I see as a good fit for a "Platform Model" seeking to tie users needs 
together. E-mail is a basic element of the platform. An improved RSS UI 
would be useful. Your thoughts on Blog reading and publishing surprised 
me, but your reasoning is sound and I think it should be considered. The 
Lightning add-in will be another important segment of the platform.  The 
Lightning team has two targets, small business and students. Students 
are the market segment I think We want.  They are deeply immersed in 
communication in many ways. My generation, pre-boomer, can be 
overwhelmed by all the technology. I still have not mastered inputing 
phone numbers into my wireless phone. Computers, though, I know we are 
still scratching the surface of what software can do.

> I'm still working on how to express my hopes for Thunderbird, but 
> hopefully the above gives a little window into my current thoughts, 
> and why I took this job.  I'm keen to refine how I can explain this 
> stuff, in particular to this group, because you are the people who 
> will help get this thing jump-started.
>
> Feedback welcome!
>
> --david
>


-- 
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported BSOD use by Major Error to msg the enemy!
0
Ron
12/14/2007 10:05:59 AM
David Ascher wrote:
> I phrase the choice of what goes in the product vs. what should be an 
> extension slightly differently.  In my mind, the core product should 
> provide that magical, subjective, and elusive blend of features which 
> provides the best experience for the largest number of people possible.  
> Add-ons then provide a wonderful vehicle for providing additional bits 
> that either don't provide enough value yet -- for example features that 
> aren't quite polished enough yet -- or to enough people -- because 
> different people have different needs.
>   
That's quite a good definition.
> The distinction is important.  In particular, I don't subscribe to the 
> notion of Thunderbird being defined as "the most lightweight mail/news 
> client possible, with some extensions available".  I think it's more 
> complicated and changing than that.
>   
Agreed.
> As an example, every interaction I have with "real users" who aren't in 
> the inner circles of Thunderbird development get very agitated at the 
> lack of any scheduling capability within Thunderbird.  To what feels 
> like a _large_ number of people, calendaring functions are much, much 
> more important than, say, news reading or RSS integration, or LDAP 
> integration.  
Yes. In addition to that TB could function in addition to that as the 
media center for any communication type. In that respect could be the 
application for managing anything related to scheduling and communication.
> I believe that if we figure out together where we want to go, 
> Thunderbird could help change the way lots and lots and LOTS of people 
> feel about email, communication, computer work, work in general, social 
> interactions, and more.  We won't do that by just being a mail/news 
> client.  We need to think of the system in a different way.  We have a 
> mindshare and impact because of Mozilla and Firefox's success that we 
> should use to our best advantage.  Let's not squander it.
>   
+1
> I'm still working on how to express my hopes for Thunderbird, but 
> hopefully the above gives a little window into my current thoughts, and 
> why I took this job.  I'm keen to refine how I can explain this stuff, 
> in particular to this group, because you are the people who will help 
> get this thing jump-started.
Just confirming your thoughts in this feedback...so far so good ;-)

-- 
Regards 
 
Signer:  	Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber:  	startcom@startcom.org <xmpp:startcom@startcom.org>
Blog:  	Join the Revolution! <http://blog.startcom.org>
Phone:  	+1.213.341.0390
 

0
Eddy
12/14/2007 2:23:01 PM
David Ascher wrote:
> As an example, every interaction I have with "real users" who aren't in 
> the inner circles of Thunderbird development get very agitated at the 
> lack of any scheduling capability within Thunderbird.

Note that people always talk more about what they miss than what they 
already have, so comparing that missing functionality with something we 
have is probably not right.

Anyways, I think it might be a good idea to ease integration of 
Lightning into Thunderbird by providing XUL elements they (or other 
extensions) can easily overlay rather than having them rely on changing 
around our XUL DOM tree for integration.
That makes life easier for the Lightning team so calendering 
functionality can get integrated more smoothly with Thunderbird and 
while we're at it (that's where I originally came from with this idea) 
would also make it easier to have Lightning integrated into SeaMonkey, 
given the suite provides the same integration points. And the SeaMonkey 
team would be just as happy as the Thunderbird team and MailCo to 
improve the Mozilla mail and messaging space, including testing, using 
and improving calendering functionality integrated with it.

Robert Kaiser

0
Robert
12/14/2007 2:53:36 PM
Kent James wrote:
> Really right now there are too many places to discuss things, not too 
> few. 

....

> ...  I find this
> forum (mozilla.dev.apps.thunderbird) to be the most reliable place where 
> names of people that I recognize as active will routine participate.

FWIW, I agree, this is the best forum. It is where I look first for what 
is happening in TB dev. It is archived and searchable. If there are 
compelling arguments to use other forums, that is fine, but lets not 
fragment it too much.

- Brian
0
Brian
12/14/2007 3:21:17 PM
Robert Kaiser wrote:
> David Ascher wrote:
>   
>> As an example, every interaction I have with "real users" who aren't in 
>> the inner circles of Thunderbird development get very agitated at the 
>> lack of any scheduling capability within Thunderbird.
>>     
>
> Note that people always talk more about what they miss than what they 
> already have, so comparing that missing functionality with something we 
> have is probably not right.
>   

Very fair point, Kairo!  Bad logic, david, bad logic.
> Anyways, I think it might be a good idea to ease integration of 
> Lightning into Thunderbird by providing XUL elements they (or other 
> extensions) can easily overlay rather than having them rely on changing 
> around our XUL DOM tree for integration.
> That makes life easier for the Lightning team so calendering 
> functionality can get integrated more smoothly with Thunderbird and 
> while we're at it (that's where I originally came from with this idea) 
> would also make it easier to have Lightning integrated into SeaMonkey, 
> given the suite provides the same integration points. And the SeaMonkey 
> team would be just as happy as the Thunderbird team and MailCo to 
> improve the Mozilla mail and messaging space, including testing, using 
> and improving calendering functionality integrated with it.
>   

Sounds good!

--david

0
David
12/14/2007 4:07:36 PM
This is a cryptographically signed message in MIME format.

--------------ms070607050005000208080009
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Eddy Nigg (StartCom Ltd.) wrote:
> David Ascher wrote:
>> In 
>> particular, I find it frustrating that some state is held server-side, 
>> and some is held client-side, even when using stateful serverside 
>> systems like IMAP.  
> Yes, yes and yes! This is a key issue in every respect...
>> Would it make sense to think about what 
>> protocol should be used to synchronize client state across channels, so 
>> that there could be a "thunderbird metadata server" which would hold all 
>> appropriate data, from "bookmarked" rss items to address book data, etc?
> Absolutely! I'm not sure if there is such a protocol, but I think the 
> people from XMPP could help us thinking into the right directions a 
> little bit...

Well that is definitely not the XMPP "roster" since it includes much
more than just your contacts (the roster is like a Jabber-only contact
list), but we can definitely achieve all that real-time synchronization
over XMPP.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


--------------ms070607050005000208080009
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYQDCC
B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI
EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD
VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0
MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy
YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh
dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy
ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz
eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA
IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O
U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj
eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u
xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud
DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx
tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE
BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0
eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G
CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0
YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp
oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6
Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5
BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y
Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50
ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX
TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z
KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls
YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC
AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl
cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo
dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0
cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw
Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H
yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa
v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0
4STurMCFwLoyx5k1rDHQYTCCCGIwggdKoAMCAQICAwF4qjANBgkqhkiG9w0BAQUFADCBrzEL
MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj
MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t
IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz
dGFydGNvbS5vcmcwHhcNMDcwODIyMjExMzI3WhcNMDgwODIxMjExMzI3WjCBujELMAkGA1UE
BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxGjAYBgNVBAoTEVBl
dGVyIFNhaW50LUFuZHJlMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl
IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0
cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALC1dkqD
gghuvUCkEloRDX50TTJ6Szj1BqtMpYq+An66BwkWfP07uay+jHori77776wk1/Ajk1nTSHX+
JWo+JWwVXYWBX+Zd780bB0FGShYlHGwMhd/pxX9sT4KW3D+r8sIHVbTGdudSweuNdBhqr1iE
cjze75hpywMkk1OQhTkseQxI5owa9M31JOdNEX0Ja6esyhwwtqqTNC86OujXwa2wew8GTRJE
9p2I0B1VCsKuJaPatbIcf9OFiTSODb5vyoq3+lrElh6V6BXKxEfQ4D2HCSY+5UmlKdnltzvN
bqxyaTYQi1YGsFzew7ST3R8P5jrCq2cvRjGrTKVojZXgPZ0CAwEAAaOCBHgwggR0MAwGA1Ud
EwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAd
BgNVHQ4EFgQUl7CU2dS/alOwLIHV/Oc2RkGDYugwgd0GA1UdIwSB1TCB0oAUBKzbJHdTRkaW
XxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxDjAM
BgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFDQSBBdXRo
b3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx
ITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASCATcwggEz
MIIBLwYLKwYBBAGBtTcBAQQwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNv
bS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0ZC4wAwIB
ARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0
aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWlsYWJsZSBh
dCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBbMCygKqAo
hiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDov
L2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2MDcGCCsG
AQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2VyL2NhMDsG
CCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51c2VyLmNh
LmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29tIFRydXN0
ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0LnN0YXJ0
Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5zdGFydGNv
bS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRjb20ub3Jn
MA0GCSqGSIb3DQEBBQUAA4IBAQCdG1L0T4OT1x4X/cKsuHxgijRaZGGiVECcn5+1X7E3H54/
yDkUqWAp6MZ3hZm36pzTYYnl+5M6vldLcqFCVpD7MgH6Kmu+r6pXAjU33k1RIHnkBvQ6KGlR
p0RjfaZW/2MkG07vF2QTLbx6KIhi0pa9Bg9wlqyw+C2g6FYnfmrdJLgGrxUXek8DSZNjZ/AA
75OoutrWkBtdaL2TbFiawdbGuJbSoQLHqLrNhT8f74Oec7ReOmuUTEL8hsFU0sbY/n2e9Wna
1Vzze3nZPbyPiC5F88p88gVLB9mKkOzleYefYiQw8LABz5x1MI+w0bNKNPLviJ/KnHGFEfVL
z1oMHyC3MIIIYjCCB0qgAwIBAgIDAXiqMA0GCSqGSIb3DQEBBQUAMIGvMQswCQYDVQQGEwJJ
TDEPMA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpT
ZWN1cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQ
cmltYXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9y
ZzAeFw0wNzA4MjIyMTEzMjdaFw0wODA4MjEyMTEzMjdaMIG6MQswCQYDVQQGEwJVUzERMA8G
A1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEaMBgGA1UEChMRUGV0ZXIgU2FpbnQt
QW5kcmUxLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRow
GAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBl
dGVyLmltMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsLV2SoOCCG69QKQSWhEN
fnRNMnpLOPUGq0ylir4CfroHCRZ8/Tu5rL6MeiuLvvvvrCTX8COTWdNIdf4laj4lbBVdhYFf
5l3vzRsHQUZKFiUcbAyF3+nFf2xPgpbcP6vywgdVtMZ251LB6410GGqvWIRyPN7vmGnLAyST
U5CFOSx5DEjmjBr0zfUk500RfQlrp6zKHDC2qpM0Lzo66NfBrbB7DwZNEkT2nYjQHVUKwq4l
o9q1shx/04WJNI4Nvm/Kirf6WsSWHpXoFcrER9DgPYcJJj7lSaUp2eW3O81urHJpNhCLVgaw
XN7DtJPdHw/mOsKrZy9GMatMpWiNleA9nQIDAQABo4IEeDCCBHQwDAYDVR0TBAUwAwIBADAL
BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSX
sJTZ1L9qU7AsgdX85zZGQYNi6DCB3QYDVR0jBIHVMIHSgBQErNskd1NGRpZfFwFcfUJHvUgZ
CKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UEBxMFRWls
YXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0eSBEZXAu
MSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8GCSqGSIb3
DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0gBIIBNzCCATMwggEvBgsrBgEE
AYG1NwEBBDCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRl
cm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s
aWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGNTGltaXRl
ZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0
aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9j
ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j
ZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0
Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4MHYwNwYIKwYBBQUHMAGGK2h0
dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3VzZXIvY2EwOwYIKwYBBQUHMAKG
L2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3MzLnVzZXIuY2EuY3J0MBEGCWCG
SAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRDb20gVHJ1c3RlZCBFbWFpbCBD
ZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2Nh
LWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1
My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s
aWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFydGNvbS5vcmcwDQYJKoZIhvcN
AQEFBQADggEBAJ0bUvRPg5PXHhf9wqy4fGCKNFpkYaJUQJyfn7VfsTcfnj/IORSpYCnoxneF
mbfqnNNhieX7kzq+V0tyoUJWkPsyAfoqa76vqlcCNTfeTVEgeeQG9DooaVGnRGN9plb/YyQb
Tu8XZBMtvHooiGLSlr0GD3CWrLD4LaDoVid+at0kuAavFRd6TwNJk2Nn8ADvk6i62taQG11o
vZNsWJrB1sa4ltKhAseous2FPx/vg55ztF46a5RMQvyGwVTSxtj+fZ71adrVXPN7edk9vI+I
LkXzynzyBUsH2YqQ7OV5h59iJDDwsAHPnHUwj7DRs0o08u+In8qccYUR9UvPWgwfILcxggQs
MIIEKAIBATCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMN
U3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAt
BgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZI
hvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjAJBgUrDgMCGgUAoIICSTAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEyMTQxNjQ1MTJaMCMGCSqG
SIb3DQEJBDEWBBSZegPEQH2kcY8e1t5ijaNUG68keDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG
SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG
9w0DAgIBKDCByAYJKwYBBAGCNxAEMYG6MIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMG
SXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlm
aWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWls
IEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAXiqMIHKBgsq
hkiG9w0BCRACCzGBuqCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQG
A1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25p
bmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEw
HwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjANBgkqhkiG9w0BAQEFAASC
AQCkV606lmsIn4wK7OpgU7Nh+DrNXKrc5D6RrAYJkzoyUxlj+sLdPmgpbfoPlHw1vqZXRSkf
xpPekE1VrAxR+MqBALt8g8eJjPE0WIghvL/JMm/SjQcFFo6fWrk9Ce1ouwLimuFnsMpy1xNs
7Y0loJl9H5PMaZfzoWyrloWXNUCEFoCX4XI4epvqYkcZJ7X1gXx4OyNdihKhHq95qrb8uxYd
UhYlTg2DMZgnfZsIAPp4KGu+nids+v5WiZRashDh24ZTUxHmNHM7qDdIcWPpyX1yBSfrZ5MB
yL3vD9OgTiDSw+ryaCJbN8naS8wF2SsQqGEaxE4ns5QatIznJ1dfa6qOAAAAAAAA
--------------ms070607050005000208080009--
0
Peter
12/14/2007 4:45:12 PM
Eddy Nigg (StartCom Ltd.) wrote:
> Agreed, so there are different preferred medias for different tasks as 
> we all know. Discussions on general issues belong to here (mailing list) 
> whereas communication between developers can be very dynamic (IM, phone, 
> mailing list or just email). Wiki is good to nail down decisions, plans, 
> road maps and other such stuff...and than there are the status meetings 
> (usually by phone) and at last but not least bugzilla...

I think you've summed it up well here Eddy. The point I'd like to extend 
is that we should try and be active in getting some of the decisions and 
ideas here onto wiki or something - especially the ones that are 
directional. Otherwise decisions get lost in the archives and its harder 
for folks inside & outside to know what is going on.

Standard8

0
Mark
12/14/2007 7:33:58 PM
Kent James wrote:
> David Ascher wrote:
>
>   
>> I believe that if we figure out together where we want to go, 
>> Thunderbird could help change the way lots and lots and LOTS of people 
>> feel about email, communication, computer work, work in general, social 
>> interactions, and more.  We won't do that by just being a mail/news 
>> client.
>>     
>
> In my comment on your blog entry at 
> http://ascher.ca/blog/2007/10/17/i-just-really-want-to-know-what%e2%80%99s-going-on-with-thunderbird/ 
> I suggested that TB focus on a single Big Idea (and suggested some 
> possibilities), rather than try to be all things to all people. 
Yes, thank.  FWIW, I like your 3 & 4 most of that batch.
> But that 
> would not be an easy path. Your existing users are primarily interested 
> in a better email client - scheduling, LDAP, RSS, HTML editing, better 
> search, etc, etc. Also, if you spend much time browsing bugzilla you 
> will see many bugs that really should have been fixed a long time ago 
> that are still out there. So there is a long grind of incremental 
> improvement to existing features, along with bug fixes, that is clearly 
> the path of least resistance for moving TB forward.
>   

Yup.

> Yet an open source project like TB really needs to attract developers. 
Oh yes.  But I'll tell you this -- it feels like there are a lot of 
people outside the door, peering in the windows, trying to figure out if 
this is a fun party.  I think as soon as we pull out the appetizer trays 
and party games, it'll get crowded -- in a good way.
> I 
> don't see the long grind as being very attractive. (Though, strangely 
> enough, I personally find the esoterica of spam filter token pruning as 
> an interesting subject. That clearly is a "long grind" topic.)
I'm often surprised at what people will do in their free time.  Your 
parenthetical comment is a case in point -- there's a long tail of 
software problems that, if you can figure out how to match interests and 
problems, can get you 90% of the way there.  The paid staff in some ways 
are there to pick up the other 10%.

> Somehow 
> we need to move forward on the basic improvements that the product 
> needs, while at the same time leaving some space to try wild-eyed, 
> innovative things (or to at least provide Mozilla-style open leadership 
> to things that everyone is talking about, like unified communication or 
> open social networks).
>   

Absolutely agreed.

> What is sorely needed, and perhaps would be well-served by a Wiki, is to 
> start to identify and categorize both the wild-eyed and conventional 
> topics so that we could perhaps congregate around areas of interest, and 
> maybe see what the Thunderbird forest starts to look like. Perhaps it 
> would then be clear if there are a few Big Ideas that could develop a 
> critical mass of people interested in making them happen.
>
>   
Let me think on how to structure some of this. 

A related point: One bit of pain that I'm feeling is that I know there 
are lots of great ideas in bugzilla, but it's very hard to extract 
knowledge from that data.  Is it reasonable to consider using a set of 
whiteboard keywords to build queries which we could then link to wiki 
pages, so that we can e.g. keep track of all the bugs & RFEs about 
contact management features, or IM integration features, or ...?  It's 
what I'd have done in my last bugzilla, but it may not be Mozilla-ish 
enough.

It's great to see all this energy in the last 24 hours, btw.  I'm 
feeling rewarded for posting.  Good job to all on providing positive 
reinforcment =).

--david
0
David
12/14/2007 7:51:03 PM
David Ascher wrote:
> Eddy Nigg (StartCom Ltd.) wrote:
>> But since you mentioned last August..what me concerns not much happened
>> since then. Except if there is somewhere something elsewhere 
>> maybe....But I'd expect the crowned leader to hang out with the right 
>> people :-\
>>   ...or is Thunderbird a ship sailing without a captain to nowhere? 
>> Somebody knows? I don't so far....
>>   
> 
> I can appreciate that people are impatient and want to see a plan in 
> place now.  At the same time, I know that a deliberative and 
> collaborative process is a lot more likely to build a true community 
> with a shared goal than if I just dumped by raw thoughts and declared 
> them policy.
> 
> So please be patient -- feel free to poke me as often as you need, though.
> 
> I'll contribute more on this newsgroup, and we'll see how things evolve.
> 
> --david

Lots of good stuff mentioned, but it may be worthwhile to mention that 
the basic function of Thunderbird is to be used to communicate via 
e-mail. There are two ways to communicate; text/plain and HTML. While 
text/plain is working like a charm, the HTML side has been thoroughly 
neglected and is severely handicapped. I would like to suggest humbly 
that Thunderbird should learn how to walk before it is asked to run.

-- 
Gus
0
Gus
12/14/2007 8:17:49 PM
Ron K. wrote:
> Yes, we are fragmented in part because I view the Tb community has been 
> forced to adapt to the Firefox business model.

Do you really mean business model, or just "firefox community ways"?

> Having worked with Eddy 
> on a report in August, I am familiar with his enthusiasm. My 
> recommendation to David A. is to say "These are the places we will do 
> business" because I feel MailCo needs to flesh out it's identity and 
> community.

Agreed.  Part of my job is to figure out where to adapt to existing 
Mozilla-wide structures, where to adapt to existing Thunderbird & 
Mailnews structures, and where to create new ones. 

>  I pointed out to David that Same Place is a Jabber IM/IRC 
> solution that has presence so we can see at a glance who is busy, away, 
> or available. It is both Fx and Tb 2.0+ compatible. Nit is it lacks 
> persistance.
>   

Yup.  Along similar lines, it's too bad that libpurple is GPL, as that 
makes incorporating it into mainline Thunderbird problematic. 

--david

0
David
12/14/2007 8:28:59 PM
David Ascher wrote:
> Kent James wrote:
>> 2) It really takes dedicated effort in TB to train routinely on ham, 
>> but really the main value of a local spam filter is the 
>> characterization of ham. Junk is common over many users, but each 
>> person has their own unique ham signature. Some methods need to be 
>> developed to automatically do this. Maybe, for example, we could 
>> consider each message ham that the user replies to.

> I like that. I'd also suggest that senders to whom one replies should 
> probably be special-cased in the addressbook as well. They're likely to 
> be special. It might even make sense to consider some whitelisting hints.

They're already added to the personal addressbook by default (see the 
composition / addressing prefpane), and I think anything in the personal 
addressbook is in fact already whitelisted.

>> 3) There are now multiple text characterization schemes (starred, 
>> junk/nonjunk, tags) that could be unified into a single system, with 
>> possible benefits such as expanding Bayesian analysis to determination 
>> of tags for example (to say nothing of much-needed refactoring).
> Agreed.

IIRC, Henry Jia of Sun long ago submitted a patch to generalize the 
Bayesian code in some ways.  I think the idea may have been to train it 
to follow the user's general message filing pattern, rather than just 
caring about two ham/spam buckets.  It's been a while, though, so I may 
be misremembering the details.  Searching Bugzilla should turn it up...

Dan

0
Dan
12/14/2007 9:07:04 PM
David Ascher wrote:
>
> Yup.  Along similar lines, it's too bad that libpurple is GPL, as that 
> makes incorporating it into mainline Thunderbird problematic. 
Huuu? Mozilla itself uses a triple license model including GPL, why 
should this be a problem please?

-- 
Regards 
 
Signer:  	Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber:  	startcom@startcom.org <xmpp:startcom@startcom.org>
Blog:  	Join the Revolution! <http://blog.startcom.org>
Phone:  	+1.213.341.0390
 

0
Eddy
12/14/2007 9:11:17 PM
On Dec 14, 2007 4:11 PM, Eddy Nigg (StartCom Ltd.) <eddy_nigg@startcom.org>
wrote:

> David Ascher wrote:
> >
> > Yup.  Along similar lines, it's too bad that libpurple is GPL, as that
> > makes incorporating it into mainline Thunderbird problematic.
> Huuu? Mozilla itself uses a triple license model including GPL, why
> should this be a problem please?
>
Because the GPL is viral and exclusive in its terms.  You can't take GPL
code and incorporate it into closed-source code that you don't release.
Similarly, the GPL license doesn't allow its code to be released merely
under the stricter LGPL.  Mozilla's licensing is permissive, allowing a user
to choose its license.  In other words, in order to incorporate GPL'd code,
the owners would have to agree that the code could be relicensed under
LGPL/MPL, effectively tri-licensing it.  Without this permission, it's not
compatible with the Mozilla tri-license.

Note that this is an asymmetric situation.  Because of the tri-license, GPL
code can incorporate Mozilla code, by electing to use the GPL part of the
tri-license.

At least, that's how I understand it.  But IANAL (yet).

-Joey

See the actual text in the boilerplate license block:
 * Alternatively, the contents of this file may be used under the terms of
 * either the GNU General Public License Version 2 or later (the "GPL"), or
 * the GNU Lesser General Public License Version 2.1 or later (the "LGPL"),
 * in which case the provisions of the GPL or the LGPL are applicable
instead
 * of those above.
0
Joey
12/14/2007 9:23:04 PM
Ron K. wrote:
> Ed
>>> Would it make sense to think about what protocol should be used to 
>>> synchronize client state across channels, so that there could be a 
>>> "thunderbird metadata server" which would hold all appropriate data, 
>>> from "bookmarked" rss items to address book data, etc?
>> Absolutely! I'm not sure if there is such a protocol, but I think the 
>> people from XMPP could help us thinking into the right directions a 
>> little bit...

In the past, there was a protocol called ACAP.  It evolved from the IMSP 
protocol, and I think Cyrus Daboo (one of the CalDAV spec authors) had a 
hand in it.  I'm pretty sure Mulberry Mail supports one or both of these.

<http://ietfreport.isoc.org/idref/draft-newman-acap-imsp-lessons/> is an 
old document that talks about this some.  Neither of these protocols 
achieved super widespread use but a number of partial implementations of 
servers exist.

Out of some of the ideas in ACAP evolved XCAP 
<http://www.jdrosen.net/papers/draft-ietf-simple-xcap-12.txt>, and I 
think there's actually some amount of usage of this in the VOIP 
community, though I haven't really kept up.  Because it's based on HTTP 
and XML, it's fairly "webby", so it might be a good starting point.

> Would LDAP or SQL-Lite have the flexibility and adaptability for such a 
> task ?

In the Netscape 4 timeframe, users had the option of roaming their data 
to either LDAP or HTTP servers, so the former is definitely  definitely 
possible.

Dan








0
Dan
12/14/2007 9:37:31 PM
Joey Minta wrote:
> On Dec 14, 2007 4:11 PM, Eddy Nigg (StartCom Ltd.) <eddy_nigg@startcom.org>
> wrote:
>> Huuu? Mozilla itself uses a triple license model including GPL, why
>> should this be a problem please?
>>
>>     
> Because the GPL is viral and exclusive in its terms.  
Are you sure you aren't mixing up MS share code license with GPL here? :-D
(no flame-war please)
> You can't take GPL
> code and incorporate it into closed-source code that you don't release.
>   
You can take GPL code and use it even in a closed source project. But if 
you release a product (software) based on this code you must share the 
code along with the software. The parent project in question doesn't 
have to make use of your code so...
> Similarly, the GPL license doesn't allow its code to be released merely
> under the stricter LGPL.
Yes, relicensing isn't permitted.
>   Mozilla's licensing is permissive, allowing a user
> to choose its license.  In other words, in order to incorporate GPL'd code,
> the owners would have to agree that the code could be relicensed under
> LGPL/MPL, effectively tri-licensing it.  Without this permission, it's not
> compatible with the Mozilla tri-license.
>   
Yes, this might be correct...and LGPL is a big problem for many GPL 
projects, but one can always ask nevertheless...

-- 
Regards 
 
Signer:  	Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber:  	startcom@startcom.org <xmpp:startcom@startcom.org>
Blog:  	Join the Revolution! <http://blog.startcom.org>
Phone:  	+1.213.341.0390
 

0
Eddy
12/14/2007 9:37:59 PM
I'm sorry I brought up licensing.

The point I was trying to make is that jabber is really interesting, but 
right now the vast majority of users have non-jabber IM accounts.  So 
finding a way to do interop with them would be good.

Hmm.  Crazy idea: could we build a server-side proxy which talked jabber 
to the client and whatever IM protocols to the world?

--david

0
David
12/14/2007 9:47:49 PM
This is a cryptographically signed message in MIME format.

--------------ms000608030706020205000706
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

David Ascher wrote:
> I'm sorry I brought up licensing.
> 
> The point I was trying to make is that jabber is really interesting, but 
> right now the vast majority of users have non-jabber IM accounts.  So 
> finding a way to do interop with them would be good.
> 
> Hmm.  Crazy idea: could we build a server-side proxy which talked jabber 
> to the client and whatever IM protocols to the world?

Yes, we've had those since 1999. We call them "transports".

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


--------------ms000608030706020205000706
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYQDCC
B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI
EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD
VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0
MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy
YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh
dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy
ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz
eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA
IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O
U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj
eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u
xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud
DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx
tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE
BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0
eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G
CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0
YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp
oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6
Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5
BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y
Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50
ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX
TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z
KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls
YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC
AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl
cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo
dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0
cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw
Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H
yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa
v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0
4STurMCFwLoyx5k1rDHQYTCCCGIwggdKoAMCAQICAwF4qjANBgkqhkiG9w0BAQUFADCBrzEL
MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj
MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t
IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz
dGFydGNvbS5vcmcwHhcNMDcwODIyMjExMzI3WhcNMDgwODIxMjExMzI3WjCBujELMAkGA1UE
BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxGjAYBgNVBAoTEVBl
dGVyIFNhaW50LUFuZHJlMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl
IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0
cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALC1dkqD
gghuvUCkEloRDX50TTJ6Szj1BqtMpYq+An66BwkWfP07uay+jHori77776wk1/Ajk1nTSHX+
JWo+JWwVXYWBX+Zd780bB0FGShYlHGwMhd/pxX9sT4KW3D+r8sIHVbTGdudSweuNdBhqr1iE
cjze75hpywMkk1OQhTkseQxI5owa9M31JOdNEX0Ja6esyhwwtqqTNC86OujXwa2wew8GTRJE
9p2I0B1VCsKuJaPatbIcf9OFiTSODb5vyoq3+lrElh6V6BXKxEfQ4D2HCSY+5UmlKdnltzvN
bqxyaTYQi1YGsFzew7ST3R8P5jrCq2cvRjGrTKVojZXgPZ0CAwEAAaOCBHgwggR0MAwGA1Ud
EwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAd
BgNVHQ4EFgQUl7CU2dS/alOwLIHV/Oc2RkGDYugwgd0GA1UdIwSB1TCB0oAUBKzbJHdTRkaW
XxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxDjAM
BgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFDQSBBdXRo
b3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx
ITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASCATcwggEz
MIIBLwYLKwYBBAGBtTcBAQQwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNv
bS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0ZC4wAwIB
ARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0
aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWlsYWJsZSBh
dCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBbMCygKqAo
hiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDov
L2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2MDcGCCsG
AQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2VyL2NhMDsG
CCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51c2VyLmNh
LmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29tIFRydXN0
ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0LnN0YXJ0
Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5zdGFydGNv
bS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRjb20ub3Jn
MA0GCSqGSIb3DQEBBQUAA4IBAQCdG1L0T4OT1x4X/cKsuHxgijRaZGGiVECcn5+1X7E3H54/
yDkUqWAp6MZ3hZm36pzTYYnl+5M6vldLcqFCVpD7MgH6Kmu+r6pXAjU33k1RIHnkBvQ6KGlR
p0RjfaZW/2MkG07vF2QTLbx6KIhi0pa9Bg9wlqyw+C2g6FYnfmrdJLgGrxUXek8DSZNjZ/AA
75OoutrWkBtdaL2TbFiawdbGuJbSoQLHqLrNhT8f74Oec7ReOmuUTEL8hsFU0sbY/n2e9Wna
1Vzze3nZPbyPiC5F88p88gVLB9mKkOzleYefYiQw8LABz5x1MI+w0bNKNPLviJ/KnHGFEfVL
z1oMHyC3MIIIYjCCB0qgAwIBAgIDAXiqMA0GCSqGSIb3DQEBBQUAMIGvMQswCQYDVQQGEwJJ
TDEPMA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpT
ZWN1cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQ
cmltYXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9y
ZzAeFw0wNzA4MjIyMTEzMjdaFw0wODA4MjEyMTEzMjdaMIG6MQswCQYDVQQGEwJVUzERMA8G
A1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEaMBgGA1UEChMRUGV0ZXIgU2FpbnQt
QW5kcmUxLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRow
GAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBl
dGVyLmltMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsLV2SoOCCG69QKQSWhEN
fnRNMnpLOPUGq0ylir4CfroHCRZ8/Tu5rL6MeiuLvvvvrCTX8COTWdNIdf4laj4lbBVdhYFf
5l3vzRsHQUZKFiUcbAyF3+nFf2xPgpbcP6vywgdVtMZ251LB6410GGqvWIRyPN7vmGnLAyST
U5CFOSx5DEjmjBr0zfUk500RfQlrp6zKHDC2qpM0Lzo66NfBrbB7DwZNEkT2nYjQHVUKwq4l
o9q1shx/04WJNI4Nvm/Kirf6WsSWHpXoFcrER9DgPYcJJj7lSaUp2eW3O81urHJpNhCLVgaw
XN7DtJPdHw/mOsKrZy9GMatMpWiNleA9nQIDAQABo4IEeDCCBHQwDAYDVR0TBAUwAwIBADAL
BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSX
sJTZ1L9qU7AsgdX85zZGQYNi6DCB3QYDVR0jBIHVMIHSgBQErNskd1NGRpZfFwFcfUJHvUgZ
CKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UEBxMFRWls
YXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0eSBEZXAu
MSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8GCSqGSIb3
DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0gBIIBNzCCATMwggEvBgsrBgEE
AYG1NwEBBDCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRl
cm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s
aWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGNTGltaXRl
ZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0
aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9j
ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j
ZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0
Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4MHYwNwYIKwYBBQUHMAGGK2h0
dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3VzZXIvY2EwOwYIKwYBBQUHMAKG
L2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3MzLnVzZXIuY2EuY3J0MBEGCWCG
SAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRDb20gVHJ1c3RlZCBFbWFpbCBD
ZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2Nh
LWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1
My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s
aWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFydGNvbS5vcmcwDQYJKoZIhvcN
AQEFBQADggEBAJ0bUvRPg5PXHhf9wqy4fGCKNFpkYaJUQJyfn7VfsTcfnj/IORSpYCnoxneF
mbfqnNNhieX7kzq+V0tyoUJWkPsyAfoqa76vqlcCNTfeTVEgeeQG9DooaVGnRGN9plb/YyQb
Tu8XZBMtvHooiGLSlr0GD3CWrLD4LaDoVid+at0kuAavFRd6TwNJk2Nn8ADvk6i62taQG11o
vZNsWJrB1sa4ltKhAseous2FPx/vg55ztF46a5RMQvyGwVTSxtj+fZ71adrVXPN7edk9vI+I
LkXzynzyBUsH2YqQ7OV5h59iJDDwsAHPnHUwj7DRs0o08u+In8qccYUR9UvPWgwfILcxggQs
MIIEKAIBATCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMN
U3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAt
BgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZI
hvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjAJBgUrDgMCGgUAoIICSTAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEyMTQyMTUyNDNaMCMGCSqG
SIb3DQEJBDEWBBRGeUmGCerXVdPuf0rPasVpi95XZjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG
SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG
9w0DAgIBKDCByAYJKwYBBAGCNxAEMYG6MIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMG
SXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlm
aWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWls
IEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAXiqMIHKBgsq
hkiG9w0BCRACCzGBuqCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQG
A1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25p
bmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEw
HwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjANBgkqhkiG9w0BAQEFAASC
AQCY5KZc+IjDAZ0cPgjEsJe4iEHkrAT7RaUVxK7jp2j3sGaS7r0lxQcqB1hgR4+mbuss1Sj9
PAZA7HpAPMURq/enPgbssWQkLC5PoB9DOiYwaMVgoDlOVtihJXKse4uKRy6c+RgYOmVxvJXY
+EE1VvuP5zGWqRi/ILE1u/oGs6cDy0XaMFbwVVr3LIEQa4rfk7dwIWe7iRw2jr6ByTqvHN1p
Yg+QQj8H2E+xidj6KZZQuN5NrIHwc/qjTRuliNIdUMRwuvguPdmgx20rBzu6busjYwBzasv2
xoVFsT9PMTaUGl8JCQGiE2zKvFqXEvqS9f0GfiVm7ml6I+zb1BqGFfmYAAAAAAAA
--------------ms000608030706020205000706--
0
Peter
12/14/2007 9:52:43 PM
David Ascher wrote:
> 
> The point I was trying to make is that jabber is really interesting, but 
> right now the vast majority of users have non-jabber IM accounts.  So 
> finding a way to do interop with them would be good.
> 

If you combine some of these discussions about IM clients with the 
concepts of Mozilla providing web services directly, all kinds of 
interesting possibilities open up. If, for example, each person using Tb 
by default was signed up to a jabber account on a Mozilla server, then 
the vast majority of Tb users would have immediate IM access to most 
other Tb users. Similarly, you could use some sort of Mozilla-provided 
web service to update personal contact information between Tb users. 
That way, all Tb users would have accurate, consistent contact 
information about all other Tb users. Of course you could make this open 
source so that others could do the same, but in reality the 
zero-configuration capability provided by owning both the client 
application as well as the web service would make the default Tb version 
extremely attractive. Also, since you can better interact with other Tb 
users, then it would create some viral adoption incentive for Tb.

Kent
0
Kent
12/14/2007 10:24:21 PM
Peter Saint-Andre wrote:
> David Ascher wrote:
>   
>> I'm sorry I brought up licensing.
>>
>> The point I was trying to make is that jabber is really interesting, but 
>> right now the vast majority of users have non-jabber IM accounts.  So 
>> finding a way to do interop with them would be good.
>>
>> Hmm.  Crazy idea: could we build a server-side proxy which talked jabber 
>> to the client and whatever IM protocols to the world?
>>     
>
> Yes, we've had those since 1999. We call them "transports".
>   
In order to make this a little bit clearer for David, XMPP (Jabber) can 
talk to almost any IM protocol there is out there...It depends on what 
the server supports, but many do GoogleTalk, MSN, Amazon etc. etc.

Now XMPP has been discussed in the past and is certainly a likely 
candidate for IM integration for TB. But the initial idea in this 
specific thread was, if XMPP can somehow be useful to store contact and 
other data. To all of my knowledge most XMPP servers do store much more 
(and are capable to do so) than the very least of user names as Peter 
stated earlier. As such I can today save and retrieve various 
information about other XMPP users including images etc...hence I 
believe that it should be possible to extend in some way in an existing 
framework. Peter, if I misunderstand something here, please correct me...

And since XMPP is based mostly (all?) on XML I think this should be 
interesting in every respect as somebody else here already mentioned XML 
as a likely candidate...

-- 
Regards 
 
Signer:  	Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber:  	startcom@startcom.org <xmpp:startcom@startcom.org>
Blog:  	Join the Revolution! <http://blog.startcom.org>
Phone:  	+1.213.341.0390
 

0
Eddy
12/14/2007 10:48:08 PM
David Ascher wrote:
> I'm sorry I brought up licensing.
> 
> The point I was trying to make is that jabber is really interesting, but 
> right now the vast majority of users have non-jabber IM accounts. So 
> finding a way to do interop with them would be good.
> 
> Hmm. Crazy idea: could we build a server-side proxy which talked jabber 
> to the client and whatever IM protocols to the world?

XMPP was specifically built to allow Jabber servers to do exactly this, 
and some deployed servers do support it.

Dan


0
Dan
12/14/2007 10:58:14 PM
This is a cryptographically signed message in MIME format.

--------------ms090601060104040906040800
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Eddy Nigg (StartCom Ltd.) wrote:
> Peter Saint-Andre wrote:
>> David Ascher wrote:
>>   
>>> I'm sorry I brought up licensing.
>>>
>>> The point I was trying to make is that jabber is really interesting, but 
>>> right now the vast majority of users have non-jabber IM accounts.  So 
>>> finding a way to do interop with them would be good.
>>>
>>> Hmm.  Crazy idea: could we build a server-side proxy which talked jabber 
>>> to the client and whatever IM protocols to the world?
>>>     
>> Yes, we've had those since 1999. We call them "transports".
>>   
> In order to make this a little bit clearer for David, XMPP (Jabber) can 
> talk to almost any IM protocol there is out there...It depends on what 
> the server supports, but many do GoogleTalk, MSN, Amazon etc. etc.

Well Google Talk just *is* XMPP. Proprietary services like AIM, ICQ, MSN
(now Windows Live Messenger), QQ, Skype, and Yahoo! Instant Messenger
use their own closed protocols, but it is possible to run a transport or
gateway on the server side to translate from the open Jabber protocol to
the closed protocol of choice. However, those translations are not easy
to keep current since the proprietary services continually change their
protocols.

> Now XMPP has been discussed in the past and is certainly a likely 
> candidate for IM integration for TB. But the initial idea in this 
> specific thread was, if XMPP can somehow be useful to store contact and 
> other data. To all of my knowledge most XMPP servers do store much more 
> (and are capable to do so) than the very least of user names as Peter 
> stated earlier. As such I can today save and retrieve various 
> information about other XMPP users including images etc...hence I 
> believe that it should be possible to extend in some way in an existing 
> framework. Peter, if I misunderstand something here, please correct me...

Most XMPP server codebases (there are many) can be enchanced through
what we call server-side components. Transports (mentioned above) are
one kind of component, but we also have components for multi-user chat,
data syndication (real-time Atom/RSS feeds), generic publish-subscribe
services, user directories, and so on.

> And since XMPP is based mostly (all?) on XML I think this should be 
> interesting in every respect as somebody else here already mentioned XML 
> as a likely candidate...

Right. XMPP is at root just a technology for streaming XML. What you
send over it is up to you.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


--------------ms090601060104040906040800
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYQDCC
B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI
EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD
VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0
MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy
YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh
dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy
ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz
eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA
IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O
U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj
eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u
xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud
DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx
tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE
BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0
eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G
CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0
YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp
oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6
Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5
BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y
Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50
ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX
TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z
KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls
YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC
AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl
cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo
dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0
cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw
Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H
yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa
v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0
4STurMCFwLoyx5k1rDHQYTCCCGIwggdKoAMCAQICAwF4qjANBgkqhkiG9w0BAQUFADCBrzEL
MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj
MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t
IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz
dGFydGNvbS5vcmcwHhcNMDcwODIyMjExMzI3WhcNMDgwODIxMjExMzI3WjCBujELMAkGA1UE
BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxGjAYBgNVBAoTEVBl
dGVyIFNhaW50LUFuZHJlMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl
IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0
cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALC1dkqD
gghuvUCkEloRDX50TTJ6Szj1BqtMpYq+An66BwkWfP07uay+jHori77776wk1/Ajk1nTSHX+
JWo+JWwVXYWBX+Zd780bB0FGShYlHGwMhd/pxX9sT4KW3D+r8sIHVbTGdudSweuNdBhqr1iE
cjze75hpywMkk1OQhTkseQxI5owa9M31JOdNEX0Ja6esyhwwtqqTNC86OujXwa2wew8GTRJE
9p2I0B1VCsKuJaPatbIcf9OFiTSODb5vyoq3+lrElh6V6BXKxEfQ4D2HCSY+5UmlKdnltzvN
bqxyaTYQi1YGsFzew7ST3R8P5jrCq2cvRjGrTKVojZXgPZ0CAwEAAaOCBHgwggR0MAwGA1Ud
EwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAd
BgNVHQ4EFgQUl7CU2dS/alOwLIHV/Oc2RkGDYugwgd0GA1UdIwSB1TCB0oAUBKzbJHdTRkaW
XxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxDjAM
BgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFDQSBBdXRo
b3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx
ITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASCATcwggEz
MIIBLwYLKwYBBAGBtTcBAQQwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNv
bS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0ZC4wAwIB
ARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0
aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWlsYWJsZSBh
dCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBbMCygKqAo
hiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDov
L2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2MDcGCCsG
AQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2VyL2NhMDsG
CCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51c2VyLmNh
LmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29tIFRydXN0
ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0LnN0YXJ0
Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5zdGFydGNv
bS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRjb20ub3Jn
MA0GCSqGSIb3DQEBBQUAA4IBAQCdG1L0T4OT1x4X/cKsuHxgijRaZGGiVECcn5+1X7E3H54/
yDkUqWAp6MZ3hZm36pzTYYnl+5M6vldLcqFCVpD7MgH6Kmu+r6pXAjU33k1RIHnkBvQ6KGlR
p0RjfaZW/2MkG07vF2QTLbx6KIhi0pa9Bg9wlqyw+C2g6FYnfmrdJLgGrxUXek8DSZNjZ/AA
75OoutrWkBtdaL2TbFiawdbGuJbSoQLHqLrNhT8f74Oec7ReOmuUTEL8hsFU0sbY/n2e9Wna
1Vzze3nZPbyPiC5F88p88gVLB9mKkOzleYefYiQw8LABz5x1MI+w0bNKNPLviJ/KnHGFEfVL
z1oMHyC3MIIIYjCCB0qgAwIBAgIDAXiqMA0GCSqGSIb3DQEBBQUAMIGvMQswCQYDVQQGEwJJ
TDEPMA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpT
ZWN1cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQ
cmltYXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9y
ZzAeFw0wNzA4MjIyMTEzMjdaFw0wODA4MjEyMTEzMjdaMIG6MQswCQYDVQQGEwJVUzERMA8G
A1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEaMBgGA1UEChMRUGV0ZXIgU2FpbnQt
QW5kcmUxLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRow
GAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBl
dGVyLmltMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsLV2SoOCCG69QKQSWhEN
fnRNMnpLOPUGq0ylir4CfroHCRZ8/Tu5rL6MeiuLvvvvrCTX8COTWdNIdf4laj4lbBVdhYFf
5l3vzRsHQUZKFiUcbAyF3+nFf2xPgpbcP6vywgdVtMZ251LB6410GGqvWIRyPN7vmGnLAyST
U5CFOSx5DEjmjBr0zfUk500RfQlrp6zKHDC2qpM0Lzo66NfBrbB7DwZNEkT2nYjQHVUKwq4l
o9q1shx/04WJNI4Nvm/Kirf6WsSWHpXoFcrER9DgPYcJJj7lSaUp2eW3O81urHJpNhCLVgaw
XN7DtJPdHw/mOsKrZy9GMatMpWiNleA9nQIDAQABo4IEeDCCBHQwDAYDVR0TBAUwAwIBADAL
BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSX
sJTZ1L9qU7AsgdX85zZGQYNi6DCB3QYDVR0jBIHVMIHSgBQErNskd1NGRpZfFwFcfUJHvUgZ
CKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UEBxMFRWls
YXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0eSBEZXAu
MSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8GCSqGSIb3
DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0gBIIBNzCCATMwggEvBgsrBgEE
AYG1NwEBBDCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRl
cm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s
aWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGNTGltaXRl
ZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0
aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9j
ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j
ZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0
Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4MHYwNwYIKwYBBQUHMAGGK2h0
dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3VzZXIvY2EwOwYIKwYBBQUHMAKG
L2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3MzLnVzZXIuY2EuY3J0MBEGCWCG
SAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRDb20gVHJ1c3RlZCBFbWFpbCBD
ZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2Nh
LWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1
My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s
aWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFydGNvbS5vcmcwDQYJKoZIhvcN
AQEFBQADggEBAJ0bUvRPg5PXHhf9wqy4fGCKNFpkYaJUQJyfn7VfsTcfnj/IORSpYCnoxneF
mbfqnNNhieX7kzq+V0tyoUJWkPsyAfoqa76vqlcCNTfeTVEgeeQG9DooaVGnRGN9plb/YyQb
Tu8XZBMtvHooiGLSlr0GD3CWrLD4LaDoVid+at0kuAavFRd6TwNJk2Nn8ADvk6i62taQG11o
vZNsWJrB1sa4ltKhAseous2FPx/vg55ztF46a5RMQvyGwVTSxtj+fZ71adrVXPN7edk9vI+I
LkXzynzyBUsH2YqQ7OV5h59iJDDwsAHPnHUwj7DRs0o08u+In8qccYUR9UvPWgwfILcxggQs
MIIEKAIBATCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMN
U3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAt
BgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZI
hvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjAJBgUrDgMCGgUAoIICSTAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEyMTQyMjU4MzZaMCMGCSqG
SIb3DQEJBDEWBBSbzssdweX5F/wvJ8dNelZS5Je3PjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG
SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG
9w0DAgIBKDCByAYJKwYBBAGCNxAEMYG6MIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMG
SXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlm
aWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWls
IEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAXiqMIHKBgsq
hkiG9w0BCRACCzGBuqCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQG
A1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25p
bmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEw
HwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjANBgkqhkiG9w0BAQEFAASC
AQAJej9vJeIMxsZZZKyXMi9RuQ+n/BCNt6veg1liOwgQzUll3GsQcAzAjgF62QN095xFIBXP
UmnpHxBWKecDq4PooEWmyrpYBNOfKJsfibIWYrlideYKg4rG2h2Rrhn5dCqaXeQAKDlUa+66
YUjTtyLW0v3yKAI3nQRc0S4t1hdXXIicN6DcTdJ+78dRUgtJNVgtGiNr1uX5g9WzKNvhZ+fm
dE5IEvzB3BPyIsNa9hG7dKeoaYoQ+T30GvfeYVVmyaZR7r8FRKbbZZ6LZsO5G8R8fGmL504i
lYlx8+DuzpJGCMUM1/GwADK77SkphvZksADcfSVgTjJWVSgyPDIq+dBcAAAAAAAA
--------------ms090601060104040906040800--
0
Peter
12/14/2007 10:58:36 PM
This is a cryptographically signed message in MIME format.

--------------ms080306010707000802010006
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Kent James wrote:
> David Ascher wrote:
>> The point I was trying to make is that jabber is really interesting, but 
>> right now the vast majority of users have non-jabber IM accounts.  So 
>> finding a way to do interop with them would be good.
>>
> 
> If you combine some of these discussions about IM clients with the 
> concepts of Mozilla providing web services directly, all kinds of 
> interesting possibilities open up. If, for example, each person using Tb 
> by default was signed up to a jabber account on a Mozilla server, then 
> the vast majority of Tb users would have immediate IM access to most 
> other Tb users. Similarly, you could use some sort of Mozilla-provided 
> web service to update personal contact information between Tb users. 
> That way, all Tb users would have accurate, consistent contact 
> information about all other Tb users. Of course you could make this open 
> source so that others could do the same, but in reality the 
> zero-configuration capability provided by owning both the client 
> application as well as the web service would make the default Tb version 
> extremely attractive. Also, since you can better interact with other Tb 
> users, then it would create some viral adoption incentive for Tb.

Very interesting. About how many Tb users are there in the world? I'm
just trying to figure out how high a mozilla.com (or whatever) Jabber
server would need to scale. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


--------------ms080306010707000802010006
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYQDCC
B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI
EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD
VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0
MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy
YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh
dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy
ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz
eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA
IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O
U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj
eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u
xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud
DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx
tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE
BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0
eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G
CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0
YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp
oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6
Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5
BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y
Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50
ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX
TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z
KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls
YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC
AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl
cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo
dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0
cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw
Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H
yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa
v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0
4STurMCFwLoyx5k1rDHQYTCCCGIwggdKoAMCAQICAwF4qjANBgkqhkiG9w0BAQUFADCBrzEL
MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj
MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t
IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz
dGFydGNvbS5vcmcwHhcNMDcwODIyMjExMzI3WhcNMDgwODIxMjExMzI3WjCBujELMAkGA1UE
BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxGjAYBgNVBAoTEVBl
dGVyIFNhaW50LUFuZHJlMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl
IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0
cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALC1dkqD
gghuvUCkEloRDX50TTJ6Szj1BqtMpYq+An66BwkWfP07uay+jHori77776wk1/Ajk1nTSHX+
JWo+JWwVXYWBX+Zd780bB0FGShYlHGwMhd/pxX9sT4KW3D+r8sIHVbTGdudSweuNdBhqr1iE
cjze75hpywMkk1OQhTkseQxI5owa9M31JOdNEX0Ja6esyhwwtqqTNC86OujXwa2wew8GTRJE
9p2I0B1VCsKuJaPatbIcf9OFiTSODb5vyoq3+lrElh6V6BXKxEfQ4D2HCSY+5UmlKdnltzvN
bqxyaTYQi1YGsFzew7ST3R8P5jrCq2cvRjGrTKVojZXgPZ0CAwEAAaOCBHgwggR0MAwGA1Ud
EwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAd
BgNVHQ4EFgQUl7CU2dS/alOwLIHV/Oc2RkGDYugwgd0GA1UdIwSB1TCB0oAUBKzbJHdTRkaW
XxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxDjAM
BgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFDQSBBdXRo
b3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx
ITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASCATcwggEz
MIIBLwYLKwYBBAGBtTcBAQQwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNv
bS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0ZC4wAwIB
ARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0
aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWlsYWJsZSBh
dCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBbMCygKqAo
hiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDov
L2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2MDcGCCsG
AQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2VyL2NhMDsG
CCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51c2VyLmNh
LmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29tIFRydXN0
ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0LnN0YXJ0
Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5zdGFydGNv
bS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRjb20ub3Jn
MA0GCSqGSIb3DQEBBQUAA4IBAQCdG1L0T4OT1x4X/cKsuHxgijRaZGGiVECcn5+1X7E3H54/
yDkUqWAp6MZ3hZm36pzTYYnl+5M6vldLcqFCVpD7MgH6Kmu+r6pXAjU33k1RIHnkBvQ6KGlR
p0RjfaZW/2MkG07vF2QTLbx6KIhi0pa9Bg9wlqyw+C2g6FYnfmrdJLgGrxUXek8DSZNjZ/AA
75OoutrWkBtdaL2TbFiawdbGuJbSoQLHqLrNhT8f74Oec7ReOmuUTEL8hsFU0sbY/n2e9Wna
1Vzze3nZPbyPiC5F88p88gVLB9mKkOzleYefYiQw8LABz5x1MI+w0bNKNPLviJ/KnHGFEfVL
z1oMHyC3MIIIYjCCB0qgAwIBAgIDAXiqMA0GCSqGSIb3DQEBBQUAMIGvMQswCQYDVQQGEwJJ
TDEPMA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpT
ZWN1cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQ
cmltYXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9y
ZzAeFw0wNzA4MjIyMTEzMjdaFw0wODA4MjEyMTEzMjdaMIG6MQswCQYDVQQGEwJVUzERMA8G
A1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEaMBgGA1UEChMRUGV0ZXIgU2FpbnQt
QW5kcmUxLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRow
GAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBl
dGVyLmltMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsLV2SoOCCG69QKQSWhEN
fnRNMnpLOPUGq0ylir4CfroHCRZ8/Tu5rL6MeiuLvvvvrCTX8COTWdNIdf4laj4lbBVdhYFf
5l3vzRsHQUZKFiUcbAyF3+nFf2xPgpbcP6vywgdVtMZ251LB6410GGqvWIRyPN7vmGnLAyST
U5CFOSx5DEjmjBr0zfUk500RfQlrp6zKHDC2qpM0Lzo66NfBrbB7DwZNEkT2nYjQHVUKwq4l
o9q1shx/04WJNI4Nvm/Kirf6WsSWHpXoFcrER9DgPYcJJj7lSaUp2eW3O81urHJpNhCLVgaw
XN7DtJPdHw/mOsKrZy9GMatMpWiNleA9nQIDAQABo4IEeDCCBHQwDAYDVR0TBAUwAwIBADAL
BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSX
sJTZ1L9qU7AsgdX85zZGQYNi6DCB3QYDVR0jBIHVMIHSgBQErNskd1NGRpZfFwFcfUJHvUgZ
CKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UEBxMFRWls
YXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0eSBEZXAu
MSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8GCSqGSIb3
DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0gBIIBNzCCATMwggEvBgsrBgEE
AYG1NwEBBDCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRl
cm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s
aWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGNTGltaXRl
ZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0
aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9j
ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j
ZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0
Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4MHYwNwYIKwYBBQUHMAGGK2h0
dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3VzZXIvY2EwOwYIKwYBBQUHMAKG
L2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3MzLnVzZXIuY2EuY3J0MBEGCWCG
SAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRDb20gVHJ1c3RlZCBFbWFpbCBD
ZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2Nh
LWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1
My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s
aWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFydGNvbS5vcmcwDQYJKoZIhvcN
AQEFBQADggEBAJ0bUvRPg5PXHhf9wqy4fGCKNFpkYaJUQJyfn7VfsTcfnj/IORSpYCnoxneF
mbfqnNNhieX7kzq+V0tyoUJWkPsyAfoqa76vqlcCNTfeTVEgeeQG9DooaVGnRGN9plb/YyQb
Tu8XZBMtvHooiGLSlr0GD3CWrLD4LaDoVid+at0kuAavFRd6TwNJk2Nn8ADvk6i62taQG11o
vZNsWJrB1sa4ltKhAseous2FPx/vg55ztF46a5RMQvyGwVTSxtj+fZ71adrVXPN7edk9vI+I
LkXzynzyBUsH2YqQ7OV5h59iJDDwsAHPnHUwj7DRs0o08u+In8qccYUR9UvPWgwfILcxggQs
MIIEKAIBATCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMN
U3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAt
BgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZI
hvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjAJBgUrDgMCGgUAoIICSTAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEyMTQyMzAwNTlaMCMGCSqG
SIb3DQEJBDEWBBQEnR5uPbcpBc6rHKTCslfk2dTojTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG
SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG
9w0DAgIBKDCByAYJKwYBBAGCNxAEMYG6MIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMG
SXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlm
aWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWls
IEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAXiqMIHKBgsq
hkiG9w0BCRACCzGBuqCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQG
A1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25p
bmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEw
HwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjANBgkqhkiG9w0BAQEFAASC
AQBb8MMZD/DUIOufLsIKNy3ws4jtkdqZkpwGqUwzNGQpB1CvdAhvm0AVcGKXETbJXAYG6hKn
ALo1hM/c1jyCj/rkUPCWaTP+IFx1Ovqqz8lnCRZtCd06g2xBEO/4Dt5BJKL3ouCN4hixHpZb
7+5iZF0uDFs9qs8OionMmYx3ykMnXu+ChsC9ucVUcpVK4rDwx4QqvaQZJZzpj3v8U7Q8CyQ5
KlFcjPfCN1nHECfxhurmEZPHez9AoE0eH0WLpO9B97PkeDuQGNed48N+Uuuw/ycTXMY3x0r4
ce4HMBsjOO957IplW+YeozLFYSe8DGen5r++3970T4kb4qbVLF+/zRqJAAAAAAAA
--------------ms080306010707000802010006--
0
Peter
12/14/2007 11:00:59 PM
This is a cryptographically signed message in MIME format.

--------------ms080909020905070000010204
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Dan Mosedale wrote:
> David Ascher wrote:
>> I'm sorry I brought up licensing.
>>
>> The point I was trying to make is that jabber is really interesting, but 
>> right now the vast majority of users have non-jabber IM accounts. So 
>> finding a way to do interop with them would be good.
>>
>> Hmm. Crazy idea: could we build a server-side proxy which talked jabber 
>> to the client and whatever IM protocols to the world?
> 
> XMPP was specifically built to allow Jabber servers to do exactly this, 
> and some deployed servers do support it.

However, if you run a big Jabber server with transports to all the
proprietary services and lots of transport users, those services may
block your IP addresses. It happened to us years ago at jabber.org,
which is why we don't even try to run transports there anymore.

The real answer is for those services to use open protocols for
inter-service communication. I mean, we don't have email "transports"
from SMTP to Prodigy, CompuServe, MCIMail, and AOL, do we? IM is still
in 1993 as far as inter-service communication goes...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


--------------ms080909020905070000010204
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYQDCC
B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI
EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD
VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0
MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy
YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh
dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy
ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz
eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA
IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O
U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj
eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u
xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud
DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx
tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE
BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0
eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G
CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0
YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp
oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6
Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5
BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y
Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50
ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX
TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z
KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls
YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC
AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl
cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo
dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0
cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw
Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H
yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa
v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0
4STurMCFwLoyx5k1rDHQYTCCCGIwggdKoAMCAQICAwF4qjANBgkqhkiG9w0BAQUFADCBrzEL
MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj
MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t
IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz
dGFydGNvbS5vcmcwHhcNMDcwODIyMjExMzI3WhcNMDgwODIxMjExMzI3WjCBujELMAkGA1UE
BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxGjAYBgNVBAoTEVBl
dGVyIFNhaW50LUFuZHJlMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl
IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0
cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALC1dkqD
gghuvUCkEloRDX50TTJ6Szj1BqtMpYq+An66BwkWfP07uay+jHori77776wk1/Ajk1nTSHX+
JWo+JWwVXYWBX+Zd780bB0FGShYlHGwMhd/pxX9sT4KW3D+r8sIHVbTGdudSweuNdBhqr1iE
cjze75hpywMkk1OQhTkseQxI5owa9M31JOdNEX0Ja6esyhwwtqqTNC86OujXwa2wew8GTRJE
9p2I0B1VCsKuJaPatbIcf9OFiTSODb5vyoq3+lrElh6V6BXKxEfQ4D2HCSY+5UmlKdnltzvN
bqxyaTYQi1YGsFzew7ST3R8P5jrCq2cvRjGrTKVojZXgPZ0CAwEAAaOCBHgwggR0MAwGA1Ud
EwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAd
BgNVHQ4EFgQUl7CU2dS/alOwLIHV/Oc2RkGDYugwgd0GA1UdIwSB1TCB0oAUBKzbJHdTRkaW
XxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxDjAM
BgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFDQSBBdXRo
b3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx
ITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASCATcwggEz
MIIBLwYLKwYBBAGBtTcBAQQwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNv
bS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0ZC4wAwIB
ARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0
aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWlsYWJsZSBh
dCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBbMCygKqAo
hiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDov
L2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2MDcGCCsG
AQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2VyL2NhMDsG
CCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51c2VyLmNh
LmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29tIFRydXN0
ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0LnN0YXJ0
Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5zdGFydGNv
bS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRjb20ub3Jn
MA0GCSqGSIb3DQEBBQUAA4IBAQCdG1L0T4OT1x4X/cKsuHxgijRaZGGiVECcn5+1X7E3H54/
yDkUqWAp6MZ3hZm36pzTYYnl+5M6vldLcqFCVpD7MgH6Kmu+r6pXAjU33k1RIHnkBvQ6KGlR
p0RjfaZW/2MkG07vF2QTLbx6KIhi0pa9Bg9wlqyw+C2g6FYnfmrdJLgGrxUXek8DSZNjZ/AA
75OoutrWkBtdaL2TbFiawdbGuJbSoQLHqLrNhT8f74Oec7ReOmuUTEL8hsFU0sbY/n2e9Wna
1Vzze3nZPbyPiC5F88p88gVLB9mKkOzleYefYiQw8LABz5x1MI+w0bNKNPLviJ/KnHGFEfVL
z1oMHyC3MIIIYjCCB0qgAwIBAgIDAXiqMA0GCSqGSIb3DQEBBQUAMIGvMQswCQYDVQQGEwJJ
TDEPMA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpT
ZWN1cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQ
cmltYXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9y
ZzAeFw0wNzA4MjIyMTEzMjdaFw0wODA4MjEyMTEzMjdaMIG6MQswCQYDVQQGEwJVUzERMA8G
A1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEaMBgGA1UEChMRUGV0ZXIgU2FpbnQt
QW5kcmUxLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRow
GAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBl
dGVyLmltMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsLV2SoOCCG69QKQSWhEN
fnRNMnpLOPUGq0ylir4CfroHCRZ8/Tu5rL6MeiuLvvvvrCTX8COTWdNIdf4laj4lbBVdhYFf
5l3vzRsHQUZKFiUcbAyF3+nFf2xPgpbcP6vywgdVtMZ251LB6410GGqvWIRyPN7vmGnLAyST
U5CFOSx5DEjmjBr0zfUk500RfQlrp6zKHDC2qpM0Lzo66NfBrbB7DwZNEkT2nYjQHVUKwq4l
o9q1shx/04WJNI4Nvm/Kirf6WsSWHpXoFcrER9DgPYcJJj7lSaUp2eW3O81urHJpNhCLVgaw
XN7DtJPdHw/mOsKrZy9GMatMpWiNleA9nQIDAQABo4IEeDCCBHQwDAYDVR0TBAUwAwIBADAL
BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSX
sJTZ1L9qU7AsgdX85zZGQYNi6DCB3QYDVR0jBIHVMIHSgBQErNskd1NGRpZfFwFcfUJHvUgZ
CKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UEBxMFRWls
YXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0eSBEZXAu
MSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8GCSqGSIb3
DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0gBIIBNzCCATMwggEvBgsrBgEE
AYG1NwEBBDCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRl
cm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s
aWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGNTGltaXRl
ZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0
aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9j
ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j
ZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0
Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4MHYwNwYIKwYBBQUHMAGGK2h0
dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3VzZXIvY2EwOwYIKwYBBQUHMAKG
L2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3MzLnVzZXIuY2EuY3J0MBEGCWCG
SAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRDb20gVHJ1c3RlZCBFbWFpbCBD
ZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2Nh
LWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1
My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s
aWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFydGNvbS5vcmcwDQYJKoZIhvcN
AQEFBQADggEBAJ0bUvRPg5PXHhf9wqy4fGCKNFpkYaJUQJyfn7VfsTcfnj/IORSpYCnoxneF
mbfqnNNhieX7kzq+V0tyoUJWkPsyAfoqa76vqlcCNTfeTVEgeeQG9DooaVGnRGN9plb/YyQb
Tu8XZBMtvHooiGLSlr0GD3CWrLD4LaDoVid+at0kuAavFRd6TwNJk2Nn8ADvk6i62taQG11o
vZNsWJrB1sa4ltKhAseous2FPx/vg55ztF46a5RMQvyGwVTSxtj+fZ71adrVXPN7edk9vI+I
LkXzynzyBUsH2YqQ7OV5h59iJDDwsAHPnHUwj7DRs0o08u+In8qccYUR9UvPWgwfILcxggQs
MIIEKAIBATCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMN
U3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAt
BgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZI
hvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjAJBgUrDgMCGgUAoIICSTAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEyMTQyMzA2MzdaMCMGCSqG
SIb3DQEJBDEWBBS9wTeCFKyAWtm0YgcaOqyzNcw+ZTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG
SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG
9w0DAgIBKDCByAYJKwYBBAGCNxAEMYG6MIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMG
SXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlm
aWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWls
IEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAXiqMIHKBgsq
hkiG9w0BCRACCzGBuqCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQG
A1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25p
bmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEw
HwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjANBgkqhkiG9w0BAQEFAASC
AQBe4gxl5KSaVJwO9sPxxOAMhb2w+j95PlEJV795CXVF8L2CQL/aEnl8g8C4NysprtB4Rdvm
k4ovpxfG82+TUDhFhPMg+CAKlVrFOBBEvlAtHjUwJ28uHOZRMFrjNch+cGJj5vXUVZGrKfub
6J9RHqehSnUw+ORI/Un+TpgBQn9PSHg9kbz6BAkQeagUKomHRI2B/40LVPDEHM2QjCHU62jD
0Q3MCSPmapqvBk75A69sq8B/DPLFK+T2bZ4Ezj4At9KWmB2Pw0dV+sfyIVCeng8dtYs3mYYc
hY3VG4OQRlROQkZmNX+BVaEcjXBVRc9PwGmSLN9sEpWQhJuqVwsIacmRAAAAAAAA
--------------ms080909020905070000010204--
0
Peter
12/14/2007 11:06:37 PM
David Ascher keyboarded, On 12/14/2007 3:28 PM :
> Ron K. wrote:
>> Yes, we are fragmented in part because I view the Tb community has 
>> been forced to adapt to the Firefox business model.
>
> Do you really mean business model, or just "firefox community ways"?

The latter. Tbird has been forced into  the Firefox  style in may ways,  
Try the add-on site.  All the Tbird add-ons have an install button, not 
a download  button which would clarify the difference in add-on install 
procedure, remote versus local. It is this issue that Scott wanted the 
Tbird community to discuss at the Mozilla Wiki. Only two people 
responded, I am one of them. So simple question: Why can't we have our 
own template page so that the Webmaster would use it to setup a new 
Tbird extension page. I consider this web page issue to be disrespectful 
of Tbirds status as a Mozilla Foundation sponsored application.


>
>> Having worked with Eddy on a report in August, I am familiar with his 
>> enthusiasm. My recommendation to David A. is to say "These are the 
>> places we will do business" because I feel MailCo needs to flesh out 
>> it's identity and community.
>
> Agreed.  Part of my job is to figure out where to adapt to existing 
> Mozilla-wide structures, where to adapt to existing Thunderbird & 
> Mailnews structures, and where to create new ones.
>>  I pointed out to David that Same Place is a Jabber IM/IRC solution 
>> that has presence so we can see at a glance who is busy, away, or 
>> available. It is both Fx and Tb 2.0+ compatible. Nit is it lacks 
>> persistance.
>>   
>
> Yup.  Along similar lines, it's too bad that libpurple is GPL, as that 
> makes incorporating it into mainline Thunderbird problematic.
> --david
>

LOL, I am being bombarded with terms right out of the Harry Potter 
wizards manual.  Pray tell, how does a purple library relate to Tbird.

-- 
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported BSOD use by Major Error to msg the enemy!
0
Ron
12/14/2007 11:49:15 PM
Ron K. wrote:
> Tbird has been forced into  the Firefox  style in may ways,  
> Try the add-on site.  All the Tbird add-ons have an install button, not 
> a download  button which would clarify the difference in add-on install 
> procedure, remote versus local. It is this issue that Scott wanted the 
> Tbird community to discuss at the Mozilla Wiki. Only two people 
> responded, I am one of them. 

Do you know the URL by any chance?

> So simple question: Why can't we have our 
> own template page so that the Webmaster would use it to setup a new 
> Tbird extension page. I consider this web page issue to be disrespectful 
> of Tbirds status as a Mozilla Foundation sponsored application.
>   

The extension experience (for authors and users) is an issue that I want 
MailCo to tackle soon.  It's one of those problems which isn't 
technically super hard, but which needs someone to figure out what all 
the bits should be.  For example, things get a bit complicated when you 
realize that some extensions should be installable with a one-click in 
Seamonkey, but shouldn't be installed in Firefox, etc.  It's workable, 
but it needs to be someone's priority.  NB: This kind of problem is 
_exactly_ why MailCo is being created, and why one of the roles I'm 
looking for is someone who can be the extensions lead/evangelist.

> LOL, I am being bombarded with terms right out of the Harry Potter 
> wizards manual.  Pray tell, how does a purple library relate to Tbird.
>   

Sorry, forgot to give background: libpurple is a cross-IM client library 
which is part of Pidgin (n�e Gaim). 

-david
0
David
12/14/2007 11:58:23 PM
Peter Saint-Andre keyboarded, On 12/14/2007 6:00 PM :
> Kent James wrote:
>   
>> David Ascher wrote:
>>     
>>> The point I was trying to make is that jabber is really interesting, but 
>>> right now the vast majority of users have non-jabber IM accounts.  So 
>>> finding a way to do interop with them would be good.
>>>
>>>       
>> If you combine some of these discussions about IM clients with the 
>> concepts of Mozilla providing web services directly, all kinds of 
>> interesting possibilities open up. If, for example, each person using Tb 
>> by default was signed up to a jabber account on a Mozilla server, then 
>> the vast majority of Tb users would have immediate IM access to most 
>> other Tb users. Similarly, you could use some sort of Mozilla-provided 
>> web service to update personal contact information between Tb users. 
>> That way, all Tb users would have accurate, consistent contact 
>> information about all other Tb users. Of course you could make this open 
>> source so that others could do the same, but in reality the 
>> zero-configuration capability provided by owning both the client 
>> application as well as the web service would make the default Tb version 
>> extremely attractive. Also, since you can better interact with other Tb 
>> users, then it would create some viral adoption incentive for Tb.
>>     
>
> Very interesting. About how many Tb users are there in the world? I'm
> just trying to figure out how high a mozilla.com (or whatever) Jabber
> server would need to scale. :)
>
> Peter
>
>   


Peter we are already at more than the "Big" size and closing in on 
"Huge"  My guess is more than 10 million and less than 100 million user 
world wide. So what is the Scale factor in terms of bandwidth and server 
boxes to put this idea into play?

-- 
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported BSOD use by Major Error to msg the enemy!
0
Ron
12/14/2007 11:59:21 PM
Dan Mosedale keyboarded, On 12/14/2007 4:37 PM :
> Ron K. wrote:
>> Ed
>>>> Would it make sense to think about what protocol should be used to 
>>>> synchronize client state across channels, so that there could be a 
>>>> "thunderbird metadata server" which would hold all appropriate 
>>>> data, from "bookmarked" rss items to address book data, etc?
>>> Absolutely! I'm not sure if there is such a protocol, but I think 
>>> the people from XMPP could help us thinking into the right 
>>> directions a little bit...
>
> In the past, there was a protocol called ACAP.  It evolved from the 
> IMSP protocol, and I think Cyrus Daboo (one of the CalDAV spec 
> authors) had a hand in it.  I'm pretty sure Mulberry Mail supports one 
> or both of these.
>
> <http://ietfreport.isoc.org/idref/draft-newman-acap-imsp-lessons/> is 
> an old document that talks about this some.  Neither of these 
> protocols achieved super widespread use but a number of partial 
> implementations of servers exist.
>
> Out of some of the ideas in ACAP evolved XCAP 
> <http://www.jdrosen.net/papers/draft-ietf-simple-xcap-12.txt>, and I 
> think there's actually some amount of usage of this in the VOIP 
> community, though I haven't really kept up.  Because it's based on 
> HTTP and XML, it's fairly "webby", so it might be a good starting point.
>
>> Would LDAP or SQL-Lite have the flexibility and adaptability for such 
>> a task ?
>
> In the Netscape 4 timeframe, users had the option of roaming their 
> data to either LDAP or HTTP servers, so the former is definitely  
> definitely possible.
>
> Dan
>

Warms my heart to hear someone bring NS history into a contemporary 
discussion. For all its flaws and blemishes,  that suite broke ground 
and in the  process created the environment we work in now.   I remember 
bring able to use the LDAP feature of NC4 to query Bigfoot, or any of 
the other LDAP directory servers, to ferret out my younger brothers 
e-mail address and location in rural Iowa. It is this sort of capability 
that I want any and all e-mail applications top perform with a simple 
interface. The data is out there, it's public, so I want it here, now, 
when I need it. My mother is dying,it's urgent that I coordinate our 
response to this calamity. I want, no, need, a useful easy way to fined 
an essential person for a critical reasion. Tbird give it to me, *Now* !!!

-- 
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported BSOD use by Major Error to msg the enemy!
0
Ron
12/15/2007 12:24:45 AM
On 12/14/2007 4:07 PM, Dan Mosedale wrote:
> David Ascher wrote:
>> Kent James wrote:
>>> 2) It really takes dedicated effort in TB to train routinely on ham, 
>>> but really the main value of a local spam filter is the 
>>> characterization of ham. Junk is common over many users, but each 
>>> person has their own unique ham signature. Some methods need to be 
>>> developed to automatically do this. Maybe, for example, we could 
>>> consider each message ham that the user replies to.
> 
>> I like that. I'd also suggest that senders to whom one replies should 
>> probably be special-cased in the addressbook as well. They're likely 
>> to be special. It might even make sense to consider some whitelisting 
>> hints.
> 
> They're already added to the personal addressbook by default (see the 
> composition / addressing prefpane), and I think anything in the personal 
> addressbook is in fact already whitelisted.
> 
>>> 3) There are now multiple text characterization schemes (starred, 
>>> junk/nonjunk, tags) that could be unified into a single system, with 
>>> possible benefits such as expanding Bayesian analysis to 
>>> determination of tags for example (to say nothing of much-needed 
>>> refactoring).
>> Agreed.
> 
> IIRC, Henry Jia of Sun long ago submitted a patch to generalize the 
> Bayesian code in some ways. I think the idea may have been to train it 
> to follow the user's general message filing pattern, rather than just 
> caring about two ham/spam buckets. It's been a while, though, so I may 
> be misremembering the details. Searching Bugzilla should turn it up...
> 
> Dan

I'm not finding anything of Henry's in bugzilla that is related.  I 
thought I recalled such a thing, but perhaps just a false memory by 
power of your suggestion :)

Selected list of enh bugs:

Bug 179518 � Automatically mark own (sent) emails as non-junk
  https://bugzilla.mozilla.org/show_bug.cgi?id=179518

Bug 194455 � Offer more control to users when junk process is learning
  https://bugzilla.mozilla.org/show_bug.cgi?id=194455

Bug 226908 � Junk Mail Controls Should Ignore Replies On User's Messages
  https://bugzilla.mozilla.org/show_bug.cgi?id=226908

Bug 237403 � Bayesian Noise Reduction
  https://bugzilla.mozilla.org/show_bug.cgi?id=237403

Bug 243430 � Improving the chi-square spam detection method
  https://bugzilla.mozilla.org/show_bug.cgi?id=243430

Bug 366491 � Maintain...junkscore & junkscoreorigin, preserve junkstatus
  https://bugzilla.mozilla.org/show_bug.cgi?id=366491


and intriguing but not directly related

Bug 181866 � Use bayesian filters for other features than spam
  https://bugzilla.mozilla.org/show_bug.cgi?id=181866


0
Wayne
12/15/2007 12:48:22 AM
On 12/14/2007 6:58 PM, David Ascher wrote:
> Ron K. wrote:
>> Tbird has been forced into the Firefox style in may ways, Try the 
>> add-on site. All the Tbird add-ons have an install button, not a 
>> download button which would clarify the difference in add-on install 
>> procedure, remote versus local. It is this issue that Scott wanted the 
>> Tbird community to discuss at the Mozilla Wiki. Only two people 
>> responded, I am one of them. 
> 
> Do you know the URL by any chance?

perhaps http://wiki.mozilla.org/Talk:Thunderbird:Extension_Installation



0
Wayne
12/15/2007 12:55:29 AM
David Ascher keyboarded, On 12/14/2007 2:51 PM :
> Kent James wrote:
>> David Ascher wrote:
>>
>>  
>>> I believe that if we figure out together where we want to go, 
>>> Thunderbird could help change the way lots and lots and LOTS of 
>>> people feel about email, communication, computer work, work in 
>>> general, social interactions, and more.  We won't do that by just 
>>> being a mail/news client.
>>>     
>>
>> In my comment on your blog entry at 
>> http://ascher.ca/blog/2007/10/17/i-just-really-want-to-know-what%e2%80%99s-going-on-with-thunderbird/ 
>> I suggested that TB focus on a single Big Idea (and suggested some 
>> possibilities), rather than try to be all things to all people. 
> Yes, thank.  FWIW, I like your 3 & 4 most of that batch.
>> But that would not be an easy path. Your existing users are primarily 
>> interested in a better email client - scheduling, LDAP, RSS, HTML 
>> editing, better search, etc, etc. Also, if you spend much time 
>> browsing bugzilla you will see many bugs that really should have been 
>> fixed a long time ago that are still out there. So there is a long 
>> grind of incremental improvement to existing features, along with bug 
>> fixes, that is clearly the path of least resistance for moving TB 
>> forward.
>>   
>
> Yup.
>
>> Yet an open source project like TB really needs to attract developers. 
> Oh yes.  But I'll tell you this -- it feels like there are a lot of 
> people outside the door, peering in the windows, trying to figure out 
> if this is a fun party.  I think as soon as we pull out the appetizer 
> trays and party games, it'll get crowded -- in a good way.
>> I don't see the long grind as being very attractive. (Though, 
>> strangely enough, I personally find the esoterica of spam filter 
>> token pruning as an interesting subject. That clearly is a "long 
>> grind" topic.)
> I'm often surprised at what people will do in their free time.  Your 
> parenthetical comment is a case in point -- there's a long tail of 
> software problems that, if you can figure out how to match interests 
> and problems, can get you 90% of the way there.  The paid staff in 
> some ways are there to pick up the other 10%.
>
>> Somehow we need to move forward on the basic improvements that the 
>> product needs, while at the same time leaving some space to try 
>> wild-eyed, innovative things (or to at least provide Mozilla-style 
>> open leadership to things that everyone is talking about, like 
>> unified communication or open social networks).
>>   
>
> Absolutely agreed.
>
>> What is sorely needed, and perhaps would be well-served by a Wiki, is 
>> to start to identify and categorize both the wild-eyed and 
>> conventional topics so that we could perhaps congregate around areas 
>> of interest, and maybe see what the Thunderbird forest starts to look 
>> like. Perhaps it would then be clear if there are a few Big Ideas 
>> that could develop a critical mass of people interested in making 
>> them happen.
>>
>>   
> Let me think on how to structure some of this.
> A related point: One bit of pain that I'm feeling is that I know there 
> are lots of great ideas in bugzilla, but it's very hard to extract 
> knowledge from that data.  Is it reasonable to consider using a set of 
> whiteboard keywords to build queries which we could then link to wiki 
> pages, so that we can e.g. keep track of all the bugs & RFEs about 
> contact management features, or IM integration features, or ...?  It's 
> what I'd have done in my last bugzilla, but it may not be Mozilla-ish 
> enough.
>
> It's great to see all this energy in the last 24 hours, btw.  I'm 
> feeling rewarded for posting.  Good job to all on providing positive 
> reinforcment =).
>
> --david

Wow, I choked on you line about the snack trays.  I wish your dream of 
the paid staff being the 10% gap filler were true.  I fear that We have 
lost Scott.  That young man toiled under very less than comfortable 
conditions, from My perspective as a retired soldier.

-- 
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported BSOD use by Major Error to msg the enemy!
0
Ron
12/15/2007 1:03:23 AM
On 12/14/2007 7:48 PM, Wayne Mery wrote:
> On 12/14/2007 4:07 PM, Dan Mosedale wrote:
>> David Ascher wrote:
>>> Kent James wrote:
>>>> 2) It really takes dedicated effort in TB to train routinely on ham, 
>>>> but really the main value of a local spam filter is the 
>>>> characterization of ham. Junk is common over many users, but each 
>>>> person has their own unique ham signature. Some methods need to be 
>>>> developed to automatically do this. Maybe, for example, we could 
>>>> consider each message ham that the user replies to.
>>
>>> I like that. I'd also suggest that senders to whom one replies should 
>>> probably be special-cased in the addressbook as well. They're likely 
>>> to be special. It might even make sense to consider some whitelisting 
>>> hints.
>>
>> They're already added to the personal addressbook by default (see the 
>> composition / addressing prefpane), and I think anything in the 
>> personal addressbook is in fact already whitelisted.
>>
>>>> 3) There are now multiple text characterization schemes (starred, 
>>>> junk/nonjunk, tags) that could be unified into a single system, with 
>>>> possible benefits such as expanding Bayesian analysis to 
>>>> determination of tags for example (to say nothing of much-needed 
>>>> refactoring).
>>> Agreed.
>>
>> IIRC, Henry Jia of Sun long ago submitted a patch to generalize the 
>> Bayesian code in some ways. I think the idea may have been to train it 
>> to follow the user's general message filing pattern, rather than just 
>> caring about two ham/spam buckets. It's been a while, though, so I may 
>> be misremembering the details. Searching Bugzilla should turn it up...
>>
>> Dan
> 
> I'm not finding anything of Henry's in bugzilla that is related. I 
> thought I recalled such a thing, but perhaps just a false memory by 
> power of your suggestion :)
> 
> Selected list of enh bugs:

also

Bug 256563 � Implement ... Chung-Kwei (Teiresias) algorithm
  https://bugzilla.mozilla.org/show_bug.cgi?id=256563

0
Wayne
12/15/2007 1:12:30 AM
Mark Banner keyboarded, On 12/14/2007 2:33 PM :
> Eddy Nigg (StartCom Ltd.) wrote:
>> Agreed, so there are different preferred medias for different tasks 
>> as we all know. Discussions on general issues belong to here (mailing 
>> list) whereas communication between developers can be very dynamic 
>> (IM, phone, mailing list or just email). Wiki is good to nail down 
>> decisions, plans, road maps and other such stuff...and than there are 
>> the status meetings (usually by phone) and at last but not least 
>> bugzilla...
>
> I think you've summed it up well here Eddy. The point I'd like to 
> extend is that we should try and be active in getting some of the 
> decisions and ideas here onto wiki or something - especially the ones 
> that are directional. Otherwise decisions get lost in the archives and 
> its harder for folks inside & outside to know what is going on.
>
> Standard8
>


Mark You have hit the nail on the head, (lame metafore) in that we do a 
lot of great idea and concept sharing, but fail to codify it so those 
who follow after us can see where we came from and why we traveled in 
the direction we chose. News archives are just dry, lifeless; words 
uttered as symbolic representations of our inner vision.

-- 
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported BSOD use by Major Error to msg the enemy!
0
Ron
12/15/2007 1:14:50 AM
On 14/12/2007 16:49, Ron K. wrote:

> David Ascher keyboarded, On 12/14/2007 3:28 PM :
>> Ron K. wrote:
>>> Yes, we are fragmented in part because I view the Tb community has 
>>> been forced to adapt to the Firefox business model.
>>
>> Do you really mean business model, or just "firefox community ways"?
> 
> The latter. Tbird has been forced into  the Firefox  style in may ways,  
> Try the add-on site.  All the Tbird add-ons have an install button, not 
> a download  button which would clarify the difference in add-on install 
> procedure, remote versus local. It is this issue that Scott wanted the 
> Tbird community to discuss at the Mozilla Wiki. Only two people 
> responded, I am one of them. So simple question: Why can't we have our 
> own template page so that the Webmaster would use it to setup a new 
> Tbird extension page. I consider this web page issue to be disrespectful 
> of Tbirds status as a Mozilla Foundation sponsored application.
> 

That is a definite problem, judging by the number of people on 
MozillaZine and mozilla.support.thunderbird who cannot figure out why 
the extension(s) they are trying to install state that they are, for 
example, incompatible with Firefox. That latter is, of course, correct, 
but why should the download site offer to install something that cannot 
be installed?

<non-installable words removed>

> 


-- 
John Liebson
0
John
12/15/2007 1:29:19 AM
Gus Richter keyboarded, On 12/14/2007 3:17 PM :
> David Ascher wrote:
>> Eddy Nigg (StartCom Ltd.) wrote:
>>> But since you mentioned last August..what me concerns not much happened
>>> since then. Except if there is somewhere something elsewhere 
>>> maybe....But I'd expect the crowned leader to hang out with the 
>>> right people :-\
>>>   ...or is Thunderbird a ship sailing without a captain to nowhere? 
>>> Somebody knows? I don't so far....
>>>   
>>
>> I can appreciate that people are impatient and want to see a plan in 
>> place now.  At the same time, I know that a deliberative and 
>> collaborative process is a lot more likely to build a true community 
>> with a shared goal than if I just dumped by raw thoughts and declared 
>> them policy.
>>
>> So please be patient -- feel free to poke me as often as you need, 
>> though.
>>
>> I'll contribute more on this newsgroup, and we'll see how things evolve.
>>
>> --david
>
> Lots of good stuff mentioned, but it may be worthwhile to mention that 
> the basic function of Thunderbird is to be used to communicate via 
> e-mail. There are two ways to communicate; text/plain and HTML. While 
> text/plain is working like a charm, the HTML side has been thoroughly 
> neglected and is severely handicapped. I would like to suggest humbly 
> that Thunderbird should learn how to walk before it is asked to run.
>


Yes Gus:  The use of HTML by American commercial interests is essential 
to the profitability of not only the American economy, but also that of 
the globe we live on. The fanaticism of the plian/text purists is not in 
the best interests of electronic commerce where a picture truly is 
"Worth 1,000 words". More than once I have lost out on qualifying for a 
fantastic sales discount for lack of timely notification of a time 
limited offer by a major e-commerce vendor.

-- 
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported BSOD use by Major Error to msg the enemy!
0
Ron
12/15/2007 2:03:43 AM
Wayne Mery wrote:
>> Selected list of enh bugs:
> 
> also
> 
> Bug 256563 � Implement ... Chung-Kwei (Teiresias) algorithm
>  https://bugzilla.mozilla.org/show_bug.cgi?id=256563
> 

Thanks for all of the references. I have some working theories about 
what makes the spam processing tick, plus there has been a lot of 
research about it. I'm just starting to get actual results from Tb spam 
processing on the TREC 2005 spam corpus (thank God for Enron!) so I may 
be able to deal with those bugs, plus ideas of my own. Realistically, if 
the native spam processing in Tb could increase in effectiveness by a 
factor or 2 it would be amazing, yet that still does not completely 
solve the problem. Still, there are some obvious annoyances (like the 
need to retrain) that should be eliminated.

I think I'll start a blog in a day or so for anyone who might be 
interested in my daily encounters with spam processing. But let me make 
observations here for now.

For my initial pass on the TREC 2005 corpus, I divided the roughly 
100,000 emails into 5 groups selected randomly. I trained on one of the 
groups, then analyzed the entire set of emails. With that, I got roughly 
..05% false positives, and 6% false negatives. Looking at a few of the 
false positives, they typically involved only a few tokens that survived 
the initial cuts, usually less than 10. Those tokens usually only had a 
few previous references, say 2-5. The probability calculation used by 
Tb, copied I believe from some of the original articles, uses a formula 
to correct for the limited degrees of freedom available when there are 
only a few samples, but the formula is biased to give stronger 
probabilities than the data predicts. Anyway in my case they are 
over-estimating the value of tokens that are rarely seen, causing the 
false positives.

Using a classic Laplacian prior, calculating the posterior probability p 
of an event (here the probability that an email containing the token is 
spam) with s successes and n trials is done using:

p = (1+s)/(2+n)

so for example, if we see a spam token twice, it calculates 
p=(1+2)/(2+2) = .75

Tb uses the formula:

p = (.225+s)/(.45+n),

which for the same example gives p=.91, overestimating the spam 
prediction of that token. It's these kinds of tokens that are giving me 
some of the false positives I am seeing. The Tb formula was justified in 
some earlier paper based on empirical results. I want to understand what 
that really means. My current hypothesis is that the Tb formula may help 
with getting quick results with limited training, but gives poorer 
results when there are large numbers of training examples. (My initial 
hypotheses are often wrong, BTW)

These mathematical games are fun, but I still think that the UI and 
available information when things aren't working are much more important 
than a few percentage points improvement in detection performance.
0
Kent
12/15/2007 4:00:24 AM
On 15/12/2007 01:55 (CET), Wayne Mery wrote:
>>> Tbird has been forced into the Firefox style in may ways, Try the 
>>> add-on site. All the Tbird add-ons have an install button, not a 
>>> download button which would clarify the difference in add-on install 
>>> procedure, remote versus local. It is this issue that Scott wanted the 
>>> Tbird community to discuss at the Mozilla Wiki. Only two people 
>>> responded, I am one of them. 
>> Do you know the URL by any chance?
> 
> perhaps http://wiki.mozilla.org/Talk:Thunderbird:Extension_Installation

Yes, based on this page of course:

http://wiki.mozilla.org/Thunderbird:Extension_Installation

The original discussions are at:

http://groups.google.com/group/mozilla.dev.apps.thunderbird/browse_frm/thread/e9b08903bf100b29/4560c4e283faebb7
http://groups.google.com/group/mozilla.dev.apps.thunderbird/browse_frm/thread/1dc7f1fc0003b191/6f2218f515a099b2

This is something we probably need to reopen.

- Brian
0
Brian
12/15/2007 11:08:36 AM
Ron K. aber hob zu reden an und schrieb:
> I remember bring able to use the LDAP feature of NC4 to query
> Bigfoot, or any of the other LDAP directory servers, to ferret out my
> younger brothers e-mail address and location in rural Iowa.

Preferences -> Addressing -> Directory Server ?
(But I have no LDAP experience/don' know if that works as it did in NS4.)


Karsten
-- 
Feel free to correct my English. :)
0
ISO
12/15/2007 10:01:51 PM
David Ascher wrote:
> I find the RSS UI in Thunderbird just painful enough that it stops me 
> everytime I want to switch to it from Shrook, which is my current RSS 
> reader of choice.  So I've been thinking about what it could become.
> 
> There are some "obvious" problems, which I suspect are in bugzilla 
> already, like:
>  - can't actually use TB as a feed subcriber from Firefox.  - can't drag 
> and drop URLs into the News & Blogs container to have them added
>  - no auto-discovery of feeds from web page URIs
>  - some bugs w/ import of hierarchical OPML files (can't recall details)
>  - in the add dialog, there's a folder per feed, which certainly 
> confused me at first.

	I've always found RSS to be clunky as lego (but much less solid) in 
Thunderbird. Which is a shame because if these rough edges were 
sharpened up it would be so much nicer to utilise.

For me personally, I have a clear idealogy for how I use Thunderbird. TB 
is my 'Pull' client. It always runs in the background and I configure it 
to automatically pull down content I want. This includes my email, 
newsgroups and all my rss feeds. I can check it when I'm free and 
anything available is there waiting for me.

This is compared to 'push'/'realtime' clients, like my web browser and 
my IM app.

I'd hate to see Thunderbird incorporate IM as core functionality - 
because I use another application for that. My experience with trying to 
use the lightening extension is that any pause of delay while loading my 
google-based calendar prevented me from accessing any of my 'pull' 
content. Switching to using Sunbird made that issue go away (of course 
now I just use google calendar directly via my web browser because the 
speed difference is astronomical.

So to sum up, if it were my personal project, TB would be purely a 
'pull' client. No IM, no web browsing, just automatically pulling all 
content I configure it to pull and making it easy for me to view it.

Bed
0
Bed
12/17/2007 8:35:10 AM
> Lots of good stuff mentioned, but it may be worthwhile to mention that 
> the basic function of Thunderbird is to be used to communicate via 
> e-mail. There are two ways to communicate; text/plain and HTML. While 
> text/plain is working like a charm, the HTML side has been thoroughly 
> neglected and is severely handicapped. I would like to suggest humbly 
> that Thunderbird should learn how to walk before it is asked to run.

I agree with this notion 100%. TB is 'pretty good' at what it does, 
overall. But large chunks of functionality is just 'average' - it does 
the job, but not nicely or smoothly.

If we focus on doing what it does now - but doing it BETTER, EASIER, 
FASTER, more RELIABlY - then the alternatives will be forced to play 
catchup, like FireFox has done. Its focussed on being a web browser - 
not adding IM functionality.
0
Bed
12/17/2007 8:48:10 AM
Bed wrote:
> For me personally, I have a clear idealogy for how I use Thunderbird. TB 
> is my 'Pull' client. It always runs in the background and I configure it 
> to automatically pull down content I want. This includes my email, 
> newsgroups and all my rss feeds. I can check it when I'm free and 
> anything available is there waiting for me.
>
> This is compared to 'push'/'realtime' clients, like my web browser and 
> my IM app.
>   
This is what you've got now more or less and the majority support a 
different view. *Communication*, *integration* and *sharing* seems to be 
the key words for a new Thunderbird...
> I'd hate to see Thunderbird incorporate IM as core functionality - 
> because I use another application for that. My experience with trying to 
> use the lightening extension is that any pause of delay while loading my 
> google-based calendar prevented me from accessing any of my 'pull' 
> content. Switching to using Sunbird made that issue go away (of course 
> now I just use google calendar directly via my web browser because the 
> speed difference is astronomical.
Interestingly it is exactly this extension which was requested the most 
and makes a real difference for office usage today. If there is a 
performance issue with Lightning than this should be solved differently 
IMO...

-- 
Regards 
 
Signer:  	Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber:  	startcom@startcom.org <xmpp:startcom@startcom.org>
Blog:  	Join the Revolution! <http://blog.startcom.org>
Phone:  	+1.213.341.0390
 

0
Eddy
12/17/2007 11:21:00 AM
Eddy Nigg (StartCom Ltd.) wrote:
> Bed wrote:
>> For me personally, I have a clear idealogy for how I use Thunderbird. 
>> TB is my 'Pull' client. It always runs in the background and I 
>> configure it to automatically pull down content I want. This includes 
>> my email, newsgroups and all my rss feeds. I can check it when I'm 
>> free and anything available is there waiting for me.
>>
>> This is compared to 'push'/'realtime' clients, like my web browser and 
>> my IM app.
>>   
> This is what you've got now more or less and the majority support a 
> different view. *Communication*, *integration* and *sharing* seems to be 
> the key words for a new Thunderbird...
	
	Except I feel there are still many improvements to performance and 
usability that could be made to the existing functionality to make it 
more than *good*, but *exceptional*.

>> I'd hate to see Thunderbird incorporate IM as core functionality - 
>> because I use another application for that. My experience with trying 
>> to use the lightening extension is that any pause of delay while 
>> loading my google-based calendar prevented me from accessing any of my 
>> 'pull' content. Switching to using Sunbird made that issue go away (of 
>> course now I just use google calendar directly via my web browser 
>> because the speed difference is astronomical.
> Interestingly it is exactly this extension which was requested the most 
> and makes a real difference for office usage today. If there is a 
> performance issue with Lightning than this should be solved differently 
> IMO...

	To be fair, the performance issues I had with Lightning were more to do 
with using remote google calendars and having to pull back events from 
google's servers constantly.

0
Bed
12/17/2007 11:31:01 AM
This is a cryptographically signed message in MIME format.

--------------ms010203020903090409030101
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Bed wrote:
> Eddy Nigg (StartCom Ltd.) wrote:
>> Interestingly it is exactly this extension which was requested the most 
>> and makes a real difference for office usage today. If there is a 
>> performance issue with Lightning than this should be solved differently 
>> IMO...
>>     
>
> 	To be fair, the performance issues I had with Lightning were more to do 
> with using remote google calendars and having to pull back events from 
> google's servers constantly.
>
>   
Ohoom...didn't you asked for more pulling than pushing? ;-)

-- 
Regards 
 
Signer:  	Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber:  	startcom@startcom.org <xmpp:startcom@startcom.org>
Blog:  	Join the Revolution! <http://blog.startcom.org>
Phone:  	+1.213.341.0390
 


--------------ms010203020903090409030101
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYCDCC
B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI
EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD
VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0
MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy
YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh
dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy
ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz
eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA
IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O
U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj
eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u
xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud
DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx
tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE
BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0
eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G
CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0
YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp
oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6
Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5
BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y
Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50
ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX
TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z
KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls
YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC
AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl
cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo
dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0
cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw
Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H
yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa
v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0
4STurMCFwLoyx5k1rDHQYTCCCEYwggcuoAMCAQICAwFCwTANBgkqhkiG9w0BAQUFADCBrzEL
MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj
MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t
IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz
dGFydGNvbS5vcmcwHhcNMDcwMzE3MjMxNTU0WhcNMDgwMzE2MjMxNTU0WjCBnjELMAkGA1UE
BhMCSUwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSwwKgYDVQQL
EyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRlIE1lbWJlcjESMBAGA1UEAxMJRWRkeSBO
aWdnMSUwIwYJKoZIhvcNAQkBFhZlZGR5X25pZ2dAc3RhcnRjb20ub3JnMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqsN7vhA4tfdpEuEcHG5Y+9Eb8NKB7uPMw5I1FtP61awH
rIGcX4llWxe7edM54HwhVdo4fTdj/Q4yUr0FMEKw7FMcjUp5EEshJ13kRkIoxu0bAc/ttx4g
7UeJtNx7gl5rS8mq667CHIrk9A6Np5oCrN7e9IuDHUy8Ng8LEYCMtCgmDcg5yWFdZWi0KQyB
RR+2O8//GFCr36iuQXO6YO5MCtUZ5mSEHn+j1EiCb8mpyqvhgiR06/AeNzC0iEHWy3sc2fR6
kf2ZZgm02MO1yQa4N2Xi4sYGGcFPdJwrGYHqPDrGX/NHMOD+EHqNk/BVTe9Nzv7p0mNlYoD3
1DNwWwqdVwIDAQABo4IEeDCCBHQwDAYDVR0TBAUwAwIBADALBgNVHQ8EBAMCBLAwHQYDVR0l
BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBT0z3nrjzJgL1eGYOaY2/HWJGfl
yjCB3QYDVR0jBIHVMIHSgBQErNskd1NGRpZfFwFcfUJHvUgZCKGBtqSBszCBsDELMAkGA1UE
BhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UEBxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNT
TCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRj
b20ub3JnggEKMIIBQAYDVR0gBIIBNzCCATMwggEvBgsrBgEEAYG1NwEBAzCCAR4wNQYIKwYB
BQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRlcm1lZGlhdGUucGRmMC8GCCsG
AQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjCBswYIKwYBBQUH
AgIwgaYwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGNTGltaXRlZCBMaWFiaWxpdHksIHJlYWQg
dGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlm
aWNhdGlvbiBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9w
b2xpY3kucGRmMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9j
cnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwu
Y3JsMIGEBggrBgEFBQcBAQR4MHYwNwYIKwYBBQUHMAGGK2h0dHA6Ly9vY3NwLnN0YXJ0Y29t
Lm9yZy9zdWIvY2xhc3MzL3VzZXIvY2EwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jZXJ0LnN0YXJ0
Y29tLm9yZy9zdWIuY2xhc3MzLnVzZXIuY2EuY3J0MBEGCWCGSAGG+EIBAQQEAwIFoDAxBglg
hkgBhvhCAQ0EJBYiU3RhcnRDb20gVHJ1c3RlZCBFbWFpbCBDZXJ0aWZpY2F0ZTAyBglghkgB
hvhCAQQEJRYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwNQYJYIZIAYb4
QgEDBCgWJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMDIGCWCGSAGG
+EIBCAQlFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAjBgNVHRIEHDAa
hhhodHRwOi8vY2VydC5zdGFydGNvbS5vcmcwDQYJKoZIhvcNAQEFBQADggEBAIvystykKhj0
Z5kss+428amoenAL8rJ+oHf6L+H84aQxxKBhF5ygrfpBMRumuaIoMHuC9KIfB+UK2wK5svBX
/5bbhJ4dswjbBIJSUk8+Jr1ypxUgSevsg48e8eIq91hmf1VeXh/ILKVtHhkMCiSM1JoFLWbr
ZQxSDVeyH28b9wCkGNTQsokWRK6MwRrJB89ILUPr/aJmtS6CZMlUIlP01vXLozcnZowR/vQd
n0ueIS2DDTyYo+jiaqXfSdDQLxIg5arCf4OaenEk3PqwZmil9iW+OdfMe8r6G7Wix+8U8Mde
mRHv9kIjd0ZwVnrCKaw0ZI2faLwwAIVYHtPKzbV+6V8wgghGMIIHLqADAgECAgMBQsEwDQYJ
KoZIhvcNAQEFBQAwga8xCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xIzAhBgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8w
LQYDVQQDEyZTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqG
SIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnMB4XDTA3MDMxNzIzMTU1NFoXDTA4MDMxNjIz
MTU1NFowgZ4xCzAJBgNVBAYTAklMMQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIx
EjAQBgNVBAMTCUVkZHkgTmlnZzElMCMGCSqGSIb3DQEJARYWZWRkeV9uaWdnQHN0YXJ0Y29t
Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKrDe74QOLX3aRLhHBxuWPvR
G/DSge7jzMOSNRbT+tWsB6yBnF+JZVsXu3nTOeB8IVXaOH03Y/0OMlK9BTBCsOxTHI1KeRBL
ISdd5EZCKMbtGwHP7bceIO1HibTce4Jea0vJquuuwhyK5PQOjaeaAqze3vSLgx1MvDYPCxGA
jLQoJg3IOclhXWVotCkMgUUftjvP/xhQq9+orkFzumDuTArVGeZkhB5/o9RIgm/Jqcqr4YIk
dOvwHjcwtIhB1st7HNn0epH9mWYJtNjDtckGuDdl4uLGBhnBT3ScKxmB6jw6xl/zRzDg/hB6
jZPwVU3vTc7+6dJjZWKA99QzcFsKnVcCAwEAAaOCBHgwggR0MAwGA1UdEwQFMAMCAQAwCwYD
VR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU9M95
648yYC9XhmDmmNvx1iRn5cowgd0GA1UdIwSB1TCB0oAUBKzbJHdTRkaWXxcBXH1CR71IGQih
gbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0
MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFDQSBBdXRob3JpdHkgRGVwLjEp
MCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxITAfBgkqhkiG9w0B
CQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASCATcwggEzMIIBLwYLKwYBBAGB
tTcBAQMwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJt
ZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGlj
eS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBjUxpbWl0ZWQg
TGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhl
IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2Vy
dC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2Vy
dC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNv
bS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2MDcGCCsGAQUFBzABhitodHRw
Oi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2VyL2NhMDsGCCsGAQUFBzAChi9o
dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51c2VyLmNhLmNydDARBglghkgB
hvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29tIFRydXN0ZWQgRW1haWwgQ2Vy
dGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jYS1j
cmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMt
Y3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGlj
eS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnMA0GCSqGSIb3DQEB
BQUAA4IBAQCL8rLcpCoY9GeZLLPuNvGpqHpwC/KyfqB3+i/h/OGkMcSgYRecoK36QTEbprmi
KDB7gvSiHwflCtsCubLwV/+W24SeHbMI2wSCUlJPPia9cqcVIEnr7IOPHvHiKvdYZn9VXl4f
yCylbR4ZDAokjNSaBS1m62UMUg1Xsh9vG/cApBjU0LKJFkSujMEayQfPSC1D6/2iZrUugmTJ
VCJT9Nb1y6M3J2aMEf70HZ9LniEtgw08mKPo4mql30nQ0C8SIOWqwn+DmnpxJNz6sGZopfYl
vjnXzHvK+hu1osfvFPDHXpkR7/ZCI3dGcFZ6wimsNGSNn2i8MACFWB7Tys21fulfMYIELDCC
BCgCAQEwgbcwga8xCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xIzAhBgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYD
VQQDEyZTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3
DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnAgMBQsEwCQYFKw4DAhoFAKCCAkkwGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcxMjE3MTIwODUwWjAjBgkqhkiG
9w0BCQQxFgQUc68sjssr1Tt1kPhPnlMl1OeUvvYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgcgGCSsGAQQBgjcQBDGBujCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklz
cmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmlj
YXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBG
cmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwFCwTCBygYLKoZI
hvcNAQkQAgsxgbqggbcwga8xCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xIzAhBgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5n
MS8wLQYDVQQDEyZTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8G
CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnAgMBQsEwDQYJKoZIhvcNAQEBBQAEggEA
O2VmQYji6EuxtSLdnXAC8CVabTq0GlK6/6d2vO4I+dtwjWz0+X8URug8vNBjOIBpxhdVh5Xc
3/6a5XlJHnOZDA9ApX05FR2JQBRegL56Ntol7jHSCrjn+gum0abvGBbYuZPtNKkYRU9KIG2W
xCE2lpuZe08xM7rlezqx3F9uYp3I4+jHhXRF4aqyQqX9MYuYpA5y/iHCCZe0dXFoJr5yAC8m
0ZXi87iUkiUG1Rs2r5vw1KS05xYqMiDJZDBzCV3vKi9efggfh1jutl1BUDHPx+MIE3ULtT1d
sXOdp2PWQnXsDOyC9Sx/5eOCau0L0qznxsyqciWlWWUgEKAJpTI1sQAAAAAAAA==
--------------ms010203020903090409030101--
0
Eddy
12/17/2007 12:08:50 PM
Eddy Nigg (StartCom Ltd.) wrote:
> Bed wrote:
>> Eddy Nigg (StartCom Ltd.) wrote:
>>> Interestingly it is exactly this extension which was requested the 
>>> most and makes a real difference for office usage today. If there is 
>>> a performance issue with Lightning than this should be solved 
>>> differently IMO...
>>>     
>>
>>     To be fair, the performance issues I had with Lightning were more 
>> to do with using remote google calendars and having to pull back 
>> events from google's servers constantly.
>>
>>   
> Ohoom...didn't you asked for more pulling than pushing? ;-)

Aaah yes indeed :D

Actually that was the problem - if the google cal provider automatically 
pulled (ie synced) events, rather than being 'ondemand' it probably 
would've worked better.


0
Bed
12/17/2007 12:20:06 PM
Bed wrote:
> So to sum up, if it were my personal project, TB would be purely a 
> 'pull' client.

In a time where the borders between pull and push are getting more and 
more diffuse (the traditional pull service email e.g. goes popular as a 
push service in Blackberry devices, etc.) I don't think it makes much 
sense to try to restrict an app to one of those concepts. I think what 
users want is more important than such theoretical concepts behind the 
scenes.

Robert Kaiser

0
Robert
12/17/2007 1:06:08 PM
Bed wrote:
>
> Actually that was the problem - if the google cal provider automatically 
> pulled (ie synced) events, rather than being 'ondemand' it probably 
> would've worked better.
>
>   
Agreed! Or alternatively TB would push the events regularly, something I 
haven't seen working really in any case. Pull works, push not so...

-- 
Regards 
 
Signer:  	Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber:  	startcom@startcom.org <xmpp:startcom@startcom.org>
Blog:  	Join the Revolution! <http://blog.startcom.org>
Phone:  	+1.213.341.0390
 

0
Eddy
12/17/2007 1:21:56 PM
David Ascher wrote:
> I phrase the choice of what goes in the product vs. what should be an 
> extension slightly differently. 
> The distinction is important.  In particular, I don't subscribe to the 
> notion of Thunderbird being defined as "the most lightweight mail/news 
> client possible, with some extensions available".  I think it's more 
> complicated and changing than that.
> Which isn't to say that I want to take those features out, just that 
> the blend of what features belong in a client like Thunderbird is 
> subject to reconsideration as things change -- as technologies 
> available change, as adoption of different technologies change, as 
> people's habits change.
I take these as to go for a more refined way of dealing with 
extensibility than is now.
First, extension and core can be treated more nuanced by having simply a 
hierarchy or at least importance statements from tb. I mean they are 
treated equally today, with no special reference to lightning vs some 
small functionality tiny extensions, to keep this example, witch is 
wrong as this is a whole new set of functionality and features and may 
become more important in the future.
The idea is to have a way to say what is core, not core but big deal of 
feature, not so big deal but new feature and peripherical improvement or 
small correction. This goes for something like simply a tag for the 
extensions page and some statements in the front page of tb.
I know I didn't got lightning from the beginning and i still am 
wondering why is lost among other stuff, though I may wonder about ltng 
maturity and find my answer..

Conclusion: I would wait for a 'Get TB with Lightning' (as the FF with 
Google tool bar). It's a statement, for tb and lt, more then an ease of 
download, and may be done with a simple link or just indication. It 
shows the features available for tb and confidence in lt. Of course, as 
soon as ltn is considered to be mature enough not to become a drawback ...
>  There is _huge_ opportunity for Thunderbird to become more than a 
> good mailnews client that a few million people use.
> We won't do that by just being a mail/news client.  We need to think 
> of the system in a different way.
Yes, but is doable beginning from mail client. Look at gmail that is 
trying to gather all talk and cal and docks in one place. And yahoo and 
others the same. The point is that having an UI that grows from the 
classic 'organizing mail' UI may even be the key, cause it's a standard 
and is more likely for people to begin organizing communication from 
mail, cause is probably the most organized one.
On the other hand, let's see the bright side of desktop. Cause the gmail 
and yahoo may very well do the job on the web side and I don't see tb as 
an immediate alternative, but rather as a more settled option. Reasons 
to have desktop comm client may be the offline access and intranet, more 
thorough organization of data along with other local data (files), 
archive and backup, better integration with os and other software and 
more that don't come into mind. Corporate may be another point.
(Some people and most of the students are going for the web interface as 
this is really portable (independent) and see it as a privacy thing 
(like my mail is on the web and no one here in the office has anything 
to do wit it- kinda reverse to what privacy looks like from the 'privacy 
policy on the web' issue). Meaning that they even use web mail for 
personal comm and client for work to keep different behaviors and 
activity separated. Tb portable is not quite the same, but may be an 
answer.)
I would even dear to say that gmail showed what I would call a 
regression or down shifting with the imap methods, from the organizing 
mail point of view. They are matching those virtual folders for the real 
ones, witch shows how slow can be to propose new improved ways to people 
over the habits or standards. But this is for the next paragraph..

Conclusion: If th AB is to be the core of the change (and is a deep 
one), TB is to be the UI (and the most natural).

I plead for migration towards what you are looking for from what you 
already have. And not for the legacy kind of approach, but cause it 
seams right. Think reverse way, you are allowing to discuss 'comm hub' 
cause you start from a mail app and if you were to begin from an im or 
rss or other soft it would seam like too much or unrealistic. The thing 
is that a software that organizes mail leads to organizing the other 
channels cause mail is still the most well defined media (standard), or 
just cause is the way people behave (mail is older..). And leaded you to 
the idea. And the same, if today you help with an _UI to organize the 
mail_ and the desktop, the web or other remote info should land here 
when naturally people will find that this is the best way, witch means 
inviting and the future.
> We have a mindshare and impact because of Mozilla and Firefox's 
> success that we should use to our best advantage.  Let's not squander it.
Communicate, promote, but teach people. Teach means sometimes just to 
say something, but in the right place/time/audience. And always should 
lead to learning (these threads are such a good example).
(The example of Gmail imap to use folders for virtual folders may show 
that they are making a compromise with the most common user behavior (be 
it habit or soft standard, no matter..) and go for a slower 'teaching 
people' into something. )
Other things that go in circles:
Want more contributors?
1.get more users. There may be some dev at the door, but there may be a 
scale/critical mass thing. (FF more users, ff more extensions..)
2.want more users, get a pole. But make sure is reaching as many as 
possible and as simply as 123. It should show if they use tb, who they 
are, but also why, how got here, what they want, how thy organize comm 
data.. This would show that you care
3.show a different approach, attract more than IT or dev. There is this 
thing with open soft witch may be intimidating, cause is viewed as soft 
only, or geek only. There may be others that don't even know that they 
can help, or not even going for 'How can I help' because of this 
prejudice (so many places to improve, support, doc, dictionaries, etc 
etc). A more organized way of dealing with contributions may be a + and 
may help attractor people from various fields. And also for one to 
evaluate his/hers place in it.

For example, should I post this here, or just watch, or should I just 
mind my own business ? (but really, I hesitated and still not sure if 
only interfering or waisting time of people with this outsider's 
comments) There could be rules of collaboration including those not dev, 
even if in a subtle way, thru guidance ..

By saying that I'll stop, cause, anyway, to define directions and solid 
future is the most important here and also for communication, building 
trust, etc
0
ovidiu
12/17/2007 1:43:07 PM
Bed keyboarded, On 12/17/2007 3:48 AM :
>
>> Lots of good stuff mentioned, but it may be worthwhile to mention 
>> that the basic function of Thunderbird is to be used to communicate 
>> via e-mail. There are two ways to communicate; text/plain and HTML. 
>> While text/plain is working like a charm, the HTML side has been 
>> thoroughly neglected and is severely handicapped. I would like to 
>> suggest humbly that Thunderbird should learn how to walk before it is 
>> asked to run.
>
> I agree with this notion 100%. TB is 'pretty good' at what it does, 
> overall. But large chunks of functionality is just 'average' - it does 
> the job, but not nicely or smoothly.
>
> If we focus on doing what it does now - but doing it BETTER, EASIER, 
> FASTER, more RELIABlY - then the alternatives will be forced to play 
> catchup, like FireFox has done. Its focussed on being a web browser - 
> not adding IM functionality.

Neither Tb or Fx are adding IM functionality.  One can have IM by 
insytalling an add-on called Same Place the uses the open souce 
Jabber/XMPP protocols.  Same Place resides in a left side flyout sidebar 
which is available as needed without requiring a new window the way 
Chatzilla does on Fx.

Your comments on pull are relative.  I can make a point that Tb is a 
"Push" product.  I write a message and I have to push it to get it off 
my system so it can land on the server you pull from.

-- 
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported BSOD use by Major Error to msg the enemy!
0
Ron
12/17/2007 2:12:03 PM
ovidiu wrote:
> Conclusion: I would wait for a 'Get TB with Lightning' (as the FF with 
> Google tool bar). It's a statement, for tb and lt, more then an ease of 
> download, and may be done with a simple link or just indication. It 
> shows the features available for tb and confidence in lt. 
I would agree with that statement.
> For example, should I post this here, or just watch, or should I just 
> mind my own business ? (but really, I hesitated and still not sure if 
> only interfering or waisting time of people with this outsider's 
> comments) There could be rules of collaboration including those not dev, 
> even if in a subtle way, thru guidance ..
You aren't waisting anybodies time here (whoever doesn't want to read a 
post can look away anyway). So your post was somewhat extensive I 
believe that an "outsider" view is as important (if not sometimes more) 
than that of the insiders. Thanks for your time!

-- 
Regards 
 
Signer:  	Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber:  	startcom@startcom.org <xmpp:startcom@startcom.org>
Blog:  	Join the Revolution! <http://blog.startcom.org>
Phone:  	+1.213.341.0390
 

0
Eddy
12/17/2007 8:47:29 PM
David Ascher keyboarded, On 12/14/2007 6:58 PM :
> Ron K. wrote:
>> Tbird has been forced into  the Firefox  style in may ways,  Try the 
>> add-on site.  All the Tbird add-ons have an install button, not a 
>> download  button which would clarify the difference in add-on install 
>> procedure, remote versus local. It is this issue that Scott wanted 
>> the Tbird community to discuss at the Mozilla Wiki. Only two people 
>> responded, I am one of them. 
>
> Do you know the URL by any chance?

Sorry for the slow response, been a doggy weekend.  The direct link 
<http://wiki.mozilla.org/Thunderbird:Extension_Installation>

>> So simple question: Why can't we have our own template page so that 
>> the Webmaster would use it to setup a new Tbird extension page. I 
>> consider this web page issue to be disrespectful of Tbirds status as 
>> a Mozilla Foundation sponsored application.
>>   
>
> The extension experience (for authors and users) is an issue that I 
> want MailCo to tackle soon.  It's one of those problems which isn't 
> technically super hard, but which needs someone to figure out what all 
> the bits should be.  For example, things get a bit complicated when 
> you realize that some extensions should be installable with a 
> one-click in Seamonkey, but shouldn't be installed in Firefox, etc.  
> It's workable, but it needs to be someone's priority.  NB: This kind 
> of problem is _exactly_ why MailCo is being created, and why one of 
> the roles I'm looking for is someone who can be the extensions 
> lead/evangelist.

You may find the link plays into this. And a side note:  Seems that with 
the revisions the Fx team made to the extension manager that the Mr Tech 
Local Install add-on no longer archives updates because they are being 
directly applied during diring Fx and Tb start up.

>> LOL, I am being bombarded with terms right out of the Harry Potter 
>> wizards manual.  Pray tell, how does a purple library relate to Tbird.
>>   
>
> Sorry, forgot to give background: libpurple is a cross-IM client 
> library which is part of Pidgin (n�e Gaim).
> -david


-- 
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported BSOD use by Major Error to msg the enemy!
0
Ron
12/18/2007 3:24:20 AM
Eddy Nigg (StartCom Ltd.) wrote:
> ovidiu wrote:
>> For example, should I post this here, or just watch, or should I just 
>> mind my own business ? (but really, I hesitated and still not sure if 
>> only interfering or waisting time of people with this outsider's 
>> comments) There could be rules of collaboration including those not 
>> dev, even if in a subtle way, thru guidance ..
> You aren't waisting anybodies time here (whoever doesn't want to read 
> a post can look away anyway). So your post was somewhat extensive I 
> believe that an "outsider" view is as important (if not sometimes 
> more) than that of the insiders. Thanks for your time!
Thanks for that. I may just have let myself carried away beyond the 
point of the post and the point of the example, in the way I expressed 
that (you know, subliminal..). And yes, the post is extensive, at least 
for a brainstorming, witch is for the inner idea to suffer. Bud I'd say 
that besides being really pleased by the responsiveness of moz-tb 
generally (support,etc), I'm  wondering  about  how to channel such 
energy in a more effective way.
Thanks again.
0
ovidiu
12/18/2007 11:15:13 AM
On 2007-12-14 03:22, Joshua Cranmer wrote:
> With respect to TB, these are my preferences:
> * The wiki would be used to inform developers of extensions or as a 
> springboard for would-be developers of TB.
> * The web forum is a support channel for people who need help with TB.
> * IRC has a few channels:
> @ Support, a la web forum
> @ Developer information, like #developers or #maildev
> @ A planning channel for when two people need to have instantaneous 
> communication.
> * Newsgroup or mailing list (prefers newsgroup): main method of 
> communicating planning decisions.
> * Bugzilla would be used as it is now, for detailing bugs and 
> works-in-progress
> * Blogs would be used mostly for announcing decisions, such as 
> resolutions on a newsgroup/mailing list debate
> * Where to put RFEs? Newsgroup (like mozilla.wishlist), Bugzilla, or Web 
> forum? There should be one standard place; ideally, it would be 
> cross-referable so that all interested parties would know about them.

This list sounds pretty good to me, and may I say I'm glad to see all the recent 
discussion here! I'd certainly support using this newsgroup/list for more 
general level discussion and planning and using wikis for the documentation and 
detailed plans. I recall the firefox3 brainstorming wiki-page got huge amounts 
of publicity, not sure how much substance they got out of it though.

At the moment RFEs are a bit spread out, but I don't see that changing, since 
the entry level is a quite different. We have a lot of RFEs in bugzilla so it's 
not so easy for a newcomer to file something useful that isn't a dupe - and 
filing an RFE in bugzilla for something general level is usually quite pointless.

  -Magnus


0
Magnus
12/18/2007 5:12:34 PM
Magnus Melin wrote:
> At the moment RFEs are a bit spread out, but I don't see that changing, since 
> the entry level is a quite different. We have a lot of RFEs in bugzilla so it's 
> not so easy for a newcomer to file something useful that isn't a dupe - and 
> filing an RFE in bugzilla for something general level is usually quite pointless.
>   
I find that bugzilla is a lousy place to _discuss_ RFEs anyway, because 
it's so hard to create an evolving "spec" that doesn't require people to 
re-read the entire discussion each time. 

I wonder if it would make sense to take the RFEs in bugzilla, create 
wiki pages for them, where they can be discussed (in the Talk pages) and 
refined, and as they are finalized, create new bugs to track the 
development of those RFEs. 

--david
0
David
12/18/2007 6:20:13 PM
David Ascher wrote:
>   
> I find that bugzilla is a lousy place to _discuss_ RFEs 
> --david

One thing I've always been impressed with about the whole Mozilla 
development environment is the traceability. I can pull up code using 
lxr, see the history of changes of each line of code using CVS BLAME, 
and then trace that back to its discussion on bugzilla. Any method 
changes that you propose should consider those who come after us, who 
will have to figure out what we did and why.
0
Kent
12/18/2007 6:42:51 PM
Kent James wrote:
> David Ascher wrote:
>   
>>   
>> I find that bugzilla is a lousy place to _discuss_ RFEs 
>> --david
>>     
>
> One thing I've always been impressed with about the whole Mozilla 
> development environment is the traceability. I can pull up code using 
> lxr, see the history of changes of each line of code using CVS BLAME, 
> and then trace that back to its discussion on bugzilla. Any method 
> changes that you propose should consider those who come after us, who 
> will have to figure out what we did and why.
>
>   
Agreed -- but wikis have history pages and revision history, so I think 
traceability is pretty good there.

--david

0
David
12/18/2007 10:10:37 PM
On 12/18/2007 5:10 PM, David Ascher wrote:
> Kent James wrote:
>> David Ascher wrote:
>>> I find that bugzilla is a lousy place to _discuss_ RFEs --david
>>
>> One thing I've always been impressed with about the whole Mozilla 
>> development environment is the traceability. I can pull up code using 
>> lxr, see the history of changes of each line of code using CVS BLAME, 
>> and then trace that back to its discussion on bugzilla. Any method 
>> changes that you propose should consider those who come after us, who 
>> will have to figure out what we did and why.
>>
> Agreed -- but wikis have history pages and revision history, so I think 
> traceability is pretty good there.
> 
> --david
> 

wiki is good for depicting relationships, summarizing and organizing 
things discussed elsewhere, "lists" of <whatever>. traceability is 
definitely there, if the page is kept.  not good for discussion.

news good for discussion, if organized, i.e. with purpose and 
self-control (but even then can get unwieldy for some). traceability is 
there too.

relegate bugzilla to working through the technical issues of 
implementation and code.

0
Wayne
12/18/2007 11:22:50 PM
Magnus Melin keyboarded, On 12/18/2007 12:12 PM :
> On 2007-12-14 03:22, Joshua Cranmer wrote:
>> With respect to TB, these are my preferences:
>> * The wiki would be used to inform developers of extensions or as a 
>> springboard for would-be developers of TB.
>> * The web forum is a support channel for people who need help with TB.
>> * IRC has a few channels:
>> @ Support, a la web forum
>> @ Developer information, like #developers or #maildev
>> @ A planning channel for when two people need to have instantaneous 
>> communication.
>> * Newsgroup or mailing list (prefers newsgroup): main method of 
>> communicating planning decisions.
>> * Bugzilla would be used as it is now, for detailing bugs and 
>> works-in-progress
>> * Blogs would be used mostly for announcing decisions, such as 
>> resolutions on a newsgroup/mailing list debate
>> * Where to put RFEs? Newsgroup (like mozilla.wishlist), Bugzilla, or 
>> Web forum? There should be one standard place; ideally, it would be 
>> cross-referable so that all interested parties would know about them.
>
> This list sounds pretty good to me, and may I say I'm glad to see all 
> the recent discussion here! I'd certainly support using this 
> newsgroup/list for more general level discussion and planning and 
> using wikis for the documentation and detailed plans. I recall the 
> firefox3 brainstorming wiki-page got huge amounts of publicity, not 
> sure how much substance they got out of it though.
>
> At the moment RFEs are a bit spread out, but I don't see that 
> changing, since the entry level is a quite different. We have a lot of 
> RFEs in bugzilla so it's not so easy for a newcomer to file something 
> useful that isn't a dupe - and filing an RFE in bugzilla for something 
> general level is usually quite pointless.
>
>  -Magnus
>
>


We get a *lot* of RFE's in news://news/mozilla.support.thunderbird as 
well as "Bug" reports from people who think that support group is manned 
by Mozilla software types.  Support also get a quite a bit of OT 
requests like why does my attached CSS,HTML, JS, or XHTML not work. 
Personally I never use forums for support, the format is too cumbersome 
and threading is non-existant.  IRC might work if it was a private 
standalone server. An RSS feed would be usefull  if it agregated the 
Wiki, Mozillazine  home page, Tb blogs, etc.

Currently we refer people to Bugzilla from Tb support if a thread 
indicated that is the best resolution for future fix. That is less than 
40% follow through, so lots of RFE's are lost . One complaint is 
Bugzilla is too intimidating.

-- 
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported BSOD use by Major Error to msg the enemy!
0
Ron
12/19/2007 4:28:05 AM
On 12/18/07 5:10 PM, _David Ascher_ spoke thusly:
> Kent James wrote:
>> David Ascher wrote:
>>  
>>>   I find that bugzilla is a lousy place to _discuss_ RFEs --david
>>>     
>>
>> One thing I've always been impressed with about the whole Mozilla 
>> development environment is the traceability. I can pull up code using 
>> lxr, see the history of changes of each line of code using CVS BLAME, 
>> and then trace that back to its discussion on bugzilla. Any method 
>> changes that you propose should consider those who come after us, who 
>> will have to figure out what we did and why.
>>
>>   
> Agreed -- but wikis have history pages and revision history, so I think 
> traceability is pretty good there.

I don't think that was the point Kent was making. CVS commits in Mozilla 
usually cite a bug number, not a wiki page.

I find wikis good for documents, but not discussion. I agree that 
bugzilla is lousy for discussion, but I think wikis are worse.
-- 
Chris Ilias <http://ilias.ca>
List-owner: support-firefox, support-thunderbird, test-multimedia
0
Chris
12/19/2007 6:32:56 AM
Chris Ilias wrote:
> 
> I find wikis good for documents, but not discussion. I agree that 
> bugzilla is lousy for discussion, but I think wikis are worse.

It's sort of ironic that we, who are trying to set the pace for the 
world in communication, cannot recommend an environment that makes sense 
for collaboration. I wonder if there are some lessons to learn here, 
about perhaps what should be important directions for Thunderbird?

In one of the other contexts where I work, I am pushing SharePoint 
pretty hard on an organization for collaboration. Yet it is also a lousy 
way to collaborate in many ways. There are too many contexts for 
comment, that do not get readily tied together. It's all too easy for 
users to just throw up their hands, and revert to the Standard Method of 
collaboration: reply-to-all email, quoting the entire thread in each 
email and top posting. That actually works surprisingly well for most 
people, and probably carries over half of the world's collaboration.

Kent
0
Kent
12/19/2007 7:07:42 AM
Kent James keyboarded, On 12/19/2007 2:07 AM :
> Chris Ilias wrote:
>>
>> I find wikis good for documents, but not discussion. I agree that 
>> bugzilla is lousy for discussion, but I think wikis are worse.
>
> It's sort of ironic that we, who are trying to set the pace for the 
> world in communication, cannot recommend an environment that makes 
> sense for collaboration. I wonder if there are some lessons to learn 
> here, about perhaps what should be important directions for Thunderbird?
>
> In one of the other contexts where I work, I am pushing SharePoint 
> pretty hard on an organization for collaboration. Yet it is also a 
> lousy way to collaborate in many ways. There are too many contexts for 
> comment, that do not get readily tied together. It's all too easy for 
> users to just throw up their hands, and revert to the Standard Method 
> of collaboration: reply-to-all email, quoting the entire thread in 
> each email and top posting. That actually works surprisingly well for 
> most people, and probably carries over half of the world's collaboration.
>
> Kent

A reason Netscape named the News portion of the Communicator 4.x suite 
Collabra was a view to news being a collaberation solution.  Mial based  
discussion here withe the MailMan interface Mozilla.Org is using  
produced spotty results.  David's postings are the only ones showing 
both in the news group and dropping into my e-mail.  I am not subscribed 
to the list-serv.  With that spotty communication  I am only getting his 
side of content others reply to David by the list.

-- 
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported BSOD use by Major Error to msg the enemy!
0
Ron
12/19/2007 6:04:10 PM
Chris Ilias wrote:
> On 12/18/07 5:10 PM, _David Ascher_ spoke thusly:
>   
>> Kent James wrote:
>>     
>>> David Ascher wrote:
>>>  
>>>       
>>>>   I find that bugzilla is a lousy place to _discuss_ RFEs --david
>>>>     
>>>>         
>>> One thing I've always been impressed with about the whole Mozilla 
>>> development environment is the traceability. I can pull up code using 
>>> lxr, see the history of changes of each line of code using CVS BLAME, 
>>> and then trace that back to its discussion on bugzilla. Any method 
>>> changes that you propose should consider those who come after us, who 
>>> will have to figure out what we did and why.
>>>
>>>   
>>>       
>> Agreed -- but wikis have history pages and revision history, so I think 
>> traceability is pretty good there.
>>     
>
> I don't think that was the point Kent was making. CVS commits in Mozilla 
> usually cite a bug number, not a wiki page.
>
> I find wikis good for documents, but not discussion. I agree that 
> bugzilla is lousy for discussion, but I think wikis are worse.
>   
All this feedback is great.  I'm happy to be more mailing list centric 
than I'd usually be, and to see how it works in practice.

My current thinking is:

  - we use wikis to _describe_ what the feature should "look like"
  - we _discuss_ them on the mailing list
  - we _update_ the wikis with revised version as per the results of the 
discussion
  - we mention the updates on the mailing list, to let people know when 
those changes happen
  - we create bugs to track implementation of features, and the bugs can 
point back to the wiki pages to describe the "spec"
  - checkins refer to bugs, as always.

sounds about right?

--david

0
David
12/19/2007 7:12:13 PM
On 12/19/07 1:04 PM, _Ron K._ spoke thusly:
> A reason Netscape named the News portion of the Communicator 4.x suite 
> Collabra was a view to news being a collaberation solution.  Mial based  
> discussion here withe the MailMan interface Mozilla.Org is using  
> produced spotty results.  David's postings are the only ones showing 
> both in the news group and dropping into my e-mail.  I am not subscribed 
> to the list-serv.  With that spotty communication  I am only getting his 
> side of content others reply to David by the list.

If you're not subscribed to the mailing list, you shouldn't be getting 
messages from this newsgroup in your mailbox. The reason why you're 
receiving David's messages via email, is because he's sending his 
replies to the address of the person he is replying to, in addition to 
the mailing list address (ie. Reply All). I don't think the 
dev-apps-thunderbird mailing list is set to add the mailing list address 
to the reply-to header of each post; so Reply All is a quick/easy way of 
replying to the list.

What I'm saying is, it has nothing to do with Thunderbird, unless bug 
45715 is fixed. :-)

IMO, for discussions, nothing beats newsgroups. But I suppose that would 
be popular opinion in *here*. Those who prefer a different technology, 
are likely to be using a different technology. As long as people are 
willing to use different communications technologies, this shouldn't be 
an issue.
-- 
Chris Ilias <http://ilias.ca>
List-owner: support-firefox, support-thunderbird, test-multimedia
0
Chris
12/19/2007 8:28:11 PM
David Ascher wrote:
> All this feedback is great.  I'm happy to be more mailing list centric 
> than I'd usually be, and to see how it works in practice.
>
> My current thinking is:
>
>   - we use wikis to _describe_ what the feature should "look like"
>   - we _discuss_ them on the mailing list
>   - we _update_ the wikis with revised version as per the results of the 
> discussion
>   - we mention the updates on the mailing list, to let people know when 
> those changes happen
>   - we create bugs to track implementation of features, and the bugs can 
> point back to the wiki pages to describe the "spec"
>   - checkins refer to bugs, as always.
>
> sounds about right?
This is exactly how it should be!

-- 
Regards 
 
Signer:  	Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber:  	startcom@startcom.org <xmpp:startcom@startcom.org>
Blog:  	Join the Revolution! <http://blog.startcom.org>
Phone:  	+1.213.341.0390
 

0
Eddy
12/19/2007 8:36:01 PM
On 12/19/07 2:12 PM, _David Ascher_ spoke thusly:
> My current thinking is:
> 
>  - we use wikis to _describe_ what the feature should "look like"
>  - we _discuss_ them on the mailing list
>  - we _update_ the wikis with revised version as per the results of the 
> discussion
>  - we mention the updates on the mailing list, to let people know when 
> those changes happen
>  - we create bugs to track implementation of features, and the bugs can 
> point back to the wiki pages to describe the "spec"
>  - checkins refer to bugs, as always.
> 
> sounds about right?

Yup. As long as everything is traceable.
-- 
Chris Ilias <http://ilias.ca>
List-owner: support-firefox, support-thunderbird, test-multimedia
0
Chris
12/19/2007 8:38:43 PM
This is a cryptographically signed message in MIME format.

--------------ms020201050505060206080200
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Chris Ilias wrote:
> On 12/19/07 2:12 PM, _David Ascher_ spoke thusly:
>> My current thinking is:
>>
>>  - we use wikis to _describe_ what the feature should "look like"
>>  - we _discuss_ them on the mailing list
>>  - we _update_ the wikis with revised version as per the results of the 
>> discussion
>>  - we mention the updates on the mailing list, to let people know when 
>> those changes happen
>>  - we create bugs to track implementation of features, and the bugs can 
>> point back to the wiki pages to describe the "spec"
>>  - checkins refer to bugs, as always.
>>
>> sounds about right?
> 
> Yup. As long as everything is traceable.

Don't forget Jabber chat rooms (or IRC if you must ;-) for real-time
meetings. I'd be happy to set up a chat room with conversation logging
on conference.jabber.org...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


--------------ms020201050505060206080200
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYQDCC
B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI
EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD
VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0
MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy
YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh
dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy
ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz
eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA
IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O
U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj
eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u
xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud
DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx
tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE
BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0
eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G
CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0
YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp
oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6
Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5
BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y
Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50
ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX
TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z
KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls
YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC
AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl
cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo
dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0
cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw
Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H
yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa
v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0
4STurMCFwLoyx5k1rDHQYTCCCGIwggdKoAMCAQICAwF4qjANBgkqhkiG9w0BAQUFADCBrzEL
MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj
MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t
IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz
dGFydGNvbS5vcmcwHhcNMDcwODIyMjExMzI3WhcNMDgwODIxMjExMzI3WjCBujELMAkGA1UE
BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxGjAYBgNVBAoTEVBl
dGVyIFNhaW50LUFuZHJlMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl
IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0
cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALC1dkqD
gghuvUCkEloRDX50TTJ6Szj1BqtMpYq+An66BwkWfP07uay+jHori77776wk1/Ajk1nTSHX+
JWo+JWwVXYWBX+Zd780bB0FGShYlHGwMhd/pxX9sT4KW3D+r8sIHVbTGdudSweuNdBhqr1iE
cjze75hpywMkk1OQhTkseQxI5owa9M31JOdNEX0Ja6esyhwwtqqTNC86OujXwa2wew8GTRJE
9p2I0B1VCsKuJaPatbIcf9OFiTSODb5vyoq3+lrElh6V6BXKxEfQ4D2HCSY+5UmlKdnltzvN
bqxyaTYQi1YGsFzew7ST3R8P5jrCq2cvRjGrTKVojZXgPZ0CAwEAAaOCBHgwggR0MAwGA1Ud
EwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAd
BgNVHQ4EFgQUl7CU2dS/alOwLIHV/Oc2RkGDYugwgd0GA1UdIwSB1TCB0oAUBKzbJHdTRkaW
XxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxDjAM
BgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFDQSBBdXRo
b3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx
ITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASCATcwggEz
MIIBLwYLKwYBBAGBtTcBAQQwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNv
bS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0ZC4wAwIB
ARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0
aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWlsYWJsZSBh
dCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBbMCygKqAo
hiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDov
L2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2MDcGCCsG
AQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2VyL2NhMDsG
CCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51c2VyLmNh
LmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29tIFRydXN0
ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0LnN0YXJ0
Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5zdGFydGNv
bS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRjb20ub3Jn
MA0GCSqGSIb3DQEBBQUAA4IBAQCdG1L0T4OT1x4X/cKsuHxgijRaZGGiVECcn5+1X7E3H54/
yDkUqWAp6MZ3hZm36pzTYYnl+5M6vldLcqFCVpD7MgH6Kmu+r6pXAjU33k1RIHnkBvQ6KGlR
p0RjfaZW/2MkG07vF2QTLbx6KIhi0pa9Bg9wlqyw+C2g6FYnfmrdJLgGrxUXek8DSZNjZ/AA
75OoutrWkBtdaL2TbFiawdbGuJbSoQLHqLrNhT8f74Oec7ReOmuUTEL8hsFU0sbY/n2e9Wna
1Vzze3nZPbyPiC5F88p88gVLB9mKkOzleYefYiQw8LABz5x1MI+w0bNKNPLviJ/KnHGFEfVL
z1oMHyC3MIIIYjCCB0qgAwIBAgIDAXiqMA0GCSqGSIb3DQEBBQUAMIGvMQswCQYDVQQGEwJJ
TDEPMA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpT
ZWN1cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQ
cmltYXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9y
ZzAeFw0wNzA4MjIyMTEzMjdaFw0wODA4MjEyMTEzMjdaMIG6MQswCQYDVQQGEwJVUzERMA8G
A1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEaMBgGA1UEChMRUGV0ZXIgU2FpbnQt
QW5kcmUxLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRow
GAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBl
dGVyLmltMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsLV2SoOCCG69QKQSWhEN
fnRNMnpLOPUGq0ylir4CfroHCRZ8/Tu5rL6MeiuLvvvvrCTX8COTWdNIdf4laj4lbBVdhYFf
5l3vzRsHQUZKFiUcbAyF3+nFf2xPgpbcP6vywgdVtMZ251LB6410GGqvWIRyPN7vmGnLAyST
U5CFOSx5DEjmjBr0zfUk500RfQlrp6zKHDC2qpM0Lzo66NfBrbB7DwZNEkT2nYjQHVUKwq4l
o9q1shx/04WJNI4Nvm/Kirf6WsSWHpXoFcrER9DgPYcJJj7lSaUp2eW3O81urHJpNhCLVgaw
XN7DtJPdHw/mOsKrZy9GMatMpWiNleA9nQIDAQABo4IEeDCCBHQwDAYDVR0TBAUwAwIBADAL
BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSX
sJTZ1L9qU7AsgdX85zZGQYNi6DCB3QYDVR0jBIHVMIHSgBQErNskd1NGRpZfFwFcfUJHvUgZ
CKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UEBxMFRWls
YXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0eSBEZXAu
MSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8GCSqGSIb3
DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0gBIIBNzCCATMwggEvBgsrBgEE
AYG1NwEBBDCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRl
cm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s
aWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGNTGltaXRl
ZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0
aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9j
ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j
ZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0
Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4MHYwNwYIKwYBBQUHMAGGK2h0
dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3VzZXIvY2EwOwYIKwYBBQUHMAKG
L2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3MzLnVzZXIuY2EuY3J0MBEGCWCG
SAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRDb20gVHJ1c3RlZCBFbWFpbCBD
ZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2Nh
LWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1
My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s
aWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFydGNvbS5vcmcwDQYJKoZIhvcN
AQEFBQADggEBAJ0bUvRPg5PXHhf9wqy4fGCKNFpkYaJUQJyfn7VfsTcfnj/IORSpYCnoxneF
mbfqnNNhieX7kzq+V0tyoUJWkPsyAfoqa76vqlcCNTfeTVEgeeQG9DooaVGnRGN9plb/YyQb
Tu8XZBMtvHooiGLSlr0GD3CWrLD4LaDoVid+at0kuAavFRd6TwNJk2Nn8ADvk6i62taQG11o
vZNsWJrB1sa4ltKhAseous2FPx/vg55ztF46a5RMQvyGwVTSxtj+fZ71adrVXPN7edk9vI+I
LkXzynzyBUsH2YqQ7OV5h59iJDDwsAHPnHUwj7DRs0o08u+In8qccYUR9UvPWgwfILcxggQs
MIIEKAIBATCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMN
U3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAt
BgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZI
hvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjAJBgUrDgMCGgUAoIICSTAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEyMTkyMDQ4NTFaMCMGCSqG
SIb3DQEJBDEWBBQPK3Ss1yalwI+4gLc9GHhZjUeCKTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG
SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG
9w0DAgIBKDCByAYJKwYBBAGCNxAEMYG6MIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMG
SXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlm
aWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWls
IEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAXiqMIHKBgsq
hkiG9w0BCRACCzGBuqCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQG
A1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25p
bmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEw
HwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjANBgkqhkiG9w0BAQEFAASC
AQA3bLNzcIgiKJGgFuP3K1x4dy9xdIIILVXCeo/29fvGRdjidnOocCgGjMZ5GFz5h44juse8
wVh3PSeOn0frfVH32UOCXyy0pjWB0GCrHfbIQjaekfyqVzuSlpDsyTPPs3OKJyu/7t8ATn7N
h3F5N/WpyjadislEVx5mNgn6LYJNlF5n34lGx4vgnOfQqPwwn0724Lqi3UGkcC2OcUmDGEIZ
q00MXba0qJQNHVQHU9MTxLUwAtX8PfHgoaVvo7kwvLWc5PLM63bnBdHVm7FMzswkWAGNhYiD
WFPYWTSm1NMQOp7cc9DcI6mm9O00Sm7wd2fQuDbls4WgHgBc6XMCtx5CAAAAAAAA
--------------ms020201050505060206080200--
0
Peter
12/19/2007 8:48:51 PM
On 12/19/2007 2:12 PM, David Ascher wrote:
> Chris Ilias wrote:
>> On 12/18/07 5:10 PM, _David Ascher_ spoke thusly:
>>> Kent James wrote:
>>>> David Ascher wrote:
>>>>
>>>>> I find that bugzilla is a lousy place to _discuss_ RFEs --david
>>>> One thing I've always been impressed with about the whole Mozilla 
>>>> development environment is the traceability. I can pull up code 
>>>> using lxr, see the history of changes of each line of code using CVS 
>>>> BLAME, and then trace that back to its discussion on bugzilla. Any 
>>>> method changes that you propose should consider those who come after 
>>>> us, who will have to figure out what we did and why.
>>>>
>>> Agreed -- but wikis have history pages and revision history, so I 
>>> think traceability is pretty good there.
>>
>> I don't think that was the point Kent was making. CVS commits in 
>> Mozilla usually cite a bug number, not a wiki page.
>>
>> I find wikis good for documents, but not discussion. I agree that 
>> bugzilla is lousy for discussion, but I think wikis are worse.
> All this feedback is great. I'm happy to be more mailing list centric 
> than I'd usually be, and to see how it works in practice.
> 
> My current thinking is:
> 
> - we use wikis to _describe_ what the feature should "look like"
> - we _discuss_ them on the mailing list
> - we _update_ the wikis with revised version as per the results of the 
> discussion
> - we mention the updates on the mailing list, to let people know when 
> those changes happen
> - we create bugs to track implementation of features, and the bugs can 
> point back to the wiki pages to describe the "spec"
> - checkins refer to bugs, as always.
> 
> sounds about right?
> 
> --david
> 

precisely.

If anything "new" or odd-ball is contemplated one can post in 
m.d.planning so those who have great experience supporting 
communications mediums for mozilla-land can offer advice. One recent 
discussion was 
news://news.mozilla.org:119/VJidneknu-f0scXanZ2dnUVZ_gqdnZ2d@mozilla.org

0
Wayne
12/19/2007 9:10:19 PM
Chris Ilias keyboarded, On 12/19/2007 3:28 PM :
> On 12/19/07 1:04 PM, _Ron K._ spoke thusly:
>> A reason Netscape named the News portion of the Communicator 4.x 
>> suite Collabra was a view to news being a collaberation solution.  
>> Mial based  discussion here withe the MailMan interface Mozilla.Org 
>> is using  produced spotty results.  David's postings are the only 
>> ones showing both in the news group and dropping into my e-mail.  I 
>> am not subscribed to the list-serv.  With that spotty communication  
>> I am only getting his side of content others reply to David by the list.
>
> If you're not subscribed to the mailing list, you shouldn't be getting 
> messages from this newsgroup in your mailbox. The reason why you're 
> receiving David's messages via email, is because he's sending his 
> replies to the address of the person he is replying to, in addition to 
> the mailing list address (ie. Reply All). I don't think the 
> dev-apps-thunderbird mailing list is set to add the mailing list 
> address to the reply-to header of each post; so Reply All is a 
> quick/easy way of replying to the list.
>
> What I'm saying is, it has nothing to do with Thunderbird, unless bug 
> 45715 is fixed. :-)
>
> IMO, for discussions, nothing beats newsgroups. But I suppose that 
> would be popular opinion in *here*. Those who prefer a different 
> technology, are likely to be using a different technology. As long as 
> people are willing to use different communications technologies, this 
> shouldn't be an issue.

What got my attention was, I got a mail item from David that contained 
His reply to Kent at the head of this thread.  I had not made any 
posting to the news group at that point. So why would a non-list address 
be getting list mail ?  Only guess is, I might have been in David's 
collected addresses, but still unexpected Tb or Mailman behavior.

-- 
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported BSOD use by Major Error to msg the enemy!
0
Ron
12/20/2007 2:59:09 AM
David Ascher wrote:
> My current thinking is:
> 
> - we use wikis to _describe_ what the feature should "look like"
> - we _discuss_ them on the mailing list
> - we _update_ the wikis with revised version as per the results of the 
> discussion
> - we mention the updates on the mailing list, to let people know when 
> those changes happen
> - we create bugs to track implementation of features, and the bugs can 
> point back to the wiki pages to describe the "spec"
> - checkins refer to bugs, as always.
> 
> sounds about right?

I think this is one of the best descriptions of the Mozilla community 
collaboration I've read so far - just spread in IRC for real time 
communication somewhere and it's about complete ;-)

Robert Kaiser

0
Robert
12/21/2007 10:49:23 PM
Reply:

Similar Artilces:

test test test test test test
test test test test test test test test test test test ...

TEST TEST TEST TEST TEST
from forums 11:55 AM PST 02/12/2008 ...

test test test test
OE is a pain in my ass, test test test -- http://www.spywareinfo.com PGP Public key at http://www.spywareinfo.com/Mike_Healan.txt ...

Spam, spam, spam, spam
I sent this message to my anti-spam customers today! ************************************* Greetings to our anti-spam customers! A few of our customers have expressed concern over the amount of spam that is being delivered to your mailboxes. Alas, spam is back up to almost incomprehensible numbers. Postini estimates 94% of all email is now spam. Here is an interesting article about it: http://bits.blogs.nytimes.com/2009/03/31/spam-back-to-94-of-all-e-mail/?partner=rss&emc=rss What does this mean for you and your users? If we can block 99% of the junk destined for you...

test test test test
what is the deal with these bizarre "test updates"? i did a couple, but they just keep coming. On Feb 20, 7:08=A0pm, inspector.arc...@gmail.com wrote: > what is the deal with these bizarre "test updates"? i did a couple, > but they just keep coming. what? my email is accessible?! what the hell are you thinking? please delete these posts and remove my email address from public access. unbelievable! ...

Thunderbird Thinks It Is Spam (or, lovely spam, wonderful spam)
I receive an email newsletter (intentionally) a couple of times a week. I have the sender in my address book, but every time I get this newsletter, Thunderbird thinks it is junk, even though I click the 'Not Junk' button every time. How can I get Thunderbird to believe me that it is not junk once and for all? Thanks. Darrell wrote: > I receive an email newsletter (intentionally) a couple of times a week. > I have the sender in my address book, but every time I get this > newsletter, Thunderbird thinks it is junk, even though I click the 'Not > Junk'...

test, test, test
test ...

test test test
test test MJB Law Office wrote: > test test Is this legal? propman wrote: > MJB Law Office wrote: >> test test > > Is this legal? > Hey, propman, the post is from a law firm, so it must be legal! Right?? Daniel Daniel wrote: > propman wrote: >> MJB Law Office wrote: >>> test test >> >> Is this legal? >> > > Hey, propman, the post is from a law firm, so it must be legal! Right?? Mr. Bumble replies "If the law supposes that� the law is a ass�a idiot. If that�s the eye of the law, the law is...

test test test
test test test test for test "Praveen Hari" <phari@sybase.com> wrote in message news:enLr8dDFDHA.310@forums-1-dub... > test test test > > > ...

spam spam spam
hi, my greylisting mechanism is blocking too much mails. not only spam, its blocking web.de and so on. how can i configure this thing right? my denysoft_greylist.dbm has 2900000 ips in it. am i able to delete it or such thing? thanks m. -- _______________________ http://www.salbinger.de _______________________ Michael Salbinger wrote: > hi, > > my greylisting mechanism is blocking too much mails. > not only spam, its blocking web.de and so on. > how can i configure this thing right? > my denysoft_greylist.dbm has 2900000 ips in it. > am i ab...

App manager and Dev Apps
Hello, I am experiencing problems to debug apps loaded in the App Manager. I don't have this problem if the App is downloaded from the Marketpalce and debugged with the App Manager. Is there a known problem to debug Dev Apps, loaded from a directory in your computer? Thanks, Juanma ...

Test Test Test
Name: Gervase Markham Email: gervatmozilladotorg Product: Firefox Summary: Test Test Test Comments: Testing Hendrix. Gerv Browser Details: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9) Gecko/2008052912 Firefox/3.0 From URL: http://localhost/src/hendrix/ ...

testing and testing and testing :)
and again :) Carsten Book wrote: > and again :) Testing is fun! Stephen Donner wrote: > Carsten Book wrote: >> and again :) > > Testing is fun! test Stephen Donner wrote: > Stephen Donner wrote: >> Carsten Book wrote: >>> and again :) >> >> Testing is fun! > test testing too :p ...

test test test
test test test ...

Web resources about - SPAM regression testing - mozilla.dev.apps.thunderbird

Nonlinear regression - Wikipedia, the free encyclopedia
The data consist of error-free independent variables ( explanatory variables ), x , and their associated observed dependent variables ( response ...

Your Past Lives - Your Future Life - Regression Readings for iPhone, iPod touch, and iPad on the iTunes ...
Get Your Past Lives - Your Future Life - Regression Readings on the App Store. See screenshots and ratings, and read customer reviews.

REGRESSION Trailer (Emma Watson - Ethan Hawke - HORROR) - YouTube
A father is accused of a crime he has no memory of committing. ★Join us on Facebook ► http://facebook.com/HorrorScifiMovies ★ HORROR Fan ? Don't ...

‘Regression to the mean’ or why it probably wasn’t David Moyes’ fault
Over recent months, Moyes has been criticised for everything from sacking Ferguson’s back-room team to lacking tactical vision. He got one thing ...

Emma Watson reportedly topless in upcoming film Regression - The Courier-Mail
EMMA Watson, who moved on from Hogwarts to Brown University in the US, is continuing to test herself in more adult roles that rid her of her ...

Emma Watson reportedly topless in upcoming film Regression - Herald Sun
EMMA Watson, who moved on from Hogwarts to Brown University in the US, is continuing to test herself in more adult roles that rid her of her ...

What does regression to the mean, mean?
Employers, lovers, researchers and investors have all been fooled by this statistical concept, but it's actually a doddle, explains Gary Smith. ...

2014 Toronto Blue Jays: Rebound or regression?
Will Jose Bautista and Jose Reyes stay healthy this season? Is 2014 the year Brett Lawrie and Colby Rasmus put together breakout campaigns? We ...


Regression and extraction
The book Why Nations Fail makes the argument that sustained societal prosperity is only possible when economic and political institutions are ...

Resources last updated: 12/11/2015 2:08:46 AM