Netscape pulls Mozilla chat-client page 59
smu writes "Netscape, the contributor of the Instant Messaging API document, has
requested that mozilla.org remove the page pending further review by Netscape. "We at mozilla.org regret this inconvenience, but respect the wishes of our contributors. Netscape solicits feedback on this decision".
"I don't think I need to make any smartass comment.
Jamie? BAH! Mozilla lives! (Score:1)
ALL i see on C|net and TechWeb and shit is crappola like "From the ashes of Mozilla rises
and words like "failure" and "defunct"...
I STILL have yet to find one criteria by which Mozilla has been a failure. My FAVorite line so far was "Although Mozilla was a commercial flop..."
How entertaining... Not even in beta and a FREE, OPEN SOURCE, NONCOMMERCIAL, technically exceptional product is a "commercial flop". What clueless shits.
This kind of emotional mentality (with an emphasis on the mental) unfortunately bleeds down to the IE5 kiddiez and others who are satisfied to fly in like harpies and rip on "Nutscrape 5 sux because it's slow and sh1t..." Or crap like "Their toolbars sux i'll never use it"...
The horrid little turds just don't get it and neither do so many others. Mozilla is such a dream-come-true project it's not even funny, and it's here, and it's in rampant development, and all anyone can think to do is bitch about the soap opera that it was birthed in. WHO CARES that AOL owns NS? Who CARES that NS didn't GPL their billion-dollar-baby? What is wrong with these fools who would rather take jabs at a corporate entity rather than learn how to use a stunningly powerful tool like Gecko?
Netscape 4.x sucks. Technically and user-wise, it sucks. The developers did a valiant job but they didn't have almost 3/4 of a billion dollars to spend on it, unlike Microsoft. The engine wore out and creaked and finally snapped, and they logically decided to redo the web browser from the GROUND UP.
This is all froody new stuff folks, new layout engine, new data manipulations, new APIs supported, new modularity, even new networking code in a year or two or less. This is the browser/component set that will be in INDUSTRIAL STRENGTH USE in all walks of computing for a decade or more, so let's get cracking on making it the best, most stable, and least kludgy it can be.
Let's have fun now, and make a last-ditch effort to bring sanity to the internet before we drown in controls, applets, tables, FONT, and javascript.
You clueless shits... (Score:3)
Ever heard of Internet Explorer 4?
Internet Explorere 5?
Quicktime 4?
They're all delivered using MODULAR pieces. Ring a bell? If you do not want a chat client in browser x.xx, do not request it for download.
If you have some notion that they are somehow embedding a chat client into the layout engine, go to Mozilla.org and read a bit.
If you have the notion that 150 engineers are dropping what they are doing to make IRCAIMAOLICQ on a salaried whim, get $0.35 and call Clue to chat for a while.
If you have a complaint about the UI or behavior in M3 or M4, go to the dictionary and look up PRE-ALPHA, or DEBUGGING, or EARLY BUILD, or else if that's too much work, meditate on concepts such as "reading what is and is not implemented yet in the readme" or "there have been no beta releases of mozilla as of yet".
If you are under the assumption that a Java machine can be pulled out of one's ass in a few days, think harder. The mechanics for interfacing Mozilla with the JVM of *YOUR CHOICE* are being implemented as we speak. NS5 will ship with someone's. Don't like it? Get a copy of Mozilla and plug in your own. Oh, and no-one is going to put up 10 megs of JVM per nightly debugging build just so one can save oneself the agony of not having scrolling newstickers.
If you are under the assumption that snarky comments about the de facto ownership of a development initiative actually contributes to the project, learn about how software gets written.
And finally, if you are under the assumption that a project as sophisticated and technically superior as Mozilla "sux" because it doesn't have a recursive name or themable XYZ, go ahead and write your own browser. Implement everything The 'Leet Way yourself, using Real Open Source by Hax0rs. Don't forget to write a new widget set!
Either Mozilla or Netscape 5 will end up being the modular multipuropose ultraextensible browser you'll be using for the next five years, so get used to getting world-class best-of-breed cross platform ultra efficient useful innovative open source software for free, or go back to the land of paperclips and wizards.
Fricking ingrates. Respect Mozilla.
Rum Tum Tugger (Score:1)
I understand that it's a case of "if they can do this, what next?" -- and I don't disagree with the sentiment -- but it's still amusing
--
Important to remember... (Score:1)
However, this is a neat feature that, when Netscape brings it back in, will make Mozilla that much better. A pluggable chat API, so you can write .so:s for AIM, ICQ, or even IRC - and optional, to boot. Yes, Mozilla will kick some serious ass.
So why hasn't an AOL-free Moz project been started (Score:1)
So you don't like the AOL influence, or you don't like that Netscape always had a little too much influence on the proceedure. Take the source, start up a freemozilla.org site, and bypass AOL entirely.
--
Brad Felmey
Could they make up their minds? (Score:1)
There's an important distinction here:
- Netscape contributed a document, and wanted it taken down. As with any other contributor (Adam Lock, port owners, etc.), we honour their right to withdraw their content, even if we'd rather have them keep it up.
- If Netscape had asked us to take down someone else's content for reasons other than violations of the law (posting crypto source, unreleased source code, whatever), I've have laughed at them. And if ``The Mozilla Organisation'' had decided to take it down anyway, I'd have been out of here faster than you could say ``jay double-you zee''.
So Netscape, a Mozilla contributor, put some stuff up and then took it down. Not what I would have done, and I think it makes them look embarrassingly dumb, but that's their call. We'd have been doing the wrong thing to not take their content down when they asked us to.As far as we at mozilla.org are concerned, anyone who wants to start a chat API project is welcome to. We've been advocating it through blue-sky and intertwingle editorialization for months. If you'd like to contribute your own chat API -- I think the Netscape guys were on the right track with abstracting the various protocols under a common interface -- I'd love to help you get started. You shouldn't derive your work from the stillborn API docs that Netscape posted, to avoid complaints of taint, but that shouldn't set you back too far.
Could they make up their minds? (Score:1)
..three days later..
"Netscape told us to jump this high, so we gotta."
It would sure be nice if mozilla could take a stand as either still being run by netscape or being their own deal. Every time they go one way, they contradict themselves and go the other not long after. Sheesh.
Good idea... (Score:1)
Although M4 does render pages nicely. Too bad the UI is still broken, and its rendering fonts so small as to be unreadable most of the time.
Two Words (Score:1)
(I know mozilla.org is separate now though)
excellent idea (Score:1)
And it's a damn sight better than either AIM or ICQ. Bleah.
what's going on? (Score:1)
non-Netscape mozillas (Score:1)
AOL and linux (Score:1)
plug thug (Score:1)
So basically what this seems to me is a whole lot of hot air, snake oil and inevitable, just another vaporware product
Although I hope I'm wrong
What's the problem for AOL? (Score:1)
Admittedly I feel that IM should belong in a seperate generic client, so that I don't need some large monolithic generic client when I'm not actually viewing HTML, but I doubt that this would be Netscape's reasoning for pulling the document.
oops (Score:1)
Don't forget to take your medication. (Score:1)
It's great that Mozilla is finally becoming modular. But it should be somewhat restrictive about what kinds of modules it supports. A unified interface makes sense for similar tasks. Chatting is in no way similar to web browsing though, so I can't see a good reason for Mozilla to have any support for chatting whatsoever.
This chat module thing: is it going to require *any* code changes to Mozilla itself, or are they just going to use interfaces Mozilla already had? If it's the latter, then I don't see an real harm, but then it may as well be a separate project. If it's the former however, they're just going to delay the release of Mozilla, and overcomplicate it for a feature that shouldn't be there in the first place.
Mozilla should be made as simple as possible. Essentially just a container with a few programming interfaces for hooking up things like protocols and rendering engines. An interface for other applications to be able to communicate with Mozilla would be good too. Much more than that is pushing it.
Don't forget to take your medication. (Score:1)
Like I said before, if this chat thing requires *no changes* to the Mozilla base code at all, then it's fine with me. But as soon as Mozilla needs even a special set of hooks for "chat plugins" then they've gone too far. Leave it out.
I think it would be nice if I could click on a link to "netrek://mit.netrek.org" and have it bring up Netrek. I don't think they should add Netrek, or even "networked space game" support to Mozilla though.
Mozilla should have support for adding new protocol identifiers in an easy way, and having several ways of handling them: seperate application, special type of plug-in, etc. Much like the existing mime-type stuff Netscape has had all along. This should be totally generic though. Explicit support for particular things like chatting or text editting or whatever just leads to bloat and bad design. A good metric would be this: if chatting is mentioned anywhere in the Mozilla source, then they're doing it wrong.
Um, no. The IM API came from within. (Score:2)
The proposal did seem to be pretty narrow and a little wrongheaded in its approach, though, and for that deserved to be withdrawn. I suspect this will be coming back after some discussion on the relevant newsgroups. For one thing, there's no reason each IM client has to come bundled with its own UI shell. I might be mistaken, but my quick read of the spec called for each client to bring its own.
AIM and ICQ (and things that present a siumilar UI, like private messages on IRC) could employ a shared UI, and clients that need a modified or different UI could instead subclass it and make use of the relevant bits (like the buddy list or the multiperson chat windows).
Again, if this remains merely a removable module, and is created by people who aren't already working on core browser/editor/mail/news, it seems pleasant enough.
Actually, I think it's a shame (Score:1)
The reason I hated Netscape including AIM wasn't because of the bloat (apart from the truly stupid fact that everything else was an option in the installer, but AIM was compulsory), but because of the fact that it only spoke a single proprietary protocol. Having a generic client which speaks all protocols is IMO a great thing.
As for whether it belongs in Mozilla, I think it does, to the same extent that Mail and News belong. So long as they are optional, it makes sense to share the *huge* amount of common code (UI, HTML rendering, networking protocols...). Although most people consider the mail and news module code bloat (personally I like it and use it everyday), it's a telling point that the "navigator standalone" edition of netscape is at least 2/3 the size of the full product - in other words, the vast majority of the code is shared (unless you really believe that the browser-specific code is FAR more complex, and bigger, than all the rest put together).
As a final point, in response to the comments that "Mozilla should be concentrating on putting out a usable product" - exactly how many people do you think worked on this? The same applies to the Necko networking project, which has 5 people. A while ago everyone was following JWZ's lead in saying that the "30 or so" external contributors were "insignificant"... now it's a life-or-death matter if 5 or 10 internal developers work on something other than getting the first release ready?
Stuart.
Hear hear! (Score:1)
Me too!
;)
yah... (Score:1)
Adding any sort of chat client into mozilla undermine any effort to release a streamlined, fast browser, and of course, needlessly increase package size.
The only one's I'd truly see benefiting from this would be the *nix users -- but even then, there are still plenty of AIMish implementations out there.
...and when's the last time you've seen a *nix geek complain that he wasn't getting a fully-packaged, pretty, bloated suite of utilities with his proprietary software?
What if (Score:1)
do you think netscape will have the right to tell him to pull it out ?
Bah... (Score:1)
I'd rather see them put some sort of Java (yeah, I hate Java, but there's so many sites that use it that it's almost a necessity) support in it instead... at least that would be "necessary" bloat.
Re:A cool use.. (Score:1)
I thought we were going to see real applications that were platform-independent, thanks to the magic of Java?!
Re:Bah... (Score:1)
About the only thing that would make Java fast enough, given its compiled-then-interpreted nature, would be a chip whose native instruction set is Java bytecodes.
As for the language being bad, here's my personal list:
1. No assertions
2. No preprocessor, making global constant declaration needlessly difficult
3. Errors that IMHO should be warnings
4. "ObjectInputStream constructor under certain conditions blocks program execution" is not a bug -- must be done in a particular order for server-client programs
OK, so 3 is a _feature_ (strong typing).
If you have a Java Developer Connection account, just look at the Bug Parade. There are far too many things to work around in Java.
The one thing Java is useful for is making a decent GUI, though they're going to change that with Swing. Eventually AWT programs will break.
This is sad. (Score:1)
Now I guess we start to see the dark side of AOL. They dont like some competing component to be added to the product, and they "politely" request that it be taken out (politely == remove it, or lose your job.).
I think it's really sad, but it will most likely serve to prove a point in the future... Make it clear in other projects that components submitted can not be unsubmitted. What if Linus decided to pull his code out of the kernel ? What if FSF decided to pull it's code out of GCC ?
Sun Tzu must have been running Linux...
- Hold out baits to entice the enemy. Feign disorder, and crush him. (Sun Tzu, The art of war)
Bahva... (Score:1)
As for bloat, Sun do appear to be doing their best. The latest release of the JDK is something in the region of 24457274 bytes. That's not small, IMHO. Especially when put up against earlier releases of the JDK.
The current trend seems to be to load in as many new APIs as possible (Java3D, Java2D, Java telephony API, Java speech recognition API, Java chicken-breeding API) while leaving nasty nasty bugs in the core code (such as the fun and exciting one which prevents all apps/applications using a GUI from shutting down properly - number 4030718 in the bug parade, reported over two years ago, and still nothing more useful than 'Well, you can litter your code with calls to system.exit(), because we're too busy to fix this one'...)
:erant.
jabber plug (Score:2)
it's a pretty neat project, they've got a lot of ideas and not so much code (a sort-of functioning server, a windows client, a tcl client, and a gtk/gnome client are all in beta right now). especially interesting are the transport mechanisms to other protocols -- which will allow a user to use multiple services at the same time? check it out! [jabber.org]
hmm (Score:1)
Or are just mozilla removing the page by pure politeness to netscape(AOL)
If it get brought back in, with ICQ + AIM + IRC it will be a very good thing, but then again, why should they pull it in the first palce if they knew what they were doing???
ah... (Score:1)
If we can get a cool implementation of ICQ and AIM and maybe even IRC under a fairly good lisense wouldn't that be a good thing ?
no they should not, you shuld! (Score:1)
Its the same thing, the instant messaging people do what they want, not what might seem most impostant, the same thing goes with gnome, they dont work with the linux kernel because they think their project is important.
Its good with lost and lost and even more different projects. Everybody is working hard on their specific tasks; what is important to them.
Im perfectly happy with their efforts, Mozilla will be released then its ready. If you cant wait, help them!
oh no, I did it again :-/ (Score:1)
lots of projects is what a wanted to write
Wow! (Score:1)
But this project is a lot cooler and what at least what I would like to have in mozilla or as a stand alone client, I look forward to when I don't have to use a feature-less-ICQ-clone and another AIM-clone and instead can use this all-in-one, free, implementation of them all. If the mozilla project wants chat and instant messaging, this is what they should support.
here's the api spec (Score:1)
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
[Insert cool diagram here.]
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 ************************
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):
*/
enum nsIMAvailability {
Present,
Gone,
Away,
Unknown,
};
class nsIIMServer : public nsISupports {
public:
NS_DEFINE_STATIC_IID_ACCESSOR(NS_IIMSERVEROBJECT_
PRStatus getServerListener(nsIIMServerListener*);
nsIIMServerListener* getServerListener();
const char* getShortDescription();
PRStatus configure();
PRStatus connect();
PRStatus disconnect();
PRBool isConnected()
NS_IMETHOD GetService(REFNSIID iid, void** instancePtr);
};
class nsIIMServerListener : public nsISupports {
public:
NS_DEFINE_STATIC_IID_ACCESSOR(NS_IIMSERVERLISTENE
PRStatus lostConnection(const char* why);
};
class nsIIMIMService : public nsISupports {
public:
NS_DEFINE_STATIC_IID_ACCESSOR(NS_IIMIMSERVICE_IID
PRStatus setIMListener(nsIIMIMListener*);
nsIIMIMListener* getIMListener();
PRStatus sendMessage(nsIIMIndividual* dest, const char* html);
};
class nsIIMIMListener : public nsISupports {
public:
NS_DEFINE_STATIC_IID_ACCESSOR(NS_IIMIMLISTENER_II
PRStatus receiveMessage(nsIIMIndividual* source, const char* html);
};
class nsIIMChatService : public nsISupports {
public:
NS_DEFINE_STATIC_IID_ACCESSOR(NS_IIMCHATSERVICE_I
PRStatus setChatListener(nsIIMChatListener*);
nsIIMChatListener* getChatListener();
ListOfStrings* listKnownRooms();
nsIIMChatRoom* getRoom(const char* name);
};
class nsIIMChatListener : public nsISupports {
NS_DEFINE_STATIC_IID_ACCESSOR(NS_IIMCHATLISTENER_
PRStatus roomChanged(const char* name,
PRBool added
);
PRStatus receiveInvitation(nsIIMIndividual* who,
const char* roomname,
const char* extratext
);
};
class nsIIMPresenceService : public nsISupports {
public:
NS_DEFINE_STATIC_IID_ACCESSOR(NS_IIMPRESENCESERVI
PRStatus setPresenceListener(nsIIMPresenceListener*);
nsIIMPresenceListener* getPresenceListener();
PRStatus addUser(nsIIMIndividual*);
PRStatus removeUser(nsIIMIndividual*);
PRStatus removeAll();
nsIIMIndividualList* getWatchList();
};
class nsIIMPresenceListener : public nsISupports {
public:
NS_DEFINE_STATIC_IID_ACCESSOR(NS_IIMPRESENCELISTE
PRStatus userAvailabilityChange(nsIIMIndividual* who);
};
class nsIIMIndividual : public nsISupports {
public:
NS_DEFINE_STATIC_IID_ACCESSOR(NS_IIMINDIVIDUAL_II
nsIMAvailability getAvailability(PRBool block);
const char* getIDString();
};
class nsIIMChatRoom : public nsISupports {
public:
NS_DEFINE_STATIC_IID_ACCESSOR(NS_IIMCHATROOM_IID)
PRStatus setChatRoomListener(nsIIMChatRoomListener*);
nsIIMChatRoomListener* getChatRoomListener();
const char* getDisplayName();
const char* getDescription();
PRStatus sendMessage(char* html);
PRStatus sendInvitation(nsIIMIndividual* who, const char* extratext);
nsIIMIndividualList* listMembers();
};
class nsIIMChatRoomListener : public nsISupports {
public:
NS_DEFINE_STATIC_IID_ACCESSOR(NS_IIMCHATROOMLISTE
PRStatus receiveMessage(nsIIMIndividualList* who, const char* html);
PRStatus memberChange(nsIIMIndividual* who,
PRBool added
);
};
************************ IM_APIExt.h ************************
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):
*/
class nsIIMIMEmoteService : public nsISupports {
NS_DEFINE_STATIC_IID_ACCESSOR(NS_IIMIMEMOTESERVIC
PRStatus sendEmote(nsIIMIndividual* dest, const char* html);
};
class nsIIMIMEmoteListener : public nsISupports {
NS_DEFINE_STATIC_IID_ACCESSOR(NS_IIMIMEMOTELISTEN
PRStatus receiveEmote(nsIIMIMListener* source, const char* html);
};
class nsIIMChatRoomEmote : public nsISupports {
NS_DEFINE_STATIC_IID_ACCESSOR(NS_IIMCHATROOMEMOTE
PRStatus sendEmote(const char* html);
};
class nsIIMChatRoomEmoteListener : public nsISupports {
NS_DEFINE_STATIC_IID_ACCESSOR(NS_IIMCHATROOMEMOTE
PRStatus receiveEmote(nsIIMIMListener* who, const char* html);
};
Threading
There are no guarantees of what thread any call may be made in. If a particular protocol needs to have everything running in a single
the threading stuff got cut off (Score:1)
There are no guarantees of what thread any call may be made in. If a particular protocol needs to have everything running in a single
thread, then it must provide the necessary messaging and synchronization stuff under the IM-API.
In general, all of the calls are blocking. For example, it is expected that a call to connect() might take a long time. It is up to the user
of IM-API to call create an extra thread if it can not afford to block on a call.
Don't forget to take your medication. (Score:1)
Anyway, I think it would kind of cool to be able to browse chat groups, maybe have them all linked like an array of starbursts.... Quickly jumping from one to the next till you find one you think is perfect, with people adding links between related ones or at random... Kinda a nifty idea really...
shouldn't they... (Score:1)
so now we get at the heart of my problem with the whole "opensource" mozilla project. there are people who's jobs it is to work on this. that should make for a great product because of the full-time workers, but I would feel a little wierd trying to push my way in from the outside to help steer the project. Some people have though in defense of the project as open source.
I also think this retraction reinforces my feelings (substantiated or not to the rest of the world) that mozilla is a product of netscape. Period.
Point me to all the propaganda you want, but I feel that this is a major reason why this project isn't as far along as it could be -- because there isn't the army of zealots that linux or apache has. There are mostly only the engineers up in Mountain View.
flames to my work address, president@whitehouse.gov
"With patience and plenty of saliva,
the elephant deflowered the mosquito."
Could they make up their minds? (Score:1)
when the vast majority of your developers are on Netscape/AOL's payroll, and you do something to threaten two important and strategic AOL franchises (instant messenger & ICQ) you probably get an irate call from the dudes upstairs. protestations that one is "separate" from the corporate entity that pays your bills come out sounding pretty hollow...
of course, AOL could allow mozilla to do what it wants to do, but is anybody willing to bet on it? and at what odds?
mozilla may still produce good software, just like msoft produced the pretty good ie5, but i wouldn't say they're independent of AOL or really a part of the open source movement...
What's the problem for AOL? (Score:1)
I also agree that this sort of thing should be a seperate program. Adding it to Mozilla seems silly.
Bah... (Score:1)
Bahva... (Score:1)
Important to remember... (Score:1)
Would you just nod your head and say.."It's legal..it's ok", or would you be up in arms about Microsoft's attempts to throttle competition and open-source? Netscape is just as guilty of that now.
Bah... (Score:1)
Important to remember... (Score:1)
It's clear that some parties probably have an interest in AIM/ICQ being "standards" for chat mechanisms. I think the best thing anyone could do is write a Zephyr plug-in for Mozilla.
bookmarking IRC channels and killfile-ing users (Score:2)
>
> The reason I hated Netscape including AIM wasn't
> because of the bloat [was] because of the fact
> that it only spoke a single proprietary
> protocol. Having a generic client which speaks
> all protocols is IMO a great thing.
Agreed. I'm a user of IRC (check out the mozilla
channel), and it suffers from being split into
a number of networks, each of which has its own
set of servers, of varying reliability.
If making Mozilla the standard interface to
interchangable IRC modules would allow some
unity, this would significantly increase the
usability of the whole thing.
In particular, it would be of benefit to be
able to bookmark or email URLs for IRC such as:
irc://-dalnet/
irc://-effnet/#help
irc://-alternet/#gnudiscuss?nick=Aristotle
irc://irc.dal.net:7000/#foobar
IE the network "-dalnet" could be looked up to
find your preferred server. default nicks could
be stored in the browser (possibly in a way that
allow the nick to change with the irc network
and channel name - especially useful given that
the maximum nick length varies with network).