[besson3c]

We all work differently, have different habits, rely on certain apps more than others, etc.

I understand that Apple's design goals in developing apps like Safari, Mail, iCal, etc. are to make things as easy and intuitive as possible, particularly for novice users - this is great. However, many of Apple's apps (including OS X itself) are also quite inflexible, forcing more advanced users (and possibly even some novice users) to play along how Apple envisioned, as if Apple knows how you best work.

Thinking in terms of HCI, there is nothing wrong with advanced features so long as they reveal themselves only when the user is looking for them (i.e. don't clutter the meat and potatoes of the interface and make it look busy with all of these bells and whistles). One great way to do this is to develop a plug-in archecture to allow third-parties to write add-ons for the software. This way, the user can decide exactly what bells and whistles they desire.

I've already left Safari, I'm on the verge of leaving Mail because I don't want to install little hacks that could break from Apple update to Apple update and are awkward to install and maintain. If Apple would document plug-in API, they could control how these plug-ins interact with their software, and they can work with third-party developers to make sure that stuff doesn't break or have to work in such a hack-like, possibly even insecure fashion.

Really, I want to have my cake and eat it too, and I don't see any reason why I can't.

Why doesn't Apple make their software more extensible, and in doing so force some users to look for solutions elsewhere?

[Sage]

Someone been reading some John Gruber?

[besson3c]

Originally Posted by Sage

Someone been reading some John Gruber?

I hadn't until you turned me on to this guy

Interesting that he is saying similar things, although I wasn't thinking along the lines of opening up source to all the apps - just in making an open plug-in archetecture.

[analogika]

Several things:

Apple has said in regard to the iPod that they're very, very reluctant to add ANY features, because they can never take them out. If it turns out a feature is confusing or not implementable in a logical fashion (see "cut" and paste of files), it's too late once it's in. You can't remove it without half the community screaming bloody murder.

"Advanced" features aren't added if they break paradigms or concepts, or if they cannot be added without getting in the way of non-advanced users. Best example of this is the multi-button mouse. Apple waited TWENTY YEARS to build a multi-button mouse, because it took them THAT LONG to build the technology (with the sensors and all) that allowed them to ship it as a single-button mouse by default. Four-button support is there if you explicitly look for it, but you'd never guess just looking at the thing: No confusion, since the only ones who can access the feature are those who explicitly look for it.

Same approach to tabbed browsing in Safari.

I'm curious: what features specifically are you missing in Safari and Mail that make you jump ship?

[besson3c]

Originally Posted by analogika

Several things:

Apple has said in regard to the iPod that they're very, very reluctant to add ANY features, because they can never take them out. If it turns out a feature is confusing or not implementable in a logical fashion (see "cut" and paste of files), it's too late once it's in. You can't remove it without half the community screaming bloody murder.

That's why a plug-in archetecture would allow third-parties to "take it from here" without Apple having to worry about this sort of thing.

I'm curious: what features specifically are you missing in Safari and Mail that make you jump ship?

Mail: a ton of features...

- Profile/identity support so that I can switch between reply-to settings within an individual account
- The ability to indicate subscriptions for specific mail folders
- The ability to indicate caching for specific mail folders
- I prefer Enigmail over the third-party Mac PGP mail thing (which seems like an awkward hack)
- An RSS reader
- Richer rule creation interface

Thunderbird has all of this, although I can't seem to find a way to increase/decrease quote level in Thunderbird, and the key bindings are not what I expect. I haven't yet looked to see what sorts of quote options are available in extensions.

Safari

- drag and dropable tabs
- an ad blocker/session support mechanism that doens't constantly break after each Apple update
- The Firefox Tab Mix Plus extension has a *ton* of features that make tabs more useful, such as visual indication as to which tabs have or haven't been read, whether to open page requests from third-party apps in a new tab or new window, etc.

I'm also using Firefox because it doesn't get slower the more I use it, and because of greater compatability. I do wish that Firefox would work with the OS X dictionary though. I haven't yet looked for an extension which provides this support though. It would also be nice if Firefox's application "open with" support leveraged the choices available in the Finder.

[dru]

Make a list of the menu items whose keybindings you want to change. I think you can change the key bindings for Thunderbird in "System Preferences" -> "keyboard & Mouse" -> "Keyboard Shortcuts"... click the "+" and select "Thunderbird" from the menu. Type in the menu item's title in the appropriate field, then enter your preferred keybinding.

[besson3c]

Originally Posted by dru

Make a list of the menu items whose keybindings you want to change. I think you can change the key bindings for Thunderbird in "System Preferences" -> "keyboard & Mouse" -> "Keyboard Shortcuts"... click the "+" and select "Thunderbird" from the menu. Type in the menu item's title in the appropriate field, then enter your preferred keybinding.

Good suggestion, I might give that a try!

[Person Man]

Originally Posted by besson3c

- an ad blocker/session support mechanism that doens't constantly break after each Apple update

PithHelmet disables itself by design when a newer version comes out. The last several versions have only needed to update the version number checking routine.

Complain to the guy who makes PithHelmet, not Apple.

[besson3c]

Originally Posted by Person Man

PithHelmet disables itself by design when a newer version comes out. The last several versions have only needed to update the version number checking routine.

Complain to the guy who makes PithHelmet, not Apple.

No, Apple deserves my complaining here.

When Firefox moved from 1.0 to 1.5, the plug-in API was documented, and there was a very clear path for developers to migrate their software to the new API at their leisure. All 1.0.x or 1.5.x releases do not break Firefox or Thunderbird extensions, developers can count on having their extensions work until the next major release of Firefox/Thunderbird, and plan around these releases.


Mail and Safari add-ons are essentially hacks. There is no set API for adding these extensions, there are no guidelines, no forewarning as to when things might start to break, no migration path. Only Apple can make things so that these developers don't have to develop hacks.

[cc_foo]

I suppose that's why there's a diverse group of 3rd party email applications each containing a set of these wonderful features that Apple forgot.

Unless Apple adopts Extensions and Themes architecture -- which I think is unlikely.

And there's Applescript.

[besson3c]

Originally Posted by cc_foo

I suppose that's why there's a diverse group of 3rd party email applications each containing a set of these wonderful features that Apple forgot.

Unless Apple adopts Extensions and Themes architecture -- which I think is unlikely.

And there's Applescript.

Why doesn't Apple just open up these sorts of apps to allow these sorts of options for those that want it? Apple wouldn't even have to do the legwork of implementing these features, just provide the hooks. It is hard to compete with Apple in several areas, yet Apple doing this sort of thing makes their apps less useful to a certain population. Granted, this is not their target population, but appeasing this population seems like such low dangling fruit.

Applescript is one way of allow stuff to be hacked on to apps, but it is just a scripting language. You could not attach PGP support onto Mail with Applescript, for instance, in any usable way.

[cc_foo]

Originally Posted by besson3c

Why doesn't Apple just open up these sorts of apps to allow these sorts of options for those that want it? Apple wouldn't even have to do the legwork of imple...

Because Apple engineers haven't written the code necessary to support a robust plug-in architecture?

*Maybe* the powers-that-be at Apple feel that creating and maintaining such a plug-in architecture for Safari, Mail (and I suppose iTunes, iPhoto, iWeb) etc is unlikely to contribute to Apple's ultimate aim: profit maximization.

It's not difficult to see your point of view. There are very extensible software out there that meet your needs.

[Thinine]

Because they don't want to support users running crappy-but-made-with-a-supported-API plugins.

[analogika]

Originally Posted by Thinine

Because they don't want to support users running crappy-but-made-with-a-supported-API plugins.

That's probably the winner, right there.

How many threads do we have here after every system update where users complain that their entire e-mail archive is dead, or rules don't work, or Safari is crashing on launch, or whatever, and it turns out that they're using some plug-in?

Happens fairly frequently.

And I'll guess that most people savvy enough to search out plug-ins and install them are smart enough to figure that that might be the problem and never even post here.

That, however, changes drastically when you include an official, open plug-in architecture.

[besson3c]

Originally Posted by analogika

That's probably the winner, right there.

How many threads do we have here after every system update where users complain that their entire e-mail archive is dead, or rules don't work, or Safari is crashing on launch, or whatever, and it turns out that they're using some plug-in?

Happens fairly frequently.

And I'll guess that most people savvy enough to search out plug-ins and install them are smart enough to figure that that might be the problem and never even post here.

That, however, changes drastically when you include an official, open plug-in architecture.

Doesn't make complete sense.... I could still hose my copy of Safari, Mail, whatever with some third-party hack. I'd say my chances of doing so are actually less with something more supported, and all Apple would have to do is provide a "show extensions" window with uninstall or disable buttons (like Firefox/Thunderbird) when it is necessary to check to see what has been installed, or to temporarily disable these extensions.

[besson3c]

Originally Posted by Thinine

Because they don't want to support users running crappy-but-made-with-a-supported-API plugins.

Who says they do? They could just have the user temporarily disable these plugs, just like we used to do with OS 9 extensions, and still do today with kernel extensions and other third-party hacks (such as the Haxies).

An interface to temporarily disable these plugs would actually provide an even more supportable model, IMHO.

[Moose]

Originally Posted by besson3c

They could just have the user temporarily disable these plugs, just like we used to do with OS 9 extensions, and still do today with kernel extensions and other third-party hacks (such as the Haxies).

Yeah, because when I think back to what I miss most about Mac OS 9, it's Extension Manager.

Apple only recently--with Tiger--said that the core APIs were not going to change substantively in subsequent versions for awhile.

Wait until applications like Safari and Mail reach the same level of maturity and then start clamoring for a documented plugin architecture.

[besson3c]

Originally Posted by Moose

Yeah, because when I think back to what I miss most about Mac OS 9, it's Extension Manager.

Apple only recently--with Tiger--said that the core APIs were not going to change substantively in subsequent versions for awhile.

Wait until applications like Safari and Mail reach the same level of maturity and then start clamoring for a documented plugin architecture.

Hey, who says a plugable archetecture has to be like OS 9 and the extension manager? I can name a ton of really solid stuff that is based on a plug-in archetecture. You don't have to look much further than Unix itself to see an example of this, and for the most part OS X seems to be pretty modular in its approach.

I'd say that Safari is already pretty modular - it's rendering engine is portable, that's the meat and potatoes of the app. Mail, it's been around for years! If it's not mature now, when will it ever reach maturity?

[besson3c]

Why is it that everytime somebody says something constructive about OS X, people are quick to defend it.

OS X is great, but I also call it like it is. If something could stand improvement, it should be improved.

That's just my approach, FWIW.

[Moose]

Originally Posted by besson3c

Why is it that everytime somebody says something constructive about OS X, people are quick to defend it.

"Why does Apple design its software in such a limiting fashion?" is not constructive criticism.

Originally Posted by besson3c

Mail, it's been around for years! If it's not mature now, when will it ever reach maturity?

Software "maturity" is not judged on age alone. Mail has undergone major changes with each major OS version (including even more drastic changes to come in Leopard).

When you publish (and support) a plugin API for a piece of software, you have two choices if you want to effect drastic change in that software:

1) Break it (creating work for your external developers)
2) Stay chained to decisions you made years ago (creating work for your internal developers)

Originally Posted by besson3c

I'd say that Safari is already pretty modular - it's rendering engine is portable, that's the meat and potatoes of the app.

Great. Then it shouldn't be too hard for you to write your own browser that does what you want using WebKit, right?

Apple apparently doesn't want to spend a lot of time and money supporting plugin APIs for Mail and Safari, otherwise they'd exist and maybe even be well-documented.

[besson3c]

Originally Posted by Moose

"Why does Apple design its software in such a limiting fashion?" is not constructive criticism.

Why not?

When you publish (and support) a plugin API for a piece of software, you have two choices if you want to effect drastic change in that software:

1) Break it (creating work for your external developers)

This is not a bad choice. Plug-in developers develop knowing that they are tied to what Apple does or doesn't do with their software, this sort of thing comes with the territory in these sort of situations.

There are tons of users who count on products with pluggable extensions too, this is certainly not unprecedented.

Apple apparently doesn't want to spend a lot of time and money supporting plugin APIs for Mail and Safari, otherwise they'd exist and maybe even be well-documented.

I understand the return on Apple's investment argument, but I can't see why this sort of thing would not indirectly result in Apple benefitting.

[Moose]

Originally Posted by besson3c

Why not?

You phrased it not as, "It would be handy for third-party developers who want to extend core applications such as Mail and Safari if there was a documented API for this," but instead as a whiny question. Mail and Safari aren't designed to limit you. They're just not designed to be extended easily. There's a difference between the two statements.

Originally Posted by besson3c

I understand the return on Apple's investment argument, but I can't see why this sort of thing would not indirectly result in Apple benefitting.

What benefit does Apple get from making it easier for potentially buggy code to be injected into its applications?

Does your NetMusician software have a well-documented plugin architecture that allows your clients to extend it to suit their purposes?

[besson3c]

Originally Posted by Moose

You phrased it not as, "It would be handy for third-party developers who want to extend core applications such as Mail and Safari if there was a documented API for this," but instead as a whiny question. Mail and Safari aren't designed to limit you. They're just not designed to be extended easily. There's a difference between the two statements.

Okay, point taken. Perhaps a little nit-picky, but probably best to leave this one...

What benefit does Apple get from making it easier for potentially buggy code to be injected into its applications?

People are injecting (possibly buggy) code into their applications whether Apple wants it or not. I've seen add-on hacks for Mail, Safari, iPhoto, and iChat (if you include Growl stuff). All of the theming stuff could also be included here, and this is happening regardless of Apple's wishes.

Does your NetMusician software have a well-documented plugin architecture that allows your clients to extend it to suit their purposes?

Yeah, it does. For starters, I'm on the verge of releasing it as open source (I'd do so sooner if I felt it would be useful in its current form). I've also written it to be modular in its design.

In Unix software development, I'd say that modular designs are the standard, not the exception, and Apple's software designs usually abide by these conventions, for the most part...

[Moose]

Originally Posted by besson3c

People are injecting (possibly buggy) code into their applications whether Apple wants it or not. I've seen add-on hacks for Mail, Safari, iPhoto, and iChat (if you include Growl stuff). All of the theming stuff could also be included here, and this is happening regardless of Apple's wishes.

Yes. It's happening. That doesn't mean Apple has to give it the Apple Seal of Documentation/Support Approval, nor does it even mean that they should.

Originally Posted by besson3c

Yeah, it does. For starters, I'm on the verge of releasing it as open source (I'd do so sooner if I felt it would be useful in its current form). I've also written it to be modular in its design.

In Unix software development, I'd say that modular designs are the standard, not the exception, and Apple's software designs usually abide by these conventions, for the most part...

Once again, you're missing the point. Here, I'll repeat it, but with capital letters and bold.

MODULARITY AND EXTENSIBILITY VIA A WELL-DEFINED API ARE NOT AT ALL THE SAME THING.

Safari, explained simply, is a WebView and a UI that tells that WebView how to behave. I'm not as familiar with Mail's architecture, but it's modular (we already know it uses the AddressBook API and will hook into iCal's APIs soon as well).

So, I ask once again: does your software have a well-documented and well-defined mechanism by which I can add ONE FILE and substantively alter how it works and renders?

[besson3c]

Originally Posted by Moose

Yes. It's happening. That doesn't mean Apple has to give it the Apple Seal of Documentation/Support Approval, nor does it even mean that they should.
Once again, you're missing the point. Here, I'll repeat it, but with capital letters and bold.

MODULARITY AND EXTENSIBILITY VIA A WELL-DEFINED API ARE NOT AT ALL THE SAME THING.

Safari, explained simply, is a WebView and a UI that tells that WebView how to behave. I'm not as familiar with Mail's architecture, but it's modular (we already know it uses the AddressBook API and will hook into iCal's APIs soon as well).

So, I ask once again: does your software have a well-documented and well-defined mechanism by which I can add ONE FILE and substantively alter how it works and renders?

I'm not sure exactly what you are trying to argue here, or whether you are just critiquing my points for accuracy, but I'm intrigued nonetheless...

My software is web-based, so comparing it to an OS application is a little Apples vs. Oranges. Like all modern web-based stuff, you can change the look of the NetMusician Webkit by changing the single CSS file, you can replace images, you can replace the default database values, and you can add your own components by dropping in your folder and defining it by adding a single database entry. The GUI allows you to remove modules, and the website templates are freely customizable as well.

All of this is not yet well-documented, but it has been well thought out.

Again, I'm not entirely sure why you feel that my CMS can be accurately compared to something like Safari or Mail?


My point about modularity was essentially that this sort of software design makes creating a pluggable archetecture that much easier, AFAIK.

[Moose]

Originally Posted by besson3c

My point about modularity was essentially that this sort of software design makes creating a pluggable archetecture that much easier, AFAIK.

Great.

But you haven't given a compelling reason why Apple should expend the effort necessary to create and maintain public APIs for this.

Those who want the functionality can either use another program (Thunderbird, Firefox, Lightningcow, Lavadog, etc.) or use third-party hacks to get it. It's really not worth Apple's time to document and support the APIs necessary for it. It's not that Apple has purposely limited Safari and Mail so much as it is that Apple hasn't bothered to write a plugin architecture because it's really not that important.

Which of the following do you think is a higher priority for Apple's finite software engineering resources?

"Wow, the Finder really kinda sucks!"
"Man, PithHelmet relies on undocumented functionality to extend Safari!"

I know which one I consider to be more important.

[besson3c]

Originally Posted by Moose

Great.

But you haven't given a compelling reason why Apple should expend the effort necessary to create and maintain public APIs for this.

Those who want the functionality can either use another program (Thunderbird, Firefox, Lightningcow, Lavadog, etc.) or use third-party hacks to get it. It's really not worth Apple's time to document and support the APIs necessary for it. It's not that Apple has purposely limited Safari and Mail so much as it is that Apple hasn't bothered to write a plugin architecture because it's really not that important.

Which of the following do you think is a higher priority for Apple's finite software engineering resources?

"Wow, the Finder really kinda sucks!"
"Man, PithHelmet relies on undocumented functionality to extend Safari!"

I know which one I consider to be more important.

Are you looking for a businessey answer (i.e. profit potential) as to why Apple should expend the effort, or more of a technical answer explaining what they, and end-users might gain?

[Moose]

Originally Posted by besson3c

Are you looking for a businessey answer (i.e. profit potential) as to why Apple should expend the effort, or more of a technical answer explaining what they, and end-users might gain?

I'd like you to explain why Apple should expend its engineering effort (which has a cost, both up front and ongoing) to establish, document, and maintain a plugin API that brings them no financial benefit whatsoever (or do you honestly think Apple would sell more Macs if PithHelmet used a documented API?) and whose potential technical benefits (to Apple itself) are dubious at best.

[besson3c]

Originally Posted by Moose

I'd like you to explain why Apple should expend its engineering effort (which has a cost, both up front and ongoing) to establish, document, and maintain a plugin API that brings them no financial benefit whatsoever (or do you honestly think Apple would sell more Macs if PithHelmet used a documented API?) and whose potential technical benefits (to Apple itself) are dubious at best.

Financial gain:

- more viability and value of Apple's bundled products in business and places where workflow is a little more complex, without having to buy additional software at a flat rate or per seat.

- more developers interested in developing stuff for Apple which in turn leads to more consumer choice and attractive options for consumers, which leads to increased hardware sales

- more OS sales


Technical gain (what Apple gains):

- Apple: outsourcing of additional features to third-parties

- more developers (potentially)

- greater application user base, greater leverage from this increased user base

- a potentially better (more flexible) product which can be marketed

- an opportunity to market these plug-ins just as Apple has done with Dashboard widgets

[TETENAL]

Technical loss:
- inviting crappy third party code decreases stability

Financial loss:
- decreased stability leads to increased support costs and loss of sales

[besson3c]

Originally Posted by TETENAL

Technical loss:
- inviting crappy third party code decreases stability

We've been through this. People are writing hacks regardless. Providing a better means to do so can only help, IMHO. Besides, these plug-ins need not be crappy.

Financial loss:
- decreased stability leads to increased support costs and loss of sales

I installed this hacky thing to Safari months ago, and I tried to remove it, but now everytime I startup Safari I get this warning saying that my plug-in has been disabled. If my plug-in were still valid and some grandkid installed some hack for grandma, good luck getting grandma to remove these sort of hacks as they exist now. I'd say this makes for more instability than an elegent solution to enable/disable plugs.


Still not sure why my idea seems so wildly unpopular... maybe somebody could explain?

[TETENAL]

Originally Posted by besson3c

We've been through this. People are writing hacks regardless.

But people know they don't have support from Apple and do it on their own risk.

Originally Posted by besson3c

Besides, these plug-ins need not be crappy.

But some will and Apple has no way to control the quality of that code. So they don't want to support it.

[besson3c]

Originally Posted by TETENAL

But people know they don't have support from Apple and do it on their own risk.But some will and Apple has no way to control the quality of that code. So they don't want to support it.

Who says that Apple would have to support these plugs? Pretty simple, if you want support from Apple, Apple will make you disable these plugs. In fact, having an interface to do so makes things much easier for Apple, as it removes the guess work as to whether or not somebody installed some hack and forgot about it.

[Spirit_VW]

I think the more basic question is:

"Why does it have to be Mail and/or Safari that does this?"

Mail and Safari are not intended to be end-all/be-all apps, whether by design or by plugin. Safari's good, but it didn't do all that I wanted - so I got OmniWeb. Just because Safari doesn't do everything I wanted doesn't mean it's a bad program. It just means it currently doesn't do what I want. It obviously does more-or-less exactly what a great number of people want, though. They're not wrong, and I'm not wrong. Different apps for different people. Mail and Safari have their goals & purposes, which may or may not meet your needs. If they do, great - use them, and enjoy them (I love Mail, for example). If not, look for alternatives.

[Moose]

Originally Posted by besson3c

Financial gain:

- more viability and value of Apple's bundled products in business and places where workflow is a little more complex, without having to buy additional software at a flat rate or per seat.

Plugins can cost money, too, just like big boy software.

Originally Posted by besson3c

- more developers interested in developing stuff for Apple which in turn leads to more consumer choice and attractive options for consumers, which leads to increased hardware sales

You're reaching here.

Originally Posted by besson3c

- more OS sales

And when you run out of things that almost sound reasonable, you just start making **** up.

- an opportunity to market these plug-ins just as Apple has done with Dashboard widgets

And now it's game over for you, as you just demonstrated that Apple does make third-party development opportunities WHERE IT MAKES SENSE.

Seriously, if you really think that making it so that PithHelmet didn't have to use undocumented behavior would sell more Macs, you're just being silly.

Apple should not have to expend time and effort just because you don't like the functionality that Mail and Safari offer.

[besson3c]

I see your points, and you have changed my thinking a little.

However, I still see some viability in aspects of my own thinking. I guess we'll have to agree to disagree.

My little list in my last post was just a brainstorm I came up with off the top of my head, I didn't intend it to be picked apart or fixated on, just wanted to offer some contrasting perspective. I hope that you see a little viability in some of my ideas too.

[Moose]

Originally Posted by besson3c

I hope that you see a little viability in some of my ideas too.

In a perfect world where Apple has unlimited (or near unlimited) engineering resources, in some circumstances, a plugin architecture would be handy.

But we don't live in that world; in this world, public plugin APIs for Mail and Safari are not worth the cost.

[Chuckit]

Incidentally, WebKit is open-source. If you want to give Safari a plugin interface, knock yourself out!

[besson3c]

Originally Posted by Chuckit

Incidentally, WebKit is open-source. If you want to give Safari a plugin interface, knock yourself out!

Yeah, I know that Webkit is open-source, and where to get the source too. I'm happy with Firefox, but I probably would have stayed on Safari if some of the same plug-ins were available for it (and it didn't seem to slow down over time until I restart the app)

[goMac]

Originally Posted by besson3c

We've been through this. People are writing hacks regardless.

Right. And Apple doesn't have to support them.

If Apple adds an API for something, they have to support it. That's the difference. Apple doesn't want to support all this injected code.

[Chuckit]

Originally Posted by besson3c

Yeah, I know that Webkit is open-source, and where to get the source too. I'm happy with Firefox, but I probably would have stayed on Safari if some of the same plug-ins were available for it (and it didn't seem to slow down over time until I restart the app)

So then your problem is not that Apple doesn't have a public API for Safari, but that it's not Firefox.

[besson3c]

Originally Posted by goMac

Right. And Apple doesn't have to support them.

If Apple adds an API for something, they have to support it. That's the difference. Apple doesn't want to support all this injected code.

Okay, I see your point there. They need to support them in so far as to provide the hooks the developers need, and document their usage.

However, Apple has open sourced the entire damn kernel, Bonjour, iCal Server, Darwin Streaming Server, Webkit, Webojects, and provides developer documentation for Quicktime, Cocoa, etc. It's not as if they don't work with developers external to Apple on projects. A plug-in archetecture would be a relative piece of cake compared to these others projects, no?

[besson3c]

Originally Posted by Chuckit

So then your problem is not that Apple doesn't have a public API for Safari, but that it's not Firefox.

It's not a problem really, I can use Firefox or some other product, and the problem is solved. I was just wondering what the rational is to drive people like me (albeit a minority) to other products.



(And no, you don't have to answer that question if you will just be reiterating the points already made... I get them).

[Moose]

Originally Posted by besson3c

(And no, you don't have to answer that question if you will just be reiterating the points already made... I get them).

We'd stop using the same answers if you were to stop asking the same question.

[Chuckit]

Originally Posted by besson3c

However, Apple has open sourced the entire damn kernel, Bonjour, iCal Server, Darwin Streaming Server, Webkit, Webojects, and provides developer documentation for Quicktime, Cocoa, etc. It's not as if they don't work with developers external to Apple on projects. A plug-in archetecture would be a relative piece of cake compared to these others projects, no?

A plug-in architecture adds complexity that Apple itself has to deal with. Accepting tested code from outside parties is much easier than maintaining additional complexity, as I'm sure you've seen.

[besson3c]

Originally Posted by Moose

We'd stop using the same answers if you were to stop asking the same question.

I just want to be understood.

[besson3c]

Originally Posted by Chuckit

A plug-in architecture adds complexity that Apple itself has to deal with. Accepting tested code from outside parties is much easier than maintaining additional complexity, as I'm sure you've seen.

So you're saying that Apple would have to be somewhat accountable for these projects in providing the infrastructure the developers need?

[Moose]

Originally Posted by besson3c

I just want to be understood.

As do I.

The problem is that you continue to make statements like this:

Originally Posted by besson3c

I was just wondering what the rational is to drive people like me (albeit a minority) to other products.

You make it sound like Apple is intentionally expending effort to antagonize a minority of its users. The reality is that Apple just isn't expending its resources on what would necessarily be a not-so-small undertaking to appease a (by your own admission) minority of its users.

[Moose]

Originally Posted by besson3c

So you're saying that Apple would have to be somewhat accountable for these projects in providing the infrastructure the developers need?

What we're saying is that if it's a publicly documented API, Apple has to support it through regression testing, documentation, and Developer Technical Support. This is not a low-cost undertaking, so it's not done just because a handful of users might find it useful.

[besson3c]

Originally Posted by Moose

As do I.

The problem is that you continue to make statements like this:
You make it sound like Apple is intentionally expending effort to antagonize a minority of its users. The reality is that Apple just isn't expending its resources on what would necessarily be a not-so-small undertaking to appease a (by your own admission) minority of its users.

I understand that, and I understand the reasons why. That is probably the wisdom behind Apple's decision, and I understand that.

I just see it a little differently where the advantages would outweigh the disadvantages for Apple, and was wondering whether my perspective is shared. You don't have to explain Apple's possible stance on this, I really do get it.

And yes, you have made a good case that has caused me to move from having a firm stance to waffling a little.