Be Developer Services

Free Resources

BeIA FAQ

BeIA Evaluation

Partner Program

Join

Partner Area

Issue 21    March 21, 2001 Be in the News March 9, 2001 BeOS: All Operating System -- No Flab, ComputerEdge Online Be Press Release March 13, 2001 Be to Include the Macromedia Flash Player in BeIA March 22, 2001 Be Announces Licensing and Distribution Agreement with Sony return to top The Music Industry and PCs by Jean-Louis Gassée, CEO and Chairman Around four years ago, the music industry started something called the Secure Digital Music Initiative. Apparently, it fizzled, because there is no evidence of it today. Yes, we have proposals and possible formats such as Sony's ATRAC, but in practice, MP3 is king. Real Networks and Microsoft are fighting it out in the marketplace with ambitious plans to provide complete encoding and playback solutions, while Napster tries to transition from perceived accomplice of piracy to partner of the "legit" music industry. But we still have no practical, standardized way to buy secure digital music. In theory, secure digital music lets buyers and sellers do business on attractive terms. The basic business model is similar to the time-tested telephone financial structure. The phone companies have a costly infrastructure but, once that is in place it doesn't cost the Baby Bell a red cent when I pick up the phone and dial, and they generate nice profit margins by charging me a few units of currency. Put another way, the phone companies have near-zero incremental costs. Returning to selling secure digital music online, we see the similarity. A relatively expensive infrastructure is needed, after that, selling me one hour of Mikhail Pletnev costs the company very little. On the buy side, I can choose between "transient" and "persistent" versions. The first one plays and disappears. The second is stored on my computer, playable at will, as with a CD, but impossible to duplicate or pirate -- hence, secure. So why hasn't security arrived? We can dispose of the loudspeaker wires explanation: you can record the music in "clear text" out of the speaker connector, thus defeating the whole purpose. That was always true and the Napster saga demonstrates that we prefer the easy digital reproduction process -- less work and better quality. The same is true for pirating CDs, which took off with the availability of CD-R and CD-RW drives. The real explanation is that PCs are easily hacked and the hack can spread almost instantly to millions through the same network used to trade pirated content. Let's assume for a moment that we have software on a PC that provides a secure environment for streaming, saving, and playing back digital music. A determined individual or team will always find a way to defeat the protection. We've seen, or rather heard, the fracas over unlocking DVD codes for playback on Linux systems. Once the defeating code is available, it spreads like a virus, with the important difference that many people welcome it. The problem doesn't lie with human nature and its instinct for picking locks and "liberating" property. No, the real trouble lies with the PC. It's too easily accessible, too easily modified to all kinds of ends, and too exciting a medium for experimentation to prove one's intellectual personhood. By now you've figured out where I'm going. The key to unlock, rather than secure, digital music and its market potential is the appliance. Few people hack the software in cars (actually, I'm looking for one such magician, but that's another story). Few take pains to pry open game consoles, replay TV recorders, or DirecTV boxes. Which is not to say that pirates will be discouraged by appliances, but the hacks won't spread the way they can and do on PCs. Herein lies one of the reasons for our Home Audio Reference Platform, HARP. That is, we believe appliances solve the secure digital music problem in ways PCs can never match. return to top DasPortal by Raymond Rodgers, QA Engineer When I was asked to write an article for The BMessage, the first thing I did was panic. Then I regrouped and panicked again. Then I put together a plan. When they caught me at the airport, I decided to write a simple file sharing application. There were a few times when I was tempted to hop the next flight to Buenos Aires while designing and implementing dasPortal, but in the end, I admit, I'm rather proud of it. Such should be the result of any engineering project. The source can be found at ftp://ftp.be.com/pub/samples/bone/dasPortal.zip. Threads, threads everywhere, but not a single one to sync. Beneath the surface of dasPortal's Spartan user interface is a series of threads: dasPortal (BApplication) w>dasPortal (BWindow) NetCentral (BLooper) a.k.a. "The Core" Receiver Connection In addition to these five threads, dasPortal may spawn up to ten additional threads to handle file transfers. I hope a quick overview of how the app works will make you curious enough to dig in and rip dasPortal apart. The two main threads are pretty much self-explanatory; virtually all BeOS apps utilize BApplication and BWindow objects. No big deal there. However, NetCentral is a BLooper object which spawns both the Reeceiver and Connection threads at start-up, and can spawn the FileSenderThread and FileReceivingThread threads which send and receive files respectively. The intent and purpose of NetCentral's design is to handle all network communications, from the initial broadcast message it sends to locate instances running on other machines on your network to the file transfers themselves. dasPortal primarily uses BMessages as the data containers before a file transfer actually begins. This allows easy communication between any and all instances of dasPortal. Each incoming BMessage is tagged with its origin host, then processed depending on its 'what' value: some are passed on to the app's BWindow object, others are processed immediately by NetCentral's MessageReceived. The overall process might look something like this: Selecting a remote machine in the dasPortal window and dropping a file in it initiates the above process. The window sends a message to NetCentral and asks it to forward the message on to target machine; the target machine's receiver thread picks up the message and forwards the message on to its NetCentral object, which in turn sends a message back to the original machine requesting the file in question. The source machine picks up the message, spawns a sending thread that establishes a connection through the "Connection" thread, which in turn hands off the connection to a file receiver thread. Once the file transfer is complete, both the file sending threads and the the file receiving threads take their own lives happily. Because dasPortal's design makes extensive use of threads, it's a very responsive application. In addition because of its sample code nature, it is very small, uses the tricks and tips found only in the Be Book, and is not a perfect example of a BeOS application. One example of its imperfection is a race condition cured by the use of semaphores in the NetCentral constructor. Still, dasPortal demonstrates some basics of application design in a multithreaded environment, network communication via both TCP and UDP, and a dynamic menu system in a relatively small package. dasPortal also makes heavy use of BMessages, in case you hadn't noticed. This ultimate data container is used to store the program's settings (including the list of files being actively shared); to send commands from one part of the user interface to another; and to send commands from the UI to NetCentral and beyond. These are all common uses of BMessage objects. Be careful when using them across a network, however; if Be has changed the format of a flattened BMessage between versions of BeOS, machines running older versions of BeOS may not be able to communicate properly with machines running newer versions. (Though newer versions of BeOS will most likely be able to interpret the older format.) Now, before you run off and compile dasPortal, here's an important sanity check: dasPortal was written using BONE and pretty much requires it because of issues in net_server. Let's not go there. Please. I'll wrap this article up by telling you what this little program actually does: It's a simple way to use drag and drop file transfer programs. Starting dasPortal on two or more machines allows each instance to automatically detect and recognize each instance on your local network by utilizing a UDP broadcast. From there, you can add files to your shared list by clicking and dragging a file, with the secondary mouse button, to the window, which allows other users to select the files they want to download. All file transfers are currently hard coded to store the files at/boot/home/Downloads/ ; implementing a preference panel to change this option and others is left up to the reader as an exercise. Files can be more directly transferred by selecting a host from the menu field located at the top left of the window, and dropping a file on the window with the primary mouse button. Please drop me a line if you have any questions! return to top Statements contained in this Newsletter that are not historical facts are "forward-looking statements" including without limitation statements regarding the demand for, future market penetration and market acceptance of BeIA and BeOS, the shipment dates of Be's products, and the future operating results of Be Incorporated. Actual events or results may differ materially as a result of risks facing Be Incorporated or actual results differing from the assumptions underlying such statements. Such risks and assumptions include, but are not limited to, risks related to competition, market acceptance and market penetration of Be's products, ability to establish and maintain strategic relationships, the benefit of Be's products to OEM and Internet appliance manufacturers. the continued availability of third party BeOS applications and drivers, and the ability to establish and maintain strategic publishing relationships. All forward-looking statements are expressly qualified in their entirety by the "Risk Factors" and other cautionary statements included in Be Incorporated's Annual Report on Form 10-K for the year ended December 31, 1999, and other public filings with the Securities and Exchange Commission. The BMessage Copyright (c) 2001 by Be, Inc. All rights reserved. Be, Inc. 800 El Camino Real, Suite 400 Menlo Park, CA 94025 Tel: (650) 462-4100 Fax: (650) 462-4129 Web: http://www.be.com/ Be, BeOS and BeIA are trademarks or registered trademarks of Be Incorporated in the United States and other countries. Other brand product names are registered trademarks or trademarks of their respective holders. All rights reserved. The BMessage is sent to subscribers of one or more of the Be mailing lists. For more information about subscribing/unsubscribing, see the Be web site: http://www.be.com/world/mailinglists.html. The Be web site also offers a complete set of current and back issues of Be Newsletters: If you have any comments about The BMessage, please e-mail them to:newsletter@be.com.

About Be, Inc. | Be Products | World of Be | BeOS Support | Jobs | Developers | Press | Partners | Investors

Copyright © 2001 by Be, Inc. All rights reserved. (Legal Info)
Comments, questions, or confessions about our site? Please write the Webmaster!