MozillaZine

The IM Project Page Has Vanished

Wednesday April 21st, 1999

The IM Project page has been taken down at the request of Netscape. Netscape was the contributor of the Instant Messaging API document, and they have taken it down pending further review. As far as we can tell, there is nothing more to the story at this point. We'll let you know when the page comes back online.


#1 Re:The IM Project Page Has Vanished

by Douglas Reay <douglas@beyond2000.co.uk>

Wednesday April 21st, 1999 8:51 AM

Reply to this message

It will be interesting if, when the page returns, they note the reason why it had to be temporarily removed.

On a positive note, perhaps they will take the change to make a flexible and bookmarkable interface to IRC, IM and others by specifying a new URL type, such as:

irc://-dalnet/ irc://-effnet/#help irc://-alternet/#gnudiscuss?nick=Aristotle irc://irc.dal.net:7000/#foobar

IE  a channel "-dalnet" could be looked up to find your preferred server     default nicks could be stored in the browser (possibly changable with     irc network and channel name)

#2 Re:The IM Project Page Has Vanished

by Sendmail

Wednesday April 21st, 1999 8:56 AM

Reply to this message

Pardon me for asking a stupid question, but if Netscape released the code under MPL, do they have the right to withdraw it?

#3 Re:The IM Project Page Has Vanished

by Jamie N. Katz <jamienk@bigfoot.com>

Wednesday April 21st, 1999 9:03 AM

Reply to this message

I find it dishonest for you to say that there is nothing more to the story. WHY did they ask that it be pulled? What do the people who administrate the Moz project feel about this? What directions will the Moz people go in if Netscape's "further review" turns out to be a bid for proprietartyness?

This is the first time that I have seen a public rift between Netscape an Mozilla, and I think that how Moz handles this will be very telling.

#4 Re: The IM Project Page Has Vanished

by Stephen Donner <sdonner@earthlink.net>

Wednesday April 21st, 1999 9:54 AM

Reply to this message

AOL made them..don't you see? AOL already has two flagship projects, ICQ and Instant Messenger. YOu people just don't get it!

#5 The IM Project Page Has Vanished

by bubba

Wednesday April 21st, 1999 9:56 AM

Reply to this message

How can anybody thrust mozilla/MPL/MPL if netscape or just anyone can pull a project ?, and how can they do it if the code relly are under a real open-sorce lisense and not one of the semi-open ones?

#6 Re:The IM Project Page Has Vanished

by logo

Wednesday April 21st, 1999 10:24 AM

Reply to this message

Hey bubba and others,

This project from what I've read is a NETSCAPE project, there was no source code committed, it was only an API spec, and preliminary work (docs) that had been made available on the server. Nothing wrong has been done, except a communication clash by Netscape (documents released to public too soon).

Stop this paranoia about Mozilla/Netscape! IMHO its perfectly OK for Netscape to withdraw documents that have been released too soon from the Mozilla WEB server.

When/if they (Netscape) consider that's its OK to publish this information they'll do it.

#7 Re:The IM Project Page Has Vanished

by Troy

Wednesday April 21st, 1999 10:25 AM

Reply to this message

I will be sad if (as it seems to be) Netscape/AOL is going home and taking their ball with them. I do not think their ICQ/IM project will be as successful or rich as it could be without community help.

#8 I see

by bubba

Wednesday April 21st, 1999 10:30 AM

Reply to this message

>it was only an API spec, >and preliminary work (docs) >that had been made available >on the server

Okey, well it was handled in a bad way, what do they expect people to think when the page describing a very intressting project sais everything has been pulled by netscape for further review?

#9 Re:The IM Project Page Has Vanished

by arielb

Wednesday April 21st, 1999 11:11 AM

Reply to this message

<http://www.news.com> already did a story on mozilla IM and it looks really dumb right now :(

#10 It's a DOCUMENT!

by asa <asa@mozilla.org>

Wednesday April 21st, 1999 1:51 PM

Reply to this message

Netscape decided to contribute a document describing an API. Then they decided that they didn't want to make it public yet. They didn't seize any code. They didn't kill an active project. This isn't the _event_ most of you seem to be making of it.

#11 Re:The IM Project Page Has Vanished

by Kovu <Kovu401@netscape.net>

Wednesday April 21st, 1999 2:09 PM

Reply to this message

The problem may be that to do this properly AOL would have to open IM and ICQ sourcecode to make it work properly. This is obviously a gray area at this point. If AOL opens IM do they then have to open AOL sourcecode because IM is part of that? See how it could be confusing? It is an issue that obviously needs to be dealt with now and someone at Netscape probably just jumped the gun on it.

#12 Re:The IM Project Page Has Vanished

by arielb

Wednesday April 21st, 1999 2:26 PM

Reply to this message

heh someone posted the API spec to slashdot

#13 Re:The IM Project Page Has Vanished

by Strangelove

Wednesday April 21st, 1999 3:29 PM

Reply to this message

IM-API -- Instant Messaging API

Terry Weissman Travis Bogard Sudharshan Srinivasan

Goals

One of the fundamental strengths of the browser has always been the ability to hide the messy details of diverse network protocols under a simple user interface. The same client can go talk to servers speaking HTTP, FTP, Gopher, etc., and provide a fairly consistent interface to them all.

We would like to make Mozilla be able to do chatting and "instant messaging". However, we don't want to limit ourselves to a single server, or a single protocol. People today are chatting using a variety of different protocols and servers. We would like Mozilla to be able to usefully talk to all of these protocols, and hide most of the differences from the user.

On the other hand, we also don't want to hard-code knowledge of every known chat protocol into the code base. We would like to have a "pluggable" architecture, where it would be possible at any time to write up a new module for a new protocol, and Mozilla would just work with it.

IM-API defines the API for people wanting to make Mozilla speak a new chat protocol.

The big picture

The whole IM/Chat module will be an separate module from the rest of the Mozilla client; it will be possible to build the client without any IM/Chat support at all.

The IM/Chat module will include lots of UI code and stuff. But to actually speak a chat protocol, it will look in the registry for classes that provide the nsIMServer interface. Each of those classes represent a different protocol. When the client wishes to connect to a chat protocol, it will create an instance of the appropriate nsIMServer object, connect() to the service, and start calling getService() to get the Service objects it needs. The client will implement the corresponding Listener interfaces defined below for any Service objects it needs.

So, for a new protocol, you need to define which of the below services make sense for your protocol. You will define an object that implements nsIMServer, and make its GetService() method return objects you define for the services you support. You do not have to define any of the Listener classes; those are generally defined by the client.

As things get further flushed out, and actual UI code gets added, we plan to add stuff so that a particular protocol can add things to the UI to support protocol-specific stuff. The additional UI will probably end up calling additional interfaces provided by the protocol. We do not expect that all calls to the protocol module will go through this IM-API, but we do hope that most of them do.

The API

Random notes about the API:

Any interface whose name ends with "Listener" is generally implemented by the main client code, not by a protocol module. The stuff in IM_APIExt.h is optional. This is the place for features that some implementations of a service will have, and some will not. The user of a service will be able to QueryInterface to determine if a given feature is supported.

Details about this API that I know are wrong and need to be fixed:

I need to #define the NS_IIM* constants properly. Where do these magic numbers come from? Do I need to port this to IDL? I don't talk about how objects get constructed. Factories, mumble, mumble. The unpickle() calls are pretty constructor-ish, though. The names are all currently prefixed with the string "nsIM". I'm not sure if that's a sufficiently unique prefix. There is no RDF in here. I think it likely that much of the pickle/unpickle awkwardness may get replaced with something RDFish. Appropriate experts need to be consulted. Some other questionable things are called out in green italic text. Everywhere we pass HTML text, we might also need to pass some other info (like, maybe, encoding information for proper i18n support)?

************************ IM_APIBase.h ************************

/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 2 -*- */ /* The contents of this file are subject to the Mozilla Public License Version 1.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at <http://www.mozilla.org/MPL/>

Software distributed under the License is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License for the specific language governing rights and limitations under the License.

The Original Code is IM-API.

The Initial Developer of the Original Code is Netscape Communications Corporation. Portions created by Netscape are Copyright (C) 1999 Netscape Communications Corporation. All Rights Reserved.

Contributor(s): */

// This file defines the core IM_API functionality: the main services // that a protocol module is likely to want to implement, and the // associated Listener and other interfaces.

// This lists the different availability states a person can be in. // I'm not yet certain if this is the appropriate // generic list.

enum nsIMAvailability { Present, // The person is alive and on-line Gone, // The person is not connected Away, // The person is on-line but is not at his // computer. Unknown, // The protocol is not actively tracking the // presence of this user, and so his state // is not known. };

// The nsIMServer interface represents the main connection to a server. // One instantiation of it will be created for each connection to a // chat server. Thus, if the user wishes to speak to 3 different IRC // servers, there will be three instances of the IRC implementation of // nsIMServer. // // The nsIMServer interface only deals with things having to do with the entire // server connection; basically, whether it is actually connected or not. To // actually do something using the server, you must use the getService() method // to get a service object for the service you want.

class nsIIMServer : public nsISupports { public: NS_DEFINE_STATIC_IID_ACCESSOR(NS_IIMSERVEROBJECT_IID)

// setServerListener() sets the object this server should use to // report asynchronous events and messages. PRStatus getServerListener(nsIIMServerListener*);

// getServerListener() returns the listener object. nsIIMServerListener* getServerListener();

// getShortDescription() returns a short name for this server, suitable for // use in a list of server names. If you can have multiple instantiations // of the same kind of server (for example, to do multiple IRC hosts, or to // allow people to have multiple AIM screennames for themselves), then the // string for each instantiation ought to be unique. const char* getShortDescription();

// configure() causes this server instantiation to pop up a dialog box // allowing the user to configure all options about the server in general // (hostname, port number, screenname, password, etc.) // It is undefined whether this will return immediately or wait until the // user has finished the operation. PRStatus configure();

// connect() causes a connection to be made to the server. This call // blocks until a connection is firmly established. PRStatus connect();

// disconnect() causes any connection with the server to be dropped. // This call blocks until the connection has been dropped. PRStatus disconnect();

// isConnected() returns whether there is a current connection to the // server. PRBool isConnected()

// GetService() returns a pointer to the object that implements the // given service (which should be on of NS_IIMIMSERVICE_IID, // NS_IIMCHATSERVICE_IID, NS_IIMPRESENCESERVICE_IID, etc.) If the // given service can be found, the pointer is set; if the service // is not supported, an error code is returned and the pointer is // set to NULL.

NS_IMETHOD GetService(REFNSIID iid, void** instancePtr); };

// The nsIIMServerListener interface gets called with asynchronous events that // relate to the whole server (not particular to any service within it).

class nsIIMServerListener : public nsISupports { public: NS_DEFINE_STATIC_IID_ACCESSOR(NS_IIMSERVERLISTENER_IID)

// If we ever lose the connection to the server, then this function will // be called. "why" is an error message that can be displayed to the user, // explaining what happened. Is passing this as a // string the right I18N thing to do here? PRStatus lostConnection(const char* why); };

// The nsIIMIMService interface (and I really *hate* that name, but // everything else is either too long or too inconsistant with other // names here) provides the instant messaging service.

class nsIIMIMService : public nsISupports { public: NS_DEFINE_STATIC_IID_ACCESSOR(NS_IIMIMSERVICE_IID)

// setIMListener() sets the object this server should use to // report asynchronous events and messages. PRStatus setIMListener(nsIIMIMListener*);

// getIMListener() returns the listener object. nsIIMIMListener* getIMListener();

// sendMessage() causes an instant message to be delievered to the given // user. This call blocks until the message has been delivered. PRStatus sendMessage(nsIIMIndividual* dest, const char* html); };

// The nsIIMIMListener interface gets called with asynchronous events that // relate to the instant messaging service.

class nsIIMIMListener : public nsISupports { public: NS_DEFINE_STATIC_IID_ACCESSOR(NS_IIMIMLISTENER_IID)

// receiveMessage() gets called whenever someone out on the network sends // us an instant message. PRStatus receiveMessage(nsIIMIndividual* source, const char* html); };

// The nsIIMChatService interface provides support for the chat service.

class nsIIMChatService : public nsISupports { public: NS_DEFINE_STATIC_IID_ACCESSOR(NS_IIMCHATSERVICE_IID)

// setChatListener() sets the object this server should use to // report asynchronous events and messages. PRStatus setChatListener(nsIIMChatListener*);

// getChatListener() returns the listener object. nsIIMChatListener* getChatListener();

// listKnownRooms() returns a list of room names that are known to exist // with this chat service. It does not necessarily return every room that // is actually out there, just the ones that are currently known to exist. // This ListOfStrings return type is just a // placeholder; I hope such a class does exist. ListOfStrings* listKnownRooms();

// getRoom() returns the room object corresponding to the given name, or // NULL if no such room exists and can't it can't created. nsIIMChatRoom* getRoom(const char* name); };

// The nsIIMChatListener interface gets called with asynchronous events that // relate to the chat service.

class nsIIMChatListener : public nsISupports { NS_DEFINE_STATIC_IID_ACCESSOR(NS_IIMCHATLISTENER_IID)

// roomChanged() gets called whenever a room appears or disappears from // the list of known rooms. It is legal for listKnownRooms() to return // a different list on two successive calls without any intervening calls // to roomChanged() happening; that is, some protocols may only support // polling on the list of rooms and will not provide asynchronous // updates. PRStatus roomChanged(const char* name, PRBool added // True if added, False if removed. );

// receiveInvitation() gets called when the user has received an invitation // to join a room. PRStatus receiveInvitation(nsIIMIndividual* who, // Who sent the invitation const char* roomname, // What room we're // invited to const char* extratext // Any extra text to // display as part of the // invitation. This is // HTML. ); };

// The nsIIMPresenceService intervening provides support for the presence // indication service, the service that lets you track a list of individuals // on the network and report whether they are currently on-line.

class nsIIMPresenceService : public nsISupports { public: NS_DEFINE_STATIC_IID_ACCESSOR(NS_IIMPRESENCESERVICE_IID)

// setPresenceListener() sets the object this server should use to // report asynchronous events and messages. PRStatus setPresenceListener(nsIIMPresenceListener*);

// getPresenceListener() returns the listener object. nsIIMPresenceListener* getPresenceListener();

// addUser() causes us to start watching for presence of the given user. PRStatus addUser(nsIIMIndividual*);

// removeUser() causes us to stop watching for the given user. PRStatus removeUser(nsIIMIndividual*);

// removeAll() clears the list of all users that we are watching. PRStatus removeAll();

// getWatchList() returns the list of all users that we are watching. // The nsIIMIndividualList class is a placeholder; // I hope we have a standard easy way of doing this. nsIIMIndividualList* getWatchList(); };

// The nsIIMPresenceListener interface gets called with asynchronous events // that relate to the presence service.

class nsIIMPresenceListener : public nsISupports { public: NS_DEFINE_STATIC_IID_ACCESSOR(NS_IIMPRESENCELISTENER_IID)

// userAvailabilityChange() gets called whenever the given user goes // online, offline, or otherwise changes.

PRStatus userAvailabilityChange(nsIIMIndividual* who); };

// The nsIIMIndividual interface represents a person out on the network.

class nsIIMIndividual : public nsISupports { public: NS_DEFINE_STATIC_IID_ACCESSOR(NS_IIMINDIVIDUAL_IID)

// getAvailability() returns the current availability information for // the given user. If block is True, then the caller is willing to wait // in order to get the most accurate information; if False, then the // call should return immediately (which may very well lead to a result // of Unknown.) Actually, the caller should always be ready for a result // of Unknown; some protocols may not be able to determine availability // in some circumstances. nsIMAvailability getAvailability(PRBool block);

// getIDString() returns a short identifying string used by the protocol // to identify this person. Note that some protocols may change this // string over time; it is best for callers to remember people by their // pointer, not by their idstring. const char* getIDString(); };

// The nsIIMChatRoom interface represents a chat room. This acts much like // a service, in that it has a corresponding listening class. However, unlike // most services, there can be multiple instantiations of this for a single // protocol, one per chat room that we are connected to. The existance of // a nsIIMChatRoom object implies that the user is connected to it; to // disconnect from a chat room, the client should drop its references to // the nsIIMChatRoom object.

class nsIIMChatRoom : public nsISupports { public: NS_DEFINE_STATIC_IID_ACCESSOR(NS_IIMCHATROOM_IID)

// setChatRoomListener() sets the object this server should use to // report asynchronous events and messages. PRStatus setChatRoomListener(nsIIMChatRoomListener*);

// getChatRoomListener() returns the listener object. nsIIMChatRoomListener* getChatRoomListener();

// getDisplayName() returns a brief name for this room. const char* getDisplayName();

// getDescription() returns a description or "topic" for this room. const char* getDescription();

// sendMessage() sends a message to the chat room. It is assumed that the // listener's receiveMessage() will get called soon thereafter with this // same message. If that doesn't happen as a side effect of the network // protocol, then the protocol module must call receiveMessage() itself. PRStatus sendMessage(char* html);

// sendInvitation() invites someone to join this chat room. extratext is // extra HTML text to explain the invitation. If the underlying protocol // doesn't support extra text with an invitation, then it should try to // get that text to the receiving user somehow (i.e., send an instant // message with that text just ahead of the invitation). PRStatus sendInvitation(nsIIMIndividual* who, const char* extratext);

// listMembers() lists who is currently connected to this room. nsIIMIndividualList* listMembers(); };

// The nsIIMChatRoomListener interface gets calle with asynchronous events // that relate to a specific chat room.

class nsIIMChatRoomListener : public nsISupports { public: NS_DEFINE_STATIC_IID_ACCESSOR(NS_IIMCHATROOMLISTENER_IID)

// receiveMessage() gets called whenever a person sends a message to the // chat room.

PRStatus receiveMessage(nsIIMIndividualList* who, const char* html);

// memberChange() gets called whenever someone leaves or enters the room. PRStatus memberChange(nsIIMIndividual* who, PRBool added // True if entered, False if left ); };

************************ IM_APIExt.h ************************

/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 2 -*- */ /* The contents of this file are subject to the Mozilla Public License Version 1.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at <http://www.mozilla.org/MPL/>

Software distributed under the License is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License for the specific language governing rights and limitations under the License.

The Original Code is IM-API.

The Initial Developer of the Original Code is Netscape Communications Corporation. Portions created by Netscape are Copyright (C) 1999 Netscape Communications Corporation. All Rights Reserved.

Contributor(s): */

// This file defines strictly optional interfaces for features that // are known to be supported only by some protocols.

// ########## EMOTE SUPPORT Some protocols allow for messages that are // "emoted". ("emoting" refers to the ability to express emotions instead of // just sending text -- the ability to say in a chat room "terry feels sick", // rather than having to do "terry: I feel sick".) If a protocol supports // emoting in instant messages, then the objects supporting the nsIIMIMService // and nsIIMIMListener interfaces need to also support the nsIIMIMEmoteService // and nsIIMIMEmoteListener interfaces, respectively. Similarly, if the // protocol supports emoting in chat messages, then the objects supporting the // nsIIMChatRoom and nsIIMChatRoomListener interfaces need to also support // the nsIIMChatRoomEmote and nsIIMChatRoomEmoteListener interfaces, // respectively. // // This is an annoying number of extra interfaces to support a simple thing // like "emote". However, we don't have a better idea. It does give the // most flexibility, and makes things simple for the simpler protocols that // do not do emote.

class nsIIMIMEmoteService : public nsISupports { NS_DEFINE_STATIC_IID_ACCESSOR(NS_IIMIMEMOTESERVICE_IID)

// sendEmote() is just like sendMessage() in nsIIMIMService, but the // message is sent emote-style. PRStatus sendEmote(nsIIMIndividual* dest, const char* html); };

class nsIIMIMEmoteListener : public nsISupports { NS_DEFINE_STATIC_IID_ACCESSOR(NS_IIMIMEMOTELISTENER_IID)

// receiveEmote() is just like receiveMessage() in nsIIMIMListener, but // the message is sent emote-style.

PRStatus receiveEmote(nsIIMIMListener* source, const char* html); };

class nsIIMChatRoomEmote : public nsISupports { NS_DEFINE_STATIC_IID_ACCESSOR(NS_IIMCHATROOMEMOTE_IID)

// sendEmote() is just like sendMessage() in nsIIMChatRoom, but the // message is sent emote-style. PRStatus sendEmote(const char* html); };

class nsIIMChatRoomEmoteListener : public nsISupports { NS_DEFINE_STATIC_IID_ACCESSOR(NS_IIMCHATROOMEMOTELISTENER_IID)

// receiveEmote() is just like receiveMessage() in nsIIMChatRoomListener, // but the message is sent emote-style.

PRStatus receiveEmote(nsIIMIMListener* who, const char* html); };

#14 Re:The IM Project Page Has Vanished

by DougV

Wednesday April 21st, 1999 4:37 PM

Reply to this message

One of the reasons that people are reluctant to become involved in Mozilla is because they fear that Netscape/AOL will forget the meaning of "Open Source" and try to take control of the project. They do not want to be seen as unpaid employees of Netscape/AOL; they want to know that they are the ones who control the project that they are working on.

There is no valid reason to censor a web site dedicated to open source programming. If there was an error in the specification, then a suggestion could have been posted. Design flaws can be corrected. However, to totally remove code pending a review suggests to me that AOL was nervous that someone had revealed too many secrets about its Instant Messenger. If they just wanted to iron out details of the standard, they could have let the public make suggestions as well. The decision reeks of Big Brother.

#15 Re:The IM Project Page Has Vanished

by stephan <stephan@micropop.com>

Wednesday April 21st, 1999 5:06 PM

Reply to this message

I guess the person responsible for the release of the mentioned source code is going through hell at Netscape right now. S/he released code that the company later decided was not to be released. That's not good PR - when Netscape decided to withdraw the code there has to be good reasons for that. Noone would deliberately try to get their own company bad PR.

I did like the chat concept that was lined up in the contribution that was available at the mozilla.org project and I do believe that there is a future for such a functionality. Obviously, the only means available to us is stating our opinions to Netscape through the e-mail address supplied at the page where the IM-API used to be. We should make use of this opportunity to make Netscape realise what we think about this development.

(By the way, if anyone has any useful Mozilla resources, I would like to know. I'm currently finishing a page ( at <http://www.micropop.com/s/browsers/mozilla/> ) about Mozilla, pages about Mozilla and accessories/add-ons/XULs available. I would appreciate feedback).

#16 Re:The IM Project Page Has Vanished

by Daikoku <Daikoku@bigfoot.com>

Wednesday April 21st, 1999 10:41 PM

Reply to this message

Please, No more bloat, When they get the basics of a browser finished, then worry about the secondary junk.

Let me say thank you to Netscape/AOL for pulling the very premature idea out before it wasted any more resources.

Mozillia folks, please get the basic browser/email/ftp stuff to at least a beta state before adding more on to the project.

#17 Re:The IM Project Page Has Vanished

by -s

Wednesday April 21st, 1999 11:02 PM

Reply to this message

Umm, this chat stuff was being implemented by people who are not working on the browser anyways, so, no, it wouldn't take away from browser development. And if it gets more external people interested in mozilla, then everybody wins.

#18 Re:The IM Project Page Has Vanished

by Kovu <Kovu401@netscape.net>

Wednesday April 21st, 1999 11:58 PM

Reply to this message

thank you -s I have wanted ICQ integration into NS for a LOOOONG time, and as long as resources aren't diverted from Communicator they should go with it. If the code's not done by M9 then it will have to wait til 2.0. Heck, they have to have SOME features to add later. Still, it would be nice for the final version. I'm drooling over the mail integration with multiple IMAPs, POPs, and Webmail. ICQ and IM have to be next.

#19 Re:The IM Project Page Has Vanished

by David Lewari <dlewari@warzc.com>

Thursday April 22nd, 1999 3:04 AM

Reply to this message

Thanks to Netscape, we got some more time to finish our "WarIChac" product, replacing IRC, ICQ, AOL-IM and so on with one MUCH better product. And this obsoletes Mozilla.org's efforts, too. Sorry, no more piece of the market left =:-)

#20 Re:The IM Project Page Has Vanished

by Guy Murphy <guy_murphy@dialog.com>

Thursday April 22nd, 1999 4:20 AM

Reply to this message

Bad Mozilla ::slap:: bad, bad, bad Mozilla ::slap:: ::slap::... how dare you threaten AOLs product line :P

David went out to slay Goliath and ended up indentured to his brother.

#21 Re:The IM Project Page Has Vanished

by Pyro

Thursday April 22nd, 1999 6:06 AM

Reply to this message

As far as I can tell, no source was released. I agree with the people who say that this is secondary and shouldn't be worked on right now. Even if "outside" people wanted to work on it, it would still require a knowledgeable programmer (senior level) to keep stuff under control. After all, it has to be released under the Netscape/Mozilla name, and they shouldn't release a product over which they have no control over the code. For only outside people to work on it would most likely create a half baked piece of work. Chances are that an IM API open source project won't gather nearly as many programmers as Linux, or even Mozilla itself.

#22 Pyro, what are you talking about?

by asa <asa@mozilla.org>

Thursday April 22nd, 1999 7:07 AM

Reply to this message

"...and they shouldn't release a product over which they have no control over the code. For only outside people to work on it would most likely create a half baked piece of work...."

Dude, Adam Lock, the Active X wrapper!

#23 Start 'Em Up

by Deep <deepsixed@[spam]usa.net>

Thursday April 22nd, 1999 12:10 PM

Reply to this message

If this is such a good idea, then anyone could do it on their own.

It's not clear that it could be done WITHIN Mozilla.org, but it definitely could be done outside it, and added on to Mozilla 5.0 (if not Communicator 5.0).

Of course, there are technical and/or legal problems opening up ICQ and AIM.

Stop the whinning, and get to work!

#24 Re:The IM Project Page Has Vanished

by Daniel Hill <danielhill@mindless.com>

Thursday April 22nd, 1999 8:34 PM

Reply to this message

It;s just typical of the AOL attitude. Here in Australia, I signed up for the AOL beta test about a year ago now, and got dick, after they decided to lie to me and tell me to f**k off.

What do you expect from scum AOL? Arseholes Offline.

#25 Re:The IM Project Page Has Vanished

by arielb

Thursday April 22nd, 1999 8:59 PM

Reply to this message

someone is working on a similar project...for BeOS. It's found at <http://www.gimmick.org.> However while they plan to integrate icq and aol instant messaging, they don't plan to integrate the chatting and irc isn't mentioned

#26 Re:The IM Project Page Has Vanished

by Brasten Sager <brasten@earthling.net>

Thursday April 22nd, 1999 10:11 PM

Reply to this message

While Mozilla shouldn't divert any significant resources to the idea until the basic browser is done, I think that the integrated ICQ, IRC, IM, etc etc is a great idea, for one major reason. That being that it's something cool and catchy that might make someone want to download the thing. In a world were IE is available off the shelf and people are less inclined to download a browser, Mozilla needs to be sure they can still attract the largest following. We are, after all, in a browser war, where #'s of users counts, and we can no longer depend on the smart people who use Netscape, because there are increasingly more stupid people who use whatever they're given unless something cooler is out there.

On a side note, a bet the next minor release to IE will contain an integrated messager program. Then Mozilla will have to implement it to catch up. why put ourselves in THAT position? lead the pack. put it in first.

My opinion, at least.