From dkap+jabberzilla at haven.org  Thu Apr  1 00:18:49 2004
From: dkap+jabberzilla at haven.org (A Page in the Life of ...)
Date: Thu Apr  1 00:30:43 2004
Subject: [Jabberzilla] the killer jabberzilla app
In-Reply-To: <m2n05w1fou.fsf@maya.dyndns.org> (message from Gary Lawrence
	Murphy on Wed, 31 Mar 2004 23:32:17 -0500)
Message-ID: <200404010518.AAA25826@opal.haven.org>

-=> Subject: Re: [Jabberzilla] the killer jabberzilla app
-=> From: Gary Lawrence Murphy <garym@canada.com>
-=> Date: Wed, 31 Mar 2004 23:32:17 -0500
-=> 
-=> >>>>> "A" == A Page in the Life of <A> writes:
-=> 
-=>     A> With all due respect, it sounds like you are re-inventing IRC
-=>     A> as it originally was.  Or perhaps a cross between IRC and
-=>     A> Zephyr.
-=> 
-=> With all due respect, this is nothing at all like IRC -- try having
-=> a business meeting in IRC ;)  Ok, it's like having your own IRC
-=> server, but how much fun is that?

Back when IRC was started, business meetings were held that way, as well
weddings, role-playing games, and even chess matches.  If you are looking
to build the "killer app" that you are talking about, how are you going to
manage lists, getting to the right lists, keeping those who shouldn't be
spamming those lists, and yet allowing the correct information through, and
knowing when people will coordinate, if they are to be offline, then what's
wrong with a mailing list?  How does it connect up people with disparate
paths and similar intersts?  I'm not knocking it, I'm just pointing out
questions that you might want to think about for your implementation.

-=>     A> Not that that is a bad thing, necessarily, but ask the
-=>     A> developers of each why they didn't scale well.
-=> 
-=> Ah, there's the magic: Who said it has to scale? ...  Read Clay
-=> Shirky's latest: http://www.shirky.com/writings/situated_software.html
-=> ... when was the last time you held a code review with 10,000 people
-=> present?  What good is a writer's workshop with 200 people?  What
-=> sort of legal brief would have an audience of more than 20 people?

It has to scale, not necessarily in the connection of how to talk to any
number of people, for Jabber already scales for that, but in terms of
connecting up all the possible folks to the right place.

-=> if anything, yes, it could probably be done embedding IRC into mozilla,
-=> but it's not really the chat itself I want to see (most often it's
-=> empty) but the /presence/ _and_ the full CC-list, present or not.

Well ... irc isn't the issue, it's learning from their lack of scaling
enviornment.  Also talk to the Zephyr folks.

-=> Consider the number of people on the typical office-document CC
-=> list, at most a dozen, a perfectly manageable number for IM chat,
-=> and I don't need the expense of running my own IRC server because
-=> Jabber is plug and play running on any store-bought Linux box.

Depends on the information that is being sent out.  In your example about
reaching all the folks involved with a production, you have upwards of 200
people, for your writing workshop.  Figuring out the appropriate scope is
important as well.  Oh, and IRC will also run on any store-bought Linux
box.  Not that that means anything, but ...

All things you should consider while implementing your idea.

-dkap
From GuruJ at mbox.com.au  Thu Apr  1 22:05:19 2004
From: GuruJ at mbox.com.au (GuruJ)
Date: Thu Apr  1 07:16:00 2004
Subject: [Jabberzilla] Suggestion...
In-Reply-To: <406ACAE4.7060800@openaether.org>
References: <4069C982.90603@openaether.org> <406A12B7.9020803@cox.net>
	<406A2263.8000907@sympatico.ca> <406A6AA5.3060006@openaether.org>
	<406AAFAF.8030905@mbox.com.au> <406ACAE4.7060800@openaether.org>
Message-ID: <406C057F.7060606@mbox.com.au>

Justin Kirby wrote:
> Ok, there seems to be a consensus here about pure xul/js application. 
> Fair enough and I will drop the issue.

I was expressing reservations, not canning the idea completely :)  I 
like the idea of a high-performance backend, as long as it doesn't 
needlessly complicate the process of hacking the UI and user-level 
capabilities, which (I presume) is where most casual hacking will take 
place.

> So the rest is just clarification of some minor points, nothing to do 
> with anything else, i.e. off topic from here on.
> 
>>
>> I feel that worrying about performance at this stage is a 'premature 
>> optimization'.  To attract developers, IMHO, the *key* is making sure 
>> that it is easy to get a copy of the program to play around.  That 
>> means not downloading 5 different programs and compiling from source.
> 
> I have been working on porting from apr to nspr for a week or so. When 
> thats done, the only non-moz dependency will be xerces-c (for binaries).

 From what I know with Xerces, it's a great XML parsing engine, but I've 
had problems getting it to work with Windows 98 (some of us still use 
it, you know ;)  That might be just the Perl library, though, which is 
the only part of Xerces I have used so far.

Out of curiosity, doesn't Mozilla have a pretty good XML parser built 
in?  Do you use Xerces because you need SAX for oa?  Or is it just a 
question of performance?

>> If it is possible to bundle all dependencies in, say, 1-4 XPIs, then 
>> great.  Anything more complicated than that, I suspect, is a no go.
> 
> I have it bundled into one xpi.

Then that's another problem out of the way.  In your model, are we down 
to three separate steps?  (1) Install Xerces; (2) Install oa XPI; (3) 
Install Jabberzilla?  If so, I could probably live with that.

>> No, but trying to re-use a wheel that won't fit the axle isn't going 
>> to help as well.  
> 
> Maybe you could help clarify this for me. How does an XPCOM component, 
> and a jar package which has xbl bindings not fit onto the mozilla axle?
> (note: I do not mean that as sarcasm, but I am interested as to why you 
> think it doesn't fit)

That was more a comment on my perceived problems with Jabber libraries 
(see previous comments below), not on your libraries themselves.  It was 
probably an ill-judged remark to make, in that I haven't had time to 
pull your sources from CVS to have a look at how they work, and so I was 
speaking more from experience with other libraries and my feeling that 
we'd end up with a very specific implementation of Jabber on Mozilla, 
when I'd love to see one that people can adjust to their needs.

If you haven't already guessed this from the way I'm talking, I see a 
good implementation of Jabber with Mozilla as a potential 'killer app' 
for the platform -- one that transforms Mozilla into a really useful 
business tool that happens to do web browsing as well.  JabberZilla 
could be one real step towards that goal if we get it right.

<snip>
> I agree with the 'not just another IM'. There are countless 
> possibilities with integrating jabber capabilities into mozilla. It is 
> exciting to think about.
> 
> I would like to point out that just because an XPCOM lib is written in 
> c++ does not mean it has fallen out of the mozilla strategy. The xpoa 
> component is nothing more than an implementation of the jabber protocol, 
> so there is no reason that it should be constrained to yet another 
> client. In fact the primary goal of it's design is to allow for more 
> interesting uses.

I agree completely.  C++ components are great, and should be used where 
necessary.  If oa is written as you say, then it probably doesn't 
present a great problem.

<snip>
> Most libs are in the first category. There are only two libraries that I 
> am aware of which fall into the second. OpenAether and JSO. PSI is 
> working on moving Iris out into this design too, but right now it is 
> still a client only for psi.

That's really handy to know!  After looking at a few, it's easy to think 
that they're all the same.  I'll have to have a look at JSO as well.

> This is all probably due to design philosophy differences. I have always 
> viewed the pure xul/js as a quick prototyping tool to make sure your 
> idea is sane. Once that is done, you relegate the js to nothing more 
> than glue. Meaning most of the logic code is move into c++ and the UI is 
> in XUL xml, js is just the native bridge between the two.
> 
> Where apparently the consensus here is that xul/js is the end, not the 
> means.

I suppose a good comparison is with Visual Basic back in the days when 
even Microsoft wasn't pushing it as a 'serious' language.  Often, people 
would build a prototype in VB that became the final product simply 
because performance was 'good enough'.  While I am obviously 
generalizing there, I think Mozilla developers often stop at JavaScript 
and don't look at full XPCOM functionality because they don't want to go 
to the extra effort for what they see as marginal returns.

> So, with that out of the way:
> I obviously have extensive experience playing with the jabber protocol 
> and implementing it (I have worked on more than just OA). So feel free 
> to ping me on any design or protocol questions you have.
> 
> Do try not to go too far outside the xmpp protocol, the point of xmpp is 
> interoperability after all.

... and that's what the JEPs are for if a good idea is invented which 
doesn't fall within the specs, I know!  My main problem with XMPP at the 
moment is that it still feels strongly oriented towards generating an 
ICQ replacement.  However, I'm sure that will ease as time passes - the 
spec itself isn't that old, after all.

-- GuruJ.

From jlee at diavox.com  Thu Apr  1 12:20:39 2004
From: jlee at diavox.com (jlee@diavox.com)
Date: Thu Apr  1 07:21:12 2004
Subject: [Jabberzilla] (no subject)
Message-ID: <mailman.0.1080822072.5464.jabberzilla@mozdev.org>

Permanent Fatal Error:
This user doesn't have a diavox.com account.

From GuruJ at mbox.com.au  Thu Apr  1 22:39:14 2004
From: GuruJ at mbox.com.au (GuruJ)
Date: Thu Apr  1 07:49:54 2004
Subject: [Jabberzilla] the killer jabberzilla app
In-Reply-To: <m27jx03anm.fsf_-_@maya.dyndns.org>
References: <40553A4E.5020709@cox.net> <20040316214740.GA14594@jabber.org>
	<m27jx03anm.fsf_-_@maya.dyndns.org>
Message-ID: <406C0D72.1050207@mbox.com.au>

This is what I understand Gary to be proposing:

* Make resource 'nodes' available which people subscribe to according to 
interest, business org unit, or other logical grouping
* People can then IM either everyone in that list, or individuals 
according to who is on-line

So far this at least maps onto what IRC could do (nodes = channels, IM 
all = chat, IM individuals = whisper), and accordingly, it will probably 
suffer from some of the classical drawbacks of IRC, as I see them:

* Information overload:  Too many messages can appear at once
* Signal-to-noise ratio:  A lot of messages will not be of interest to 
particular users
* No mechanism for trust:  Easy for spammers to ruin it for everyone
* No ad-hoc groups:  No way to dynamically change user groupings without 
creating a new channel (BIG advantage of e-mail)

Obviously, many of these problems disappear or can be controlled in a 
business environment, but they're hard to control.  In particular, 
signal-to-noise ratios emerge quickly even for relatively small groups 
(say 10+ participants?).  Have you ever been on an e-mail distribution 
list of 50+ people when a flame war erupts?  LOTS of off-topic messages 
which are of no interest to those who aren't involved, and no way to 
stop receiving them without potentially missing out on useful 
information as well.

Building on Gary's concepts, I've always thought that business IM should 
include some or all of the following:

* Hierarchical user groups.  Users should be able to subscribe 
themselves into one or more places in a comprehensive group structure 
that defines who they are, and what they are interested in.

* Group presence.  Users can view who is subscribed to a group, and the 
current state of each user's presence.

* Security barriers.  Users are assigned different levels of permissions 
that limit which groupings they can view and/or send messages to.

* Message threading.  Every initiating IM message should be assigned a 
'thread ID', and preferably a subject as well.  All messages in the same 
thread appear together, grouped chronologically, much like email threading.

Each thread has a list of users who wish to receive messages regarding 
this thread, or alternatively, it could be the responsibility of clients 
to filter out unwanted threads.  See also 'thread ignore', below.

* Thread ignore.  Users should be able to easily 'quash' notification of 
thread discussions that is of no interest to them.  While the 
information might still be received by the client, the information is 
simply logged and not displayed to the user until they want to go 
through it later.

* User invite.  Conversely, users should be able to invite others to 
participate in their thread, which is then activated to receive messages.

* Thread escalation.  (This is probably only useful in a business 
setting.)  If a thread is felt to be of general interest, the thread can 
be marked so that all users who fall into the parent-level of the 
hierarchy are invited to join the thread.

No doubt there's more things people can come up with, but I strongly 
feel that just these features would help address a lot of IRC's 
shortcomings and make for a more structured IM experience.

Any comments?

-- GuruJ.

From jlee at diavox.com  Thu Apr  1 12:53:34 2004
From: jlee at diavox.com (jlee@diavox.com)
Date: Thu Apr  1 07:54:51 2004
Subject: [Jabberzilla] (no subject)
Message-ID: <mailman.1.1080824091.5464.jabberzilla@mozdev.org>

Permanent Fatal Error:
This user doesn't have a diavox.com account.

From r_greathouse at yahoo.com  Thu Apr  1 06:10:56 2004
From: r_greathouse at yahoo.com (Robb Greathouse)
Date: Thu Apr  1 09:22:45 2004
Subject: [Jabberzilla] the killer jabberzilla app
In-Reply-To: <m27jx03anm.fsf_-_@maya.dyndns.org>
Message-ID: <20040401141056.27847.qmail@web11205.mail.yahoo.com>

Sounds analagous to what Google did with search - a page's importance is determined by how many
other pages say to look there.

A network node is important because of where else it can lead.

A social network node is important because of the opportunities it can lead to - other people,
ideas, shared files, solutions, etc.


--- Gary Lawrence Murphy <garym@canada.com> wrote:
> 
> I've been doing some pondering lately on the failure of the current
> crop of "social networking" portals, and I've concluded that it's
> inside out, that it's not the endpoints who should own the network
> topology but the edges that join them, the content.
> 
> this is a half baked idea, so bear with me ;)
> 
> the buddylist should belong not to individual people, but to individual
> artifacts online, and the easiest way to do that is to embed the
> FOAF information into a webpage like the classical CC list of the old
> pre-paperless office.
> 
> So here's the interface:
> 
> * the page contains the CC list of "people attached to this web resource"
> 
> * XPI is sensitive to this list, picks it up and finds IM handles (thus
>   protecting personal privacy)
> 
> * Jabberzilla, instead of showing me /my/ buddy list, shows me the
>   current online status of /everyone attached to this resource/
> 
> In business situations, this is an obvious match.  For other sorts of
> contact, maybe the FOAF would be dynamically generated from the "portal
> members last reading this page" or somesuch, it doesn't matter, it's just
> a FOAF list attached (via meta alt link?) -- Jabberzilla doesn't care
> how the list is generated, it's just a link to follow and interpret
> 
> Jabberzilla then displays a compact list of who's who in this web resource's
> world, so if you needed to talk to someone about it, voila, there it is.
> 
> it's like a live CC-list :)
> 
> Microsoft announced it is obsessed with dating sites and people trading
> photographs; my guess is they plan to hash-id actual files and run a
> central registry that will link IM handles to the hash-id, bla bla bla
> all centralized, all locked down, and all useless when their NT server
> goes down :)
> 
> But live CC ... it's decentralized, open standard, and _requires_
> Mozilla to make it fly (ok, you could probably code an MSIE widget
> thingy to do the same, but why on earth would you encourage people to
> use MSIE?)
> 
> I think this would be a killer app for Mozilla, a killer app for
> Jabberzilla, a killer app for jabber in general, we'll all be instantly
> rich and famous (or at least famous) and social networking software will
> start performing a /useful/ function.
> 
> So ... what say the preachers?
> 
> * Is this possible?  How soon?
> * Anyone have the skills/resources to effect it?
> * Am I stark raving bonkers even suggesting such a thing?
> 
> -- 
> Gary Lawrence Murphy <garym@teledyn.com>
> www.teledyn.com/mt - www.teledyn.com - sbp.teledyn.com
> You don't play what you know; you play what you hear.
> _______________________________________________
> Jabberzilla mailing list
> Jabberzilla@mozdev.org
> http://mozdev.org/mailman/listinfo/jabberzilla


__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/
From jlee at diavox.com  Thu Apr  1 14:27:14 2004
From: jlee at diavox.com (jlee@diavox.com)
Date: Thu Apr  1 09:27:46 2004
Subject: [Jabberzilla] (no subject)
Message-ID: <mailman.2.1080829666.5464.jabberzilla@mozdev.org>

Permanent Fatal Error:
This user doesn't have a diavox.com account.

From justin at openaether.org  Thu Apr  1 10:45:42 2004
From: justin at openaether.org (Justin Kirby)
Date: Thu Apr  1 10:57:21 2004
Subject: [Jabberzilla] Suggestion...
In-Reply-To: <406C057F.7060606@mbox.com.au>
References: <4069C982.90603@openaether.org>
	<406A12B7.9020803@cox.net>	<406A2263.8000907@sympatico.ca>
	<406A6AA5.3060006@openaether.org>	<406AAFAF.8030905@mbox.com.au>
	<406ACAE4.7060800@openaether.org> <406C057F.7060606@mbox.com.au>
Message-ID: <406C3926.8010009@openaether.org>

GuruJ wrote:
> I was expressing reservations, not canning the idea completely :)  I 
> like the idea of a high-performance backend, as long as it doesn't 
> needlessly complicate the process of hacking the UI and user-level 
> capabilities, which (I presume) is where most casual hacking will take 
> place.

Most likely, since XUL/JS has a low barrier to entry. Though, not being 
a web dev I find the c++ world of mozilla much easier to digest.

>  From what I know with Xerces, it's a great XML parsing engine, but I've 
> had problems getting it to work with Windows 98 (some of us still use 
> it, you know ;)  That might be just the Perl library, though, which is 
> the only part of Xerces I have used so far.

What is this 'Windows' you speak of?

Now that you mention win98, I have mainly worked on nt4, w2k, w2k3,xp. 
Testing out on win9x never crossed my mind. Though I doubt xerces-c 
would give any trouble there. Hell the thing runs everywhere.

> 
> Out of curiosity, doesn't Mozilla have a pretty good XML parser built 
> in?  Do you use Xerces because you need SAX for oa?  Or is it just a 
> question of performance?

I started coding OA back when moz was in M14, so a direct dependency 
wasn't an option. That and I wanted my code to not require mozilla.

There are essentially two ways of dealing with jabber protocol; SAX and 
custom xml processor. To help me keep my sanity, I went with SAX :)

The code is organized like so:
- oapr = portability layer (the thing I am moving over to nspr)
- oacore = core protocol libraries
- xpoa  = xpcom and xul code


> Then that's another problem out of the way.  In your model, are we down 
> to three separate steps?  (1) Install Xerces; (2) Install oa XPI; (3) 
> Install Jabberzilla?  If so, I could probably live with that.
I actually bundle xerces-c into the xpi, so everything is there in one.

<snip>

> 
> ... and that's what the JEPs are for if a good idea is invented which 
> doesn't fall within the specs, I know!  My main problem with XMPP at the 
> moment is that it still feels strongly oriented towards generating an 
> ICQ replacement.  However, I'm sure that will ease as time passes - the 
> spec itself isn't that old, after all.

Jabber itself is very old, the protocol has been around since 1999 
(technically before that). XMPP is just an ietf formalization of the 
jabber protocol. Admittedly, XMPP has a few differences, like the 
addition of SASL. However, XMPP is most definitely *not* an overhaul of 
the jabber protocol.

I would strongly disagree with the ICQ statement. xmpp-core is an xml 
streaming protocol. xmpp-im adds presence and messaging as a layer ontop 
of -core. ICQ is a binary udp protocol. The only similarity is that they 
both have presence.

The way I look at it, is that xmpp is an extensible xml streaming 
protocol where the most popular use is IM.

Justin
From jlee at diavox.com  Thu Apr  1 16:02:09 2004
From: jlee at diavox.com (jlee@diavox.com)
Date: Thu Apr  1 11:02:41 2004
Subject: [Jabberzilla] (no subject)
Message-ID: <mailman.3.1080835361.5464.jabberzilla@mozdev.org>

Permanent Fatal Error:
This user doesn't have a diavox.com account.

From sverma at sfsu.edu  Thu Apr  1 08:10:09 2004
From: sverma at sfsu.edu (Sameer Verma)
Date: Thu Apr  1 11:22:13 2004
Subject: [Jabberzilla] (no subject)
In-Reply-To: <200404011602.i31G2f61017684@localhost.mozdev.org>
References: <200404011602.i31G2f61017684@localhost.mozdev.org>
Message-ID: <406C3EE1.4000903@sfsu.edu>

jlee@diavox.com wrote:

>Permanent Fatal Error:
>This user doesn't have a diavox.com account.
>
>  
>
Oh! This user has permanently fatalized three times already :-)  Will 
somebody get him his diavox?
--
Sameer
From jlee at diavox.com  Thu Apr  1 16:24:08 2004
From: jlee at diavox.com (jlee@diavox.com)
Date: Thu Apr  1 11:24:40 2004
Subject: [Jabberzilla] (no subject)
Message-ID: <mailman.4.1080836680.5464.jabberzilla@mozdev.org>

Permanent Fatal Error:
This user doesn't have a diavox.com account.

From GuruJ at mbox.com.au  Fri Apr  2 21:32:25 2004
From: GuruJ at mbox.com.au (GuruJ)
Date: Fri Apr  2 06:43:01 2004
Subject: [Jabberzilla] Suggestion...
In-Reply-To: <406C3926.8010009@openaether.org>
References: <4069C982.90603@openaether.org> <406A12B7.9020803@cox.net>
	<406A2263.8000907@sympatico.ca> <406A6AA5.3060006@openaether.org>
	<406AAFAF.8030905@mbox.com.au> <406ACAE4.7060800@openaether.org>
	<406C057F.7060606@mbox.com.au> <406C3926.8010009@openaether.org>
Message-ID: <406D4F49.2080604@mbox.com.au>

Justin Kirby wrote:
 >> Then that's another problem out of the way.  In your model, are we
 >> down to three separate steps?  (1) Install Xerces; (2) Install oa
 >> XPI; (3) Install Jabberzilla?  If so, I could probably live with
 >> that.
 >
 > I actually bundle xerces-c into the xpi, so everything is there
 > in one.

So what's the best way to obtain and install the XPI?  I'd be interested 
in having a look at the implementation as it stands...

> GuruJ wrote:
<snip>
>> ... My main problem with XMPP at 
>> the moment is that it still feels strongly oriented towards generating 
>> an ICQ replacement.  However, I'm sure that will ease as time passes - 
>> the spec itself isn't that old, after all.
> 
> 
> Jabber itself is very old, the protocol has been around since 1999 
> (technically before that). XMPP is just an ietf formalization of the 
> jabber protocol. Admittedly, XMPP has a few differences, like the 
> addition of SASL. However, XMPP is most definitely *not* an overhaul of 
> the jabber protocol.
> 
> I would strongly disagree with the ICQ statement. xmpp-core is an xml 
> streaming protocol. xmpp-im adds presence and messaging as a layer ontop 
> of -core. ICQ is a binary udp protocol. The only similarity is that they 
> both have presence.

I said *feels* like, not is.  Jabber beats ICQ in every way imaginable 
as far as flexibility and implementation is concerned.  And I agree that 
an implementation of xmpp-core doesn't have to even mention Instant 
Messaging, but ...

> The way I look at it, is that xmpp is an extensible xml streaming 
> protocol where the most popular use is IM.

... I just wish there were more applications out there that did 
something more than just IM.  We've got, like *15* competing IM 
implementations, but nothing much that goes beyond that.  Eric's 
whiteboard project was actually pretty visionary as far as Jabber 
implementations go.

-- GuruJ.

From carl at betterbilling.net  Fri Apr  2 11:32:40 2004
From: carl at betterbilling.net (Carl Tanner)
Date: Fri Apr  2 13:44:46 2004
Subject: [Jabberzilla] Re: Jabberzilla Digest, Vol 5, Issue 3
In-Reply-To: <200404021703.i32H3361032690@localhost.mozdev.org>
References: <200404021703.i32H3361032690@localhost.mozdev.org>
Message-ID: <406DB1C8.3080306@betterbilling.net>


>> GuruJ wrote:
>
> ... I just wish there were more applications out there that did 
> something more than just IM.  We've got, like *15* competing IM 
> implementations, but nothing much that goes beyond that.  Eric's 
> whiteboard project was actually pretty visionary as far as Jabber 
> implementations go.
>
>  
>
Actually there soon can be.  One of the advantages of Jabber is that, 
since a connection is already established, you have identified users 
that can pull subscribed services and those subscribed services can push 
to the user.  We aren't talking about just a something like a mailing 
list either.  With one account, and just a few simple GUI's, a user 
could connect to a component that allows verified users access to 
mulitple databases, EDI networks, contextual and universal help for the 
client from a remote DB, and anything else that can be streamed in XML 
or out of band.  The client could display it textually, graphically, or 
a combination.
From garym at canada.com  Thu Apr  1 09:25:26 2004
From: garym at canada.com (Gary Lawrence Murphy)
Date: Sun Apr  4 19:06:01 2004
Subject: [Jabberzilla] the killer jabberzilla app
References: <200404010518.AAA25826@opal.haven.org>
Message-ID: <m24qs322sp.fsf@maya.dyndns.org>

>>>>> "A" == A Page in the Life of <A> writes:

    A> Back when IRC was started, business meetings were held that
    A> way, as well weddings, role-playing games, and even chess

Yes, _exactly_ right.  How could we do that?  Because the audience was
small and close knit.  It is a very different world today.  

Another problem today: How many non-engineers (and non-students) do
you know who have reliable IRC "addresses"?  I can count on the
fingers of one hand the number of people over 30 that I know who know
what IRC is let alone how to use it.

But they all have some kind of IM.

    A> ... how are you going to manage lists, getting to the right
    A> lists, keeping those who shouldn't be spamming those lists

OK. Very good question. As I mentioned in the first post, the list is
an external meta-link FOAF rdf file; it is the domain of the page
/owner/ to decide how that file is generated.  

The FOAF file specs who is in the CC list.  As for who can access that
list, a simple extension might be an option to exclude anyone not
already in the list, which then has all sorts of security/spoofing
complications as you try to ascertain who is who.

A simple fix, a site could password protect the FOAF using http
auth. This means the query service must be two-stage, one step to get
the page into the browser and discover that it has been tagged with a
live-CC list, then a second stage click-through to actually access
that list.  If the list is behind http auth, the second stage will
issue the pw challenge; being http auth, the access verification can
be arbitrarily complex.

    A> ... if they are to be offline, then what's wrong with a mailing
    A> list?

Timing, presence, immediacy.  The situation I observed in the courts
offices is a good example.  They need to know /now/ because the judge
has called the lawyers in and they have to be there.  No time to send
any email and wait for a reply.  Lots of business documents have this
scenario.

    A> How does it connect up people with disparate paths and similar
    A> intersts?  

Ah ... /very/ good question! :) ... we already have a common interest
_a priori_ --- we are both reading the same page.  The _page_ owns the
buddy list, not the people.  Once I have the list and the page, I then
start asking questions about the people and their relation to this
/specific/ web resource.

So pairing relevent interests come after the fact.  I see the buddy
list and I read the paper and I think, "Did legal ok this?" and I
check the live CC FOAF and it crawls the document buddy list FOAFs and
discovers that Mr Bradley Martin is from Legal ... so I ask him.

Notice the difference here from the dating site.  I am asking for
someone with legal interests even though I am not myself listed as
having legal interests; instead of matching likes (remember, "likes
repell, opposites attract") I am matching /needs/ and /wants/.

Had we depended on any intersection of interests, it's quite unlikely
my wife and I would have ever met.  There was a task (a gig) that
required our /complimentary/ skills and, well, we just really liked
working together ;)

    A> I'm not knocking it, I'm just pointing out questions that you
    A> might want to think about for your implementation.

No problem -- I'm encouraged by the amount of discussion; this is all
good stuff. Some of the questions so far were anticipated, some are
quite new.

Back to Clay Shirky's paper, it's important to keep a perspective with
an app like this: I don't intend for this to be a "every mother and
their dog" application because that is not how IM works.  It's an
application for a small audience, and because the content owner
controls how names are tacked to the list, privacy and security are
out of the scope of the application.  By making the app simple, by
excluding problem domains, I drive up the probability that it is
possible to actually build it ;)

    A> It has to scale, not necessarily in the connection of how to
    A> talk to any number of people, for Jabber already scales for
    A> that, but in terms of connecting up all the possible folks to
    A> the right place.

I don't follow. I use IM every day and I've never had this problem.
The largest discussiong group I've ever /needed/ on IM was 4 people.

    A> Depends on the information that is being sent out.  In your
    A> example about reaching all the folks involved with a
    A> production, you have upwards of 200 people

No way.  Really? 200 people needing to discuss the script changes?
What do they do when there's a revision? Rent a hall?  

I cannot believe this assertion, and when I did some work for Bell
that involved Norman Jewison, nobody mentioned town hall meetings
about scripts, all the scenarios were at most board-room sized.

Even in the case of the Boeing 767, there was maybe a few hundred
people in the CC list for the design specs, but there was never ever a
case where more than a handful were needed to be in simultaneous
interactive real-time contact over design issues.  Engineers meet,
tool and die makers meet, assembly foremen meet, but if the assembly
workers discovered a problem for the engineers, it was still handled
by the proper chain of communications, and that's another situation
where the FOAF can help because I can IM my supervisor, who then reads
the spec and decides to IM the head of manufacturing, who reads teh
spec and IMs the head of engineering, who reads the spec and IMs the
engineer who thought a barbeque in First Class was a Good Idea.

Maybe this isn't really an appropriate application for Jabberzilla
because this really should be jabber-client neutral and just for embed
the jabber /presence/ state into the Mozilla frame (external to the
actual web page) in a form that makes it possible to click and launch
a client.  It would be more seemless (esp for those without IM) to
click the link and have a chatzilla-like frame appear for the IM
client, but that's not essential (and a great deal more work ;)

-- 
Gary Lawrence Murphy <garym@teledyn.com>
www.teledyn.com/mt - www.teledyn.com - sbp.teledyn.com
You don't play what you know; you play what you hear.
From garym at canada.com  Sun Apr  4 22:40:59 2004
From: garym at canada.com (Gary Lawrence Murphy)
Date: Sun Apr  4 21:52:50 2004
Subject: [Jabberzilla] the killer jabberzilla app
References: <200404050023.UAA10848@opal.haven.org>
Message-ID: <m24qrzdwwk.fsf@maya.dyndns.org>

>>>>> "A" == A Page In the Life Of <A> writes:

    > the list is an external meta-link FOAF rdf file; it is the
    > domain of the page /owner/ to decide how that file is
    > generated.

    A> That's one way to do it, but it then ties your app to a whole
    A> outside infrastructure.  There should be a better way.  (I
    A> hope.)

Sure: Like CC licenses or trackback, where appropriate the FOAF rdf
can be embedded in the page tiself.

    > ...  If the list is behind http auth, the
    > second stage will -=> issue the pw challenge; being http auth,
    > the access verification can -=> be arbitrarily complex.

    A> Hrm ... ok ... I can accept that, but it sounds very complex to
    A> set up and maintain for the owner.  Is there any way we can do
    A> it within the Jabber context?  Some sort of "dir" function,
    A> maybe?  

Does jabber have a secure definition of groups? For example, can I offer
a page in public where only those within a certain domain can have
access to the member list?  the basic problem to solve is where the
list is open for members, but completely invisible to non-members
(and the membership set may only intersect the CC list)

    A> ...  But it still doesn't solve the problem with (lack of)
    A> discovery, and persistance of existance, which is why I
    A> hesitated to suggest it in the first place.

That is intentional: This is not a dating app, it's a business app.
Discovery and persistence are both transactionally defined.  You might
be the writer on this film, but the director on another.

    A> ... it requires the lawyers to be logged into something,
    A> or what have you

Which they do.  And it's called AIM, and it's quite popular.  To get
the same effect, you'd have biff, then on top of it you'd have IRC?
Getting one app installed on any given business desktop is nightmare
enough ;) The advantage with IM is rolling presence, messaging and
chat into one app that is /already/ installed.

    A> There should also be a way to set context-awareness, as in "I'm
    A> in a meeting, and noone of the level below my boss should be
    A> able to disturb me now."  

That's an IM client issue, and I totally agree.  I need a way to also
distinguish between my wife, my mother and my boss -- which is part of
what I mean by these relationships being transactional; the current
crop of IM clients all believe the relationships are defined by the
individual but they should be defined by the relationships.

    A> Ok ... might I suggest taking a look at Orkut?  

Ha! :) That gave me quite a start.  For a split second I thought you
were serious.  

yes, I've seen Orkut.  And as they say, nothing is ever a complete
failure, it can always be used as a bad example, for which Orkut
is excellent.

    A> Mr. Bradley might have been CC'd for his information, but not
    A> for his reccomendation, or approval, and might be starting the
    A> company's case against the sender, or looking to protect the
    A> company from the sender, or ...

Yes, but how do people know this from the /printed/ CC on the document?

You know because you ask.

    A> In my experience they are seldom even willing to give a member
    A> of the Legal Staff time to meet with the IT folks

And for jolly good reason too ;)

    A> ...  I don't know the answers, hence why I ask questions.  It
    A> would be silly to ask questions I knew the answers to, right?

Absolutely.  I don't have answers either, but in the name of being
empirical, I figure the shortest path is probably to first answer the
question, "Would Jabberzilla be a suitable technology for a real-world
test?"

    A> "Plan your security from the beginning.  Adding it later is
    A> always a much more expensive, and often times incomplete
    A> effort."

Interesting.  Shirky's conclusion is, "Never mind, you are not likely
to ever get large enough to have worries like that, and if you do,
you'll also have the resources to deal with it."  Curiously, (and much
to my chagrin because I also give out that same advice you do) I have
seen far more lucrative apps built by Shirky's rule than by ours.

    A> Depends on who is doing the revising, when.  If you wanted to
    A> "reach everyone involved with a production" then it is upwards
    A> of 200 people.  

I don't see this as the appropriate technology for reaching 200
people; that's why God invented memos.

    A> The way it's done most often now, is that the person with the
    A> idea for a script change simply goes, often individually to
    A> each of the folks it would need to be put past.  

Where do they get this list?

    A> This doesn't work so well, and has tendencies to cause swells
    A> in unexpected places.

And time lag due to communications mis-timings.  I've been involved in
the process that includes the "fish run", where tapes leaving Toronto
must catch the Vancouver/LA flights carrying fresh fish.

    A> ...  But, yes, if you wanted to get everyone involved in what
    A> any random script change might involve, you would need
    A> everyone.  

The scenarios we worked out with Norman Jewison and with some of the
Toronto-based animation houses never involved any of those sorts of
numbers, so I suppose this gets back to what you were saying before,
there's no way this app can replace all channels of communications for
all purposes, however there are situations where it is perfectly
appropriate.

    A> ...  You'd document why eating the extra oxygen, dissapating
    A> the extra heat, safely in the enclosed space, the extra weight
    A> et al was a bad idea, and bring it to your manager, who,
    A> hopefully you would know without a FOAF file.  

Funny you should mention this scenario.  When I worked at Cognos, this
was in actual fact a real problem.  It was a problem because any given
engineer might be involved in as many as half a dozen projects each
with a different chain of command.  Org chart navigation was a daily
thing.  It was worse at Bell Canada because we had the same
time-sharing of technical talent, but the org charge seemed to change
(radically) almost weekly.

But yes, that's the idea: To tie the org chart into the social
networking systems is an idea ex-E&Y business-strategist Dave Pollard
and I have discussed and he's developed that idea quite far with his
new business venture.

This gets back to what you were saying about security and maybe that's
the ticket, that we need a different sort of jabber server that is
intimately tied to the corporate org charting software.

    A> A FOAF in this case might be a strong temptation to sidestep
    A> the management chain, and have the assembly worker, or, even
    A> better the QA individual who is currently applying bactine, of
    A> going right to the horses ... mouth.

YES!  Exactly right.  Because this is what actually happens anyway.
This is exactly the direction of the current new-wave in industrial
engineering -- software that behaves the way people expect, not
software that just enforces the rules no one follows.

    A> Ok ... hrm ... this is starting to also sound like the
    A> enchantment/whiteboard project currently going on in the MIT
    A> Media Lab.  Now if I could just drag the two discussions into
    A> proximity ... *grin*

Do they have a FOAF file? :)

-- 
Gary Lawrence Murphy <garym@teledyn.com>
www.teledyn.com/mt - www.teledyn.com - sbp.teledyn.com
You don't play what you know; you play what you hear.
From carl at betterbilling.net  Mon Apr  5 00:57:21 2004
From: carl at betterbilling.net (Carl Tanner)
Date: Mon Apr  5 02:09:33 2004
Subject: [Jabberzilla] Re: Jabberzilla Digest, Vol 5, Issue 3
In-Reply-To: <200404021703.i32H3361032690@localhost.mozdev.org>
References: <200404021703.i32H3361032690@localhost.mozdev.org>
Message-ID: <4070F541.8070209@betterbilling.net>

If there was an easier way for mozilla/xul developers to implement a 
client for a jabber network, there might be.  Using the scripts from 
Mozilla Amazon Browser,  http://mab.mozdev.org , one can rapidly develop 
a similar web service that does not use amazon.com.  If there were 
possibly a library of functions for only the communications, a little 
creativity could reveal a new way of doing things on the internet.  I 
believe that jabber.com called it the "executable internet."

jabberzilla-request@mozdev.org wrote:

>Send Jabberzilla mailing list submissions to
>	jabberzilla@mozdev.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	http://mozdev.org/mailman/listinfo/jabberzilla
>or, via email, send a message with subject or body 'help' to
>	jabberzilla-request@mozdev.org
>
>You can reach the person managing the list at
>	jabberzilla-owner@mozdev.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Jabberzilla digest..."
>  
>
>------------------------------------------------------------------------
>
>Today's Topics:
>
>   1. Re: Suggestion... (GuruJ)
>  
>
>
> ------------------------------------------------------------------------
>
> Subject:
> Re: [Jabberzilla] Suggestion...
> From:
> GuruJ <GuruJ@mbox.com.au>
> Date:
> Fri, 02 Apr 2004 21:32:25 +1000
> To:
> jabberzilla@mozdev.org
>
> To:
> jabberzilla@mozdev.org
>
>
> Justin Kirby wrote:
> >> Then that's another problem out of the way.  In your model, are we
> >> down to three separate steps?  (1) Install Xerces; (2) Install oa
> >> XPI; (3) Install Jabberzilla?  If so, I could probably live with
> >> that.
> >
> > I actually bundle xerces-c into the xpi, so everything is there
> > in one.
>
> So what's the best way to obtain and install the XPI?  I'd be 
> interested in having a look at the implementation as it stands...
>
>> GuruJ wrote:
>
> <snip>
>
>>> ... My main problem with XMPP at the moment is that it still feels 
>>> strongly oriented towards generating an ICQ replacement.  However, 
>>> I'm sure that will ease as time passes - the spec itself isn't that 
>>> old, after all.
>>
>>
>>
>> Jabber itself is very old, the protocol has been around since 1999 
>> (technically before that). XMPP is just an ietf formalization of the 
>> jabber protocol. Admittedly, XMPP has a few differences, like the 
>> addition of SASL. However, XMPP is most definitely *not* an overhaul 
>> of the jabber protocol.
>>
>> I would strongly disagree with the ICQ statement. xmpp-core is an xml 
>> streaming protocol. xmpp-im adds presence and messaging as a layer 
>> ontop of -core. ICQ is a binary udp protocol. The only similarity is 
>> that they both have presence.
>
>
> I said *feels* like, not is.  Jabber beats ICQ in every way imaginable 
> as far as flexibility and implementation is concerned.  And I agree 
> that an implementation of xmpp-core doesn't have to even mention 
> Instant Messaging, but ...
>
>> The way I look at it, is that xmpp is an extensible xml streaming 
>> protocol where the most popular use is IM.
>
>
> ... I just wish there were more applications out there that did 
> something more than just IM.  We've got, like *15* competing IM 
> implementations, but nothing much that goes beyond that.  Eric's 
> whiteboard project was actually pretty visionary as far as Jabber 
> implementations go.
>
> -- GuruJ.
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Jabberzilla mailing list
>Jabberzilla@mozdev.org
>http://mozdev.org/mailman/listinfo/jabberzilla
>  
>
From adam at cs.brandeis.edu  Sun Apr  4 21:23:31 2004
From: adam at cs.brandeis.edu (A Page In the Life Of ...)
Date: Mon Apr  5 19:22:54 2004
Subject: [Jabberzilla] the killer jabberzilla app
In-Reply-To: <m24qs322sp.fsf@maya.dyndns.org> (message from Gary Lawrence
	Murphy on Thu, 01 Apr 2004 09:25:26 -0500)
Message-ID: <200404050023.UAA10848@opal.haven.org>

-=> Subject: Re: [Jabberzilla] the killer jabberzilla app
-=> From: Gary Lawrence Murphy <garym@canada.com>
-=> Date: Thu, 01 Apr 2004 09:25:26 -0500
-=> 
-=> >>>>> "A" == A Page in the Life of <A> writes:
-=> 
-=>     A> Back when IRC was started, business meetings were held that
-=>     A> way, as well weddings, role-playing games, and even chess
-=> 
-=> Yes, _exactly_ right.  How could we do that?  Because the audience was
-=> small and close knit.  It is a very different world today.  
-=> 
-=> Another problem today: How many non-engineers (and non-students) do
-=> you know who have reliable IRC "addresses"?  I can count on the
-=> fingers of one hand the number of people over 30 that I know who know
-=> what IRC is let alone how to use it.
-=> 
-=> But they all have some kind of IM.
-=> 
-=>     A> ... how are you going to manage lists, getting to the right
-=>     A> lists, keeping those who shouldn't be spamming those lists
-=> 
-=> OK. Very good question. As I mentioned in the first post, the list is
-=> an external meta-link FOAF rdf file; it is the domain of the page
-=> /owner/ to decide how that file is generated.  

That's one way to do it, but it then ties your app to a whole outside
infrastructure.  There should be a better way.  (I hope.)

-=> The FOAF file specs who is in the CC list.  As for who can access that
-=> list, a simple extension might be an option to exclude anyone not
-=> already in the list, which then has all sorts of security/spoofing
-=> complications as you try to ascertain who is who.
-=> 
-=> A simple fix, a site could password protect the FOAF using http
-=> auth. This means the query service must be two-stage, one step to get
-=> the page into the browser and discover that it has been tagged with a
-=> live-CC list, then a second stage click-through to actually access
-=> that list.  If the list is behind http auth, the second stage will
-=> issue the pw challenge; being http auth, the access verification can
-=> be arbitrarily complex.

Hrm ... ok ... I can accept that, but it sounds very complex to set up and
maintain for the owner.  Is there any way we can do it within the Jabber
context?  Some sort of "dir" function, maybe?  For you already have auth
within the Jabber context, which is as (in)secure as the listmember
is. (As in: if I only have ssl-based auth members on my list, I know that it
is one level more secure than the lists with folks sending their IM login
information in the clear over the net, or the like.)  But it still doesn't
solve the problem with (lack of) discovery, and persistance of existance,
which is why I hesitated to suggest it in the first place.

-=>     A> ... if they are to be offline, then what's wrong with a mailing
-=>     A> list?
-=> 
-=> Timing, presence, immediacy.  The situation I observed in the courts
-=> offices is a good example.  They need to know /now/ because the judge
-=> has called the lawyers in and they have to be there.  No time to send
-=> any email and wait for a reply.  Lots of business documents have this
-=> scenario.

Yes, but it requires the lawyers to be logged into something, or what have
you, and the immediacy of a 'biff' program watching your mail is as
immediate as an IM, and has the same level of requirements.  Or possibly 
less, for in the case of the lawyers above, not only do they have to have
their IM client open, but they also have to not be engrossed in another
discussion such that they don't notice the "all-come" call in another
window/tab.

There should also be a way to set context-awareness, as in "I'm in a
meeting, and noone of the level below my boss should be able to disturb me
now."   Which might be beyond the scope of this, but ... is important to
consider, especially since now IM is available on things like Blackberries,
and Cellphones.

-=>     A> How does it connect up people with disparate paths and similar
-=>     A> intersts?  
-=> 
-=> Ah ... /very/ good question! :) ... we already have a common interest
-=> _a priori_ --- we are both reading the same page.  The _page_ owns the
-=> buddy list, not the people.  Once I have the list and the page, I then
-=> start asking questions about the people and their relation to this
-=> /specific/ web resource.

Ok ... might I suggest taking a look at Orkut?  They seem to be pioneering
the field in actual groupings, as opposed to the yahoo groupings which seem
to fail miserably (either things are too broad, or there is much more noise
than signal) they (yahoo) is beginning to fail in the same way that the
news hirarchy failed.  And Live-Journals are showing the beginning signs of
it as well.  I'm hoping that Orkut's different methodology might prove to
be more stable.  Part of the problem seems to be, that humanity, as a
whole, has a switch in it's head.  At some point the group goes beyond
"you, him, her, a couple of friends, and I" to "some group I sorta belong
to" and, at that point, the level of caring goes down, the "what's in it
for me" goes up, and the group is no longer a cohesive unit.  It's then a
mob led by a few outspoken types.  Now, this is sometimes a good thing, it
tends to work really well in the open-source model, for example, for the
couple of programmers and visionaries are the outspoken ones, and the rest
tend to provide sanity checks, and a test-bed, and a source of bug-reports,
so things work.  Not all open-source projects end up with the right
mixture, take a look at a bit ago, when the *BSD fracture happened.  But I
digress.  I believe my point was, getting the right people to the right
other people is a complex problem, not something simply solved by saying
either "Oh, he's already here ..." or "That's the problem of the person
hosting the page ..." for that's how "Killer apps" get stillborn.

-=> So pairing relevent interests come after the fact.  I see the buddy
-=> list and I read the paper and I think, "Did legal ok this?" and I
-=> check the live CC FOAF and it crawls the document buddy list FOAFs and
-=> discovers that Mr Bradley Martin is from Legal ... so I ask him.

Ahh ... and you'd put in the extra work for that, provided that all the
links and chains of communications were open, and available to you, and
there weren't any Blind Carbon Copies along the way, or secondary lines of
communications or the like.  In my experience, that never happens, but your
experiences might be different.  Your Milage Might Vary.  Also Mr. Bradley
might have been CC'd for his information, but not for his reccomendation,
or approval, and might be starting the company's case against the sender,
or looking to protect the company from the sender, or ... 

-=> Notice the difference here from the dating site.  I am asking for
-=> someone with legal interests even though I am not myself listed as
-=> having legal interests; instead of matching likes (remember, "likes
-=> repell, opposites attract") I am matching /needs/ and /wants/.

To each, according to his needs, from each according to his abilities.
Yes, I've seen it.  I've also seen it founder.

Simple example.  Is the company going to hire a member of the legal staff
to watch over, and be available for all the communications?  

In my experience they are seldom even willing to give a member of the Legal
Staff time to meet with the IT folks, when they are establishing policies,
much less the time to properly research said policies, and report back to
the IT staff in a timely manner.  For example, it took the CEO of the
company I worked with 30 seconds to decide that getting porn spam at work
could be considered sexual harrasment (and he was correct about that, as
far as my own personal research could tell) and told IT to write policy
about it, get it to him, and get it implemented in a week.  I'll leave the
details to be glossed over, but, let's just say, someone's presence doesn't
necessarily connote agreement, understanding, or even actually having
listened/read the matter at hand.

-=> Had we depended on any intersection of interests, it's quite unlikely
-=> my wife and I would have ever met.  There was a task (a gig) that
-=> required our /complimentary/ skills and, well, we just really liked
-=> working together ;)

Congradulations!  That's what communities are all about.  Getting people
working together, to find the best partners, and geting the best partners
doing the right things together.  I'm glad your partnership has worked.
Here's to it continuing for many years.

-=>     A> I'm not knocking it, I'm just pointing out questions that you
-=>     A> might want to think about for your implementation.
-=> 
-=> No problem -- I'm encouraged by the amount of discussion; this is all
-=> good stuff. Some of the questions so far were anticipated, some are
-=> quite new.

Glad I could be a straight man for some of them, and perhaps a flashlight
for the others.  I don't know the answers, hence why I ask questions.  It
would be silly to ask questions I knew the answers to, right?

-=> Back to Clay Shirky's paper, it's important to keep a perspective with
-=> an app like this: I don't intend for this to be a "every mother and
-=> their dog" application because that is not how IM works.  It's an
-=> application for a small audience, and because the content owner
-=> controls how names are tacked to the list, privacy and security are
-=> out of the scope of the application.  By making the app simple, by
-=> excluding problem domains, I drive up the probability that it is
-=> possible to actually build it ;)

Oh, of course, building from simple is good, but building a roadmap or
sketch of where simple is going, is also good.  A house is no good without
it's foundation, but if you just build a random foundation, the probability
that the house is really going to suit your needs, without major
modifications later ... well ...

One thing I consistantly point out to people (for example) is "Plan your
security from the beginning.  Adding it later is always a much more
expensive, and often times incomplete effort."  

Also know your resources.  If your clock has to phone up colorado, every
second, to ask what time it is, before doing the next tick, you are going
to end up very frustrated.  Yes it might be the most accurate clock in the
world, but ... designing only from the macroscope doesn't work either.

-=>     A> It has to scale, not necessarily in the connection of how to
-=>     A> talk to any number of people, for Jabber already scales for
-=>     A> that, but in terms of connecting up all the possible folks to
-=>     A> the right place.
-=> 
-=> I don't follow. I use IM every day and I've never had this problem.
-=> The largest discussiong group I've ever /needed/ on IM was 4 people.

Ahh ... needed.  Hrm ... might be that your needs are different than mine.
For example, I have a role-playing game.  It's a table-top game (not
running around in the woods, or the like) so most of us have computers as
well.  (All right, we are all geeks ... ) There is the main thread of what
is going on.  This is mostly if not always out loud.  There is the
sub-thread of everyone connected to the GM for private actions.  (EG O.K.
I'm going to pick the pocket of the guy who is ostensably on our side, to
find out what credentials he is carrying are, and I'm going to
surripticiously share them with Ed, but I'm doing it so that Bonnie doesn't
see what's going on, because it would bother her moral code.) and the GM
has the same connection back to the individual players (Telling Ed what he
and I see.)  and often short multi-player, communications (Ed and I looking
over the docs, noticing that he has 4 ident-cards, each in a different
name, each with a different validation code, and some facinating levels of
food-chits available to him, and our decision to let Beth in on this,
because when she was young, the amount of food-chits assigned to her
family-unit slowly starved them to death and near-death, then her private
discussion with Eric, before the four of us start signalling to each other
what we are about to do (that's 5 of us right there)) and this is just a
simple scenario, that doesn't even take into account the remote players,
the various levels of logging going on, the time-based scripts that give us
the combat timing, and the like.

Oh, and during gaming the signal to noise ration is really high on the
signal side, because, even "distractions" often hold important
information.  Of course, some of them are red-herrings, but ... that's all
part of the game.

-=>     A> Depends on the information that is being sent out.  In your
-=>     A> example about reaching all the folks involved with a
-=>     A> production, you have upwards of 200 people
-=> 
-=> No way.  Really? 200 people needing to discuss the script changes?
-=> What do they do when there's a revision? Rent a hall?  

Depends on who is doing the revising, when.  If you wanted to "reach
everyone involved with a production" then it is upwards of 200 people.
The way it's done most often now, is that the person with the idea for a
script change simply goes, often individually to each of the folks it would
need to be put past.  This doesn't work so well, and has tendencies to
cause swells in unexpected places.  I've seen writers tear out their hair
over some changes, like "Well ... the Director OK'ed (or suggested (O the
horors)) it, just fix whatever else." Might mean another 2 days of
re-shooting, and perhaps some over-dubbing to make things match later, or
just hoping that the audience won't notice, or will make up their own
explainations later.  But, yes, if you wanted to get everyone involved in
what any random script change might involve, you would need everyone.  The
list for any particular script change is much shorter, but, since you'd
have to construct that list by hand, every time, anyway, the only benefit
having the whole page up there would do, would be to give you a starting
point, and, theoretically, if you have enough weight to effect a script
change, you should already know all the people involved, quite directly.

Think on the differences of "I'm an exile"  "I'm and ex-patriot" and "I'm
an excommunicate".  

But that's another rat-hole I've wandered down.

-=> I cannot believe this assertion, and when I did some work for Bell
-=> that involved Norman Jewison, nobody mentioned town hall meetings
-=> about scripts, all the scenarios were at most board-room sized.

And that was probably unusual, for each script change, not only changed
many times from the birth of the thought of the change, to it's final form,
but it also involved going through many people's hands on an individual
basis.  By the time they reached board-room sized meetings, it was probably
either already decided, or was trying to get rammed through by sheer force
of will.  But the latter won't work under IM, (everyone's voice is the same
weight) so I'm willing to bet that the "final" decisions will still be
board-room (or a few people sitting around grouping) decisions as long as
that means one person via persistance, power, or charisma can get what they
want that way.

-=> Even in the case of the Boeing 767, there was maybe a few hundred
-=> people in the CC list for the design specs, but there was never ever a
-=> case where more than a handful were needed to be in simultaneous
-=> interactive real-time contact over design issues.  Engineers meet,
-=> tool and die makers meet, assembly foremen meet, but if the assembly
-=> workers discovered a problem for the engineers, it was still handled
-=> by the proper chain of communications, and that's another situation
-=> where the FOAF can help because I can IM my supervisor, who then reads
-=> the spec and decides to IM the head of manufacturing, who reads teh
-=> spec and IMs the head of engineering, who reads the spec and IMs the
-=> engineer who thought a barbeque in First Class was a Good Idea.

RIght ... but that can all be handled by signatures on the plan, and
knowing one's TOC to begin with, and has nothing (as far as I can tell?) to
do with what you are proposing, for what you are proposing would be that
everyone who touched the plan would have what their job was, and why they
were on the list in a FOAF file, and you would be the one going to the
engineer who though the auto-light feature he saw in his Better Homes and
Gardens magazine was so neat, he needed to put it into everything he did.
The way things work currently is, as you described above.  You'd document
why eating the extra oxygen, dissapating the extra heat, safely in the
enclosed space, the extra weight et al was a bad idea, and bring it to your
manager, who, hopefully you would know without a FOAF file.  He'd then
decide, being your manager if any of the words needed ... interpretation
for higher management to consider, and possibly podern if your suggestion
as to what to do the the engineer who came up with the idea in the first
place is even anatomically possible, before re-appropriatizing the words to
make sure your meaning was carried fully without causing similar
speculations up-chain, and passing it off, as all management is designed to
do, until it finally got to the right place, each from the hand of a person
to the hand of another person that is quite well known to each.  

A FOAF in this case might be a strong temptation to sidestep the management
chain, and have the assembly worker, or, even better the QA individual who
is currently applying bactine, of going right to the horses ... mouth.

-=> Maybe this isn't really an appropriate application for Jabberzilla
-=> because this really should be jabber-client neutral and just for embed
-=> the jabber /presence/ state into the Mozilla frame (external to the
-=> actual web page) in a form that makes it possible to click and launch
-=> a client.  It would be more seemless (esp for those without IM) to
-=> click the link and have a chatzilla-like frame appear for the IM
-=> client, but that's not essential (and a great deal more work ;)

Hrm ... maybe, maybe not.  I'm not sure it should be entirely Jabberzilla
nutral, for there are two pieces to this.  If the data-structures are to be
built inside of Jabber, nutrally, the information has to originate from
somewhere, being able to pull in TOC information, FOAF information,
playbill information, Orkut group information, Live-Journal information, et
al would definitely be something that should exist, perhaps in the bridge
between Jaberzilla and Mozilla web browser.  Also in that gap might be
something that would bring in calendaring information, or perhaps vCard
information or the like.  Once in there, using that information usefully,
in both directions, would be, also, very good.  Say there is a group,
somewhere in the Jabber tree, that has an update-page, such that, when you
click on the link, your information inside your Jabber tree, somewhere, is
updated.

Ok ... hrm ... this is starting to also sound like the
enchantment/whiteboard project currently going on in the MIT Media Lab.
Now if I could just drag the two discussions into proximity ... *grin*

-dkap

-=> -- 
-=> Gary Lawrence Murphy <garym@teledyn.com>
-=> www.teledyn.com/mt - www.teledyn.com - sbp.teledyn.com
-=> You don't play what you know; you play what you hear.

From carl at betterbilling.net  Tue Apr  6 13:57:25 2004
From: carl at betterbilling.net (Carl Tanner)
Date: Tue Apr  6 15:09:42 2004
Subject: [Jabberzilla] same page and acceleration
Message-ID: <4072FD95.7090605@betterbilling.net>

Pardon my saying this, but even though we have a lot of good ideas and 
discussion going around, this needs to be said.  Not all IM is the 
same.  It sounds as if some of the well intentioned participants have 
not fully explored the current status of what the jabber server offers 
and what some jabber clients can currently do compared to the IM systems 
of Yahoo, MSN, and AOL.  Not all IM is the same.  Everyone should 
participate on a jabber network if he has not done so already (I use 
jabber.org).  For example, some posts sound as if the writer believes 
that the user needs to be online to receive an IM.  That is not the case 
with jabber.  If the user is offline, then the message waits for the 
user until he logs in.  Also, since the roster (read Buddy  List) 
reflects his current presence,  the one trying to message the user can 
see that he is offline and can send an IM to the email address of the 
user's pager or cell phone.

If you haven't grabbed a jabber client at 
http://www.jabber.org/software/clients.php?PHPSESSID=c750f48f544768870f106a28eba21f1a 
, please give one of the clients a try. I like Psi for now, since it is 
cross-platform, but another open-source alternative is Exodus for those 
who use MS Windows.

Something for discussion:
Also, I believe that we could and should  accelerate development of 
jabberzilla with the tools of jabber.  I think that we could open up a 
logged conference room like jdev at jabber.org, complete with chatbot.  
We could have the log either emailed to the mailing list, or put into an 
RSS feed for access by tbird and forumzilla.  These two options alone 
would allow more flexibility to developers.  We get the immediacy of IRC 
and the community benefits of a mailing list.  We could stay in touch 
with the current developments, more easily collaborate new ideas and the 
current challenges, and possibly inject a little more life into the 
project's progress.
What do you think?
From stpeter at jabber.org  Tue Apr  6 17:24:26 2004
From: stpeter at jabber.org (Peter Saint-Andre)
Date: Tue Apr  6 18:36:18 2004
Subject: [Jabberzilla] same page and acceleration
In-Reply-To: <4072FD95.7090605@betterbilling.net>
References: <4072FD95.7090605@betterbilling.net>
Message-ID: <1081290266.8895.19.camel@wrk57.corp.jabber.com>


> Also, I believe that we could and should  accelerate development of 
> jabberzilla with the tools of jabber.  I think that we could open up a 
> logged conference room like jdev at jabber.org, complete with chatbot.  
> We could have the log either emailed to the mailing list, or put into an 
> RSS feed for access by tbird and forumzilla.  These two options alone 
> would allow more flexibility to developers.  We get the immediacy of IRC 
> and the community benefits of a mailing list.  We could stay in touch 
> with the current developments, more easily collaborate new ideas and the 
> current challenges, and possibly inject a little more life into the 
> project's progress.
> What do you think?

Created. I'll invite Chatbot and y'all can chat away.

jabberzilla@conference.jabber.org

Logs here:

http://www.jabber.org/muc-logs/jabberzilla@conference.jabber.org/

Peter



From emurphy79 at cox.net  Thu Apr  8 23:19:05 2004
From: emurphy79 at cox.net (Eric Murphy)
Date: Thu Apr  8 23:32:09 2004
Subject: [Jabberzilla] Mozilla Looking to Forge Alliances...
Message-ID: <40761629.2050800@cox.net>

http://mozillazine.org/talkback.html?article=4584

What alliance could Jabber have with Mozilla?

Brenden wants to have a "Mozilla platform" for application development 
and deployment. This is defintitely a reaction to Microsoft's Longhorn 
stuff with XAML and Avalon. I'm trying to think how Jabber could fit in 
with this. I mean, does having IM "native" to a Mozilla platform through 
Jabber make it more attractive?

Eric

From stpeter at jabber.org  Fri Apr  9 11:53:36 2004
From: stpeter at jabber.org (Peter Saint-Andre)
Date: Fri Apr  9 12:05:30 2004
Subject: [Jabberzilla] Mozilla Looking to Forge Alliances...
In-Reply-To: <40761629.2050800@cox.net>
References: <40761629.2050800@cox.net>
Message-ID: <20040409155336.GA9805@jabber.org>

On Thu, Apr 08, 2004 at 10:19:05PM -0500, Eric Murphy wrote:
> http://mozillazine.org/talkback.html?article=4584
> 
> What alliance could Jabber have with Mozilla?
> 
> Brenden wants to have a "Mozilla platform" for application development 
> and deployment. This is defintitely a reaction to Microsoft's Longhorn 
> stuff with XAML and Avalon. I'm trying to think how Jabber could fit in 
> with this. I mean, does having IM "native" to a Mozilla platform through 
> Jabber make it more attractive?

It's been on my list to follow up with Brendan for some time. Guess I
need to bump it up. What could streaming XML bring to the table? It's a
lot more than chat, I think.

Peter

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

From carl at betterbilling.net  Fri Apr  9 11:37:16 2004
From: carl at betterbilling.net (Carl Tanner)
Date: Fri Apr  9 12:49:43 2004
Subject: [Jabberzilla] Re: Jabberzilla Digest, Vol 5, Issue 8
In-Reply-To: <200404091602.i39G2G61069540@localhost.mozdev.org>
References: <200404091602.i39G2G61069540@localhost.mozdev.org>
Message-ID: <4076D13C.1000709@betterbilling.net>

I think so.  One of the emphases at dev day was to be able to create 
online apps like Mozilla Amazon Browser ( http://mab.mozdev.org/ ), and 
toward the end of the day George Cao made a presentation about Rich 
Internet Applications (RIA's), and we are not just talking about IM 
chat.  Using an SVG enhanced build of mozilla, he showed how mozilla 
could be used to give the benefits and richness of locally installed 
application, yet be light and easy enough for the user to use and treat 
the remote RIA like a website.  To the user's eye, it was faster than a 
website.

Here's the gist:  He made it happen with jabber.  It was a key 
component.  By using jabber, he got all the advantages of "the 
executable internet."  He got something that felt like a live, 
instantaneous feed for the user.  He got all of the advantages that come 
with using xul instead of dhtml. He got to use it today, and not 
whenever MS will release longhorn.

Here's the caveat:  He had to create a proxy from REST to XMPP.  I think 
that he also had do some other experimental things.

If he had jabber native, it might be as simple as XMLHTTP  make it to do 
web services like MAB.  I believe that there are a lot of opportunities 
with RIA's. One of the futures is that, unless the website exists to 
provide documentation, the original task of html, it will be some sort 
of RIA.  With the right tools in place, moz could be a strong contender. 

I wish we could get the foundation to stream George's presentation.

jabberzilla-request@mozdev.org wrote:

>Send Jabberzilla mailing list submissions to
>	jabberzilla@mozdev.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	http://mozdev.org/mailman/listinfo/jabberzilla
>or, via email, send a message with subject or body 'help' to
>	jabberzilla-request@mozdev.org
>
>You can reach the person managing the list at
>	jabberzilla-owner@mozdev.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Jabberzilla digest..."
>  
>
>------------------------------------------------------------------------
>
>Today's Topics:
>
>   1. Mozilla Looking to Forge Alliances... (Eric Murphy)
>  
>
>
> ------------------------------------------------------------------------
>
> Subject:
> [Jabberzilla] Mozilla Looking to Forge Alliances...
> From:
> Eric Murphy <emurphy79@cox.net>
> Date:
> Thu, 08 Apr 2004 22:19:05 -0500
> To:
> jabberzilla@mozdev.org
>
> To:
> jabberzilla@mozdev.org
>
>
> http://mozillazine.org/talkback.html?article=4584
>
> What alliance could Jabber have with Mozilla?
>
> Brenden wants to have a "Mozilla platform" for application development 
> and deployment. This is defintitely a reaction to Microsoft's Longhorn 
> stuff with XAML and Avalon. I'm trying to think how Jabber could fit 
> in with this. I mean, does having IM "native" to a Mozilla platform 
> through Jabber make it more attractive?
>
> Eric
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Jabberzilla mailing list
>Jabberzilla@mozdev.org
>http://mozdev.org/mailman/listinfo/jabberzilla
>  
>
From emurphy79 at cox.net  Thu Apr 15 23:42:49 2004
From: emurphy79 at cox.net (Eric Murphy)
Date: Thu Apr 15 23:55:26 2004
Subject: [Jabberzilla] multipart/x-mixed-replace with XMLHttpRequest
Message-ID: <407F5639.2000203@cox.net>

http://bugzilla.mozilla.org/show_bug.cgi?id=237319

This is a new fix to Mozilla that allows XML streams to be used through 
HTTP. The HTTP server pushes data to the client. This could possibly be 
a boon for doing Jabber communications with Mozilla.

Maybe someone out there has time to investigate this, and make a simple 
testcase (client and server) to see if this is possible. If nobody does, 
then I may do it.

Eric