Advocacy
Dojo (HowTo)
Reference
Markets
Museum
News
Other
Myths
Press
General
Hack
Hardware
Interface
Software
Standards
People
Forensics
Web
CodeNames
Easter Eggs
History
Innovation
Sightings
Opinion
Martial Arts
ITIL
Thought
|
Resource Management is changing in OS X and Carbon. These resource changes are coming soon -- actually, they will come to Sonata first, then OS X later.
If you don't know what resources are, then read Hack : What is a Resource or Innovation : File Forks to get what these things are and to understand a little about how (why) they work.
There will still be traditional resources, just like now -- but the way they are bundled in with Applications is changing (expanding). In fact, the way that you "package" an Application (with all the code and resources) is being radically improved.
The Old Way
In the early days, Mac Apps were very simple.
What the user sees = 
Application.
There was one Application that the user saw, and it did everything. People that wanted to move an Application would just move it, and everything to do with that Application would move as well (it was self-contained). Everything you would want to contain for an App was in that single file. Things were simple and pure.
Well times they have been a changin'. The problem was that a single file (Application) couldn't contain everything that a user might need. So things grew, and grew, and grew. Now days a single Application usually a folder, that contains many parts of the Application, some plug-ins, some parts, and so on. It is big, messy, and worst of all that isn't all of it -- some parts of an Application can be stuffed into the extensions folder (shared libraries) or put elsewhere on the system at install time. When you copy a folder, you may not get those parts, and so your Application is broken, some installers may remove those shared libraries, which can break another Application, and so on. The Mac is almost behaving as poorly as Windows. And we need even MORE complexity and power for building future Applications than the mess we already have.
So now it is time (or well over time) to make things easy again.
The New Way (called a Package)
So Apple is bringing back the single Application.
What the user sees = Application.
Now of course, Apple isn't going to be able to force users to cram everything into one file again -- that would be ugly and bad, and you can't turn back the clock. But Apple can make it look like that, even when there is really a whole hierarchy (directory tree) containing an Application.
Apple created a solution that was a very nice hybrid of the way that NeXT did things, combined with the way the Mac does things -- and we get something that is better than either.
Apple will use a special bit for a folder, which tells the folder that it is a special hierarchy of folders that will contain all the proper parts that the System wants for a single Application. What will truly be there, behind the facade of a single Application, is really the following:
Support folder
info.plist - (xml tags to explain)
What this hierarchy gives users, and programmers, are many new features.
- The user will just have to work with a single
Application on the new version of the OS -- but even on
the older versions of the OS, they will still see
something that makes sense and is standardized.
- A single Application can really contain many binaries
(executables). Including versions of the code for
multiple versions of the OS. So a single Application can
run on OS 8, Mac OS 9, Mac OS 10 -- and they can even run
on multiple platforms (that support this OS). So someday
there could be an OS 8 for PowerPC version, and a OS X
for Intel version of the Application, and so on.
Basically this is planning ahead.
- A single Application can support multiple languages.
Currently this can be done on the Mac OS -- but it is
tricky. Basically you would have to have separate files
for each language, and you'd have to load the right
resources for the language you are using (and often have
duplicate resources in each version of the file). Under
the new way, the same Application will automatically
support the Language / System that the user is using, and
the programmers have a little less work to do.
- Shared Libraries are bundled with the Application.
This is important. The Operating System will
automatically figure out (and manage) multiple shared
libraries (and versions) for programmers. There will be
duplicate versions of shared libraries on the disk
(assuming multiple Applications both use the same shared
library). Of course the system will only let one instance
of a version to be running (to save on memory). And under
the new way, the user (or Application) can delete or
relocate any Application (and it's shared library) -- and
this will never hurt any other Application. That is a
refreshing change over today, where deleting a library
can break other Applications.
- The Programmer gets far more metadata (extra information about the file) contained in a more versatile format (.xml). This will allow for more growth, and more custom information, and yet it is in a more standard format, and the whole way this system works is more compatible with other filing systems (than the current Mac way).
Conclusion
Basically what all this means is that Applications will just be magic for users and programmers. Programmers just bind in all the things that they need to work. New Resources (Application binding) use the best of the NeXT way -- but is still compatible with Macs, old resources, and you can do more than you could before. Things should be even more transparent for users, because of Mac advantages as well, and you can still encapsulate file fragments into a single file. It will be far harder to break programs by deleting a component (as a programmer or user). This system is far more versatile than the current Mac way. And this system is more standard, and is more likely to work across networks since any filing system can understand what is going on. This is truly the best of both worlds. It is very rare that you can get a Win-win (win-win-win-win...) type of improvement in any sort of engineering -- but this appears to be one of those rare cases.
|
