357 lines
28 KiB
HTML
357 lines
28 KiB
HTML
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
||
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Be Newsletters - Volume 2: 1997</title><link rel="stylesheet" href="be_newsletter.css" type="text/css" media="all" /><link rel="shortcut icon" type="image/vnd.microsoft.icon" href="./images/favicon.ico" /><!--[if IE]>
|
||
<link rel="stylesheet" type="text/css" href="be_newsletter_ie.css" />
|
||
<![endif]--><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><link rel="start" href="index.html" title="Be Newsletters" /><link rel="up" href="volume2.html" title="Volume 2: 1997" /><link rel="prev" href="Issue2-5.html" title="Issue 2-5, February 5, 1997" /><link rel="next" href="Issue2-7.html" title="Issue 2-7, February 19, 1997" /></head><body><div id="header"><div id="headerT"><div id="headerTL"><a accesskey="p" href="Issue2-5.html" title="Issue 2-5, February 5, 1997"><img src="./images/navigation/prev.png" alt="Prev" /></a> <a accesskey="u" href="volume2.html" title="Volume 2: 1997"><img src="./images/navigation/up.png" alt="Up" /></a> <a accesskey="n" href="Issue2-7.html" title="Issue 2-7, February 19, 1997"><img src="./images/navigation/next.png" alt="Next" /></a></div><div id="headerTR"><div id="navigpeople"><a href="http://www.haiku-os.org"><img src="./images/People_24.png" alt="haiku-os.org" title="Visit The Haiku Website" /></a></div><div class="navighome" title="Home"><a accesskey="h" href="index.html"><img src="./images/navigation/home.png" alt="Home" /></a></div><div class="navigboxed" id="naviglang" title="English">en</div></div><div id="headerTC">Be Newsletters - Volume 2: 1997</div></div><div id="headerB">Prev: <a href="Issue2-5.html">Issue 2-5, February 5, 1997</a> Up: <a href="volume2.html">Volume 2: 1997</a> Next: <a href="Issue2-7.html">Issue 2-7, February 19, 1997</a></div><hr /></div><div class="article"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="Issue2-6"></a>Issue 2-6, February 12, 1997</h2></div></div></div><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="Engineering2-6"></a>Be Engineering Insights: Porting the BeOS to your Toaster Oven</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">Robert</span> <span class="surname">Herold</span></span></div></div></div><p>
|
||
Life used to be easy. There was one machine to support, and the guy who
|
||
designed it worked down the hall. There was hardware with logic analyzer
|
||
cables draped everywhere, revealing the most intimate details of how the
|
||
missing bits were being dumped on the floor.
|
||
</p><p>
|
||
Be's foray into the Macintosh market has complicated life considerably.
|
||
The Apple Developer CD has block diagrams for what boil down to seven
|
||
different PowerPC-based machine architectures. Clone vendors have added
|
||
their own riffs on the theme—multiprocessing hardware from DayStar,
|
||
graphics controllers from ATI and IMS, PCI-PCI bridges, ATAPI CD-ROM
|
||
drives, and the list goes on.
|
||
</p><p>
|
||
Many people have asked why the BeOS doesn't run on THEIR Macs. Given
|
||
sufficient time, effort, and money, the BeOS could run on anything. In
|
||
the end it boils down to a business decision—how hard will the port
|
||
be, how much time do we have, how many machines are there, and will there
|
||
be and what are the technical and marketing benefits.
|
||
</p><p>
|
||
With your indulgence of one paragraph of whining, I'll offer the
|
||
following. We're a small team of engineers—sixteen software, four Q/A,
|
||
three documentation, one build guy, and one-who-must-be-obeyed project
|
||
manager. We're constantly trading off between supporting more machines
|
||
with our current software and moving the BeOS architectural stake
|
||
forward. (To say nothing of distractions like the van that just burst
|
||
into flames in front of our office—comments that there may have been a
|
||
PowerBook on the front seat are completely uncalled for.) We want the
|
||
BeOS to run everywhere, but we still have to finish the !@#$ thing.
|
||
Developers need a stable API to write to, yet they require a sufficiently
|
||
rich feature set to add their magic touches to. Venture capitalists are
|
||
eager for some return on their investment, and Be's checking account
|
||
balance only seems to shift right (fortunately the sign bit isn't set).
|
||
</p><p>
|
||
In the upcoming DR9 release we're laying the foundation to support a
|
||
wider variety of platforms. The new extensible file system architecture
|
||
is the first evidence of this effort. On the low-level front, our intent
|
||
is to distill the experience of porting the BeOS from Hobbit to <span class="trademark">BeBox</span>™
|
||
to Macintosh into the specification of a hardware abstraction layer
|
||
(HAL). Ideally it will be possible for a company to slap together a new
|
||
computer, write a little firmware, and poof! a new BeOS machine is born.
|
||
</p><p>
|
||
The HAL isn't designed yet, so I'll do it here. It should address the
|
||
following:
|
||
</p><ul class="itemizedlist"><li><p>
|
||
Firmware-kernel interface: How and where the firmware loads the
|
||
kernel and passes information to the kernel
|
||
</p></li><li><p>
|
||
Processors: How other processors are started, and how the processors
|
||
interrupt each other
|
||
</p></li><li><p>
|
||
I/O: Which processor(s) handle I/O interrupts, and how they're
|
||
dispatched
|
||
</p></li><li><p>
|
||
Physical address map: Where the memory, I/O, busses, and ROM are, and
|
||
how they're mapped into the BeOS logical address space
|
||
</p></li><li><p>
|
||
Configuration: What I/O devices are present
|
||
</p></li><li><p>
|
||
Power: Controlling power consumption, and restarting or shutting down
|
||
the hardware
|
||
</p></li></ul><p>
|
||
Shameless imitation is an option as well. Our friends in Redmond have
|
||
solved this problem, as have other operating system vendors. No point
|
||
reinventing the wheel...
|
||
</p><p>
|
||
With the decision to stop making the BeBox, Be has committed to the path
|
||
of supporting Other Peoples' Hardware. This road isn't without peril --
|
||
there's an incredible variety of hardware out there, all developed to
|
||
work with some other operating system. We face a formidable challenge in
|
||
propagating the BeOS across as much of this hardware as possible, while
|
||
still improving the BeOS architecture. Time to get back to writing code.
|
||
</p></div><hr class="pagebreak" /><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="News2-6"></a>News From The Front</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">William</span> <span class="surname">Adams</span></span></div></div></div><p>
|
||
So I was over at Nanny Jan's this morning trying to figure out the
|
||
appropriate Georgism to introduce this week's article. As I was dropping
|
||
off Yasmin, I found this toy on the table. It was some super destructor
|
||
battle cart thingy that had a winch with string that was all tangled
|
||
around it. Being the father that I am, I proceeded to try to unravel the
|
||
string and restore the toy to its original place in the hierarchy of
|
||
devices of mass destruction.
|
||
</p><p>
|
||
I struggled for a while, pulled here and there, managed to get quite a
|
||
long way. Then I found that if I used a needle, it was a lot easier. Then
|
||
it seemed I had come to an impasse. The work was too intricate and too
|
||
tight, and I couldn't really see what I was doing. So Nanny Jan, in her
|
||
infinite wisdom, asks me, "Should I turn on the light?"
|
||
</p><p>
|
||
One of the most fun things about being a pioneer on the bleeding edge is
|
||
that you get to blaze new trails, creating a path for others to follow.
|
||
The most successful pioneers didn't necessarily invent completely new
|
||
wagons and horses in order to blaze the trail, but they used the tools at
|
||
hand and improved upon them. As a programmer, I'm a scrounge. I've long
|
||
since found that if someone has already created an algorithm or data
|
||
structure that suits your needs, it's probably better to start from there
|
||
rather than from scratch.
|
||
</p><p>
|
||
I'm continually amazed at the neat things that programmers do, and it's
|
||
particularly amazing when someone explains a new algorithm or routine to
|
||
you in such a way that the light turns on in your head and you think,
|
||
"it's so obvious, I knew it all along." Well this week I choose to delve
|
||
into my sordid Objective-C past and pull out what I've found to be quite
|
||
a useful tool.
|
||
</p><p>
|
||
Way back in the days of Mission Critical Custom Apps we created two of
|
||
the most important objects known to programmer: DataSet and TableField.
|
||
Between these two objects, no typical MCCA stood a chance of evasion from
|
||
our skills. Combined they form the basis of a nice RDBMS local cache with
|
||
write-through persistence sort of thing. The basic idea is that you have
|
||
a bunch of data that can be categorized into a bunch of 'records,'
|
||
standard row/column stuff. You want to add records, delete them, find
|
||
them, and all that.
|
||
</p><p>
|
||
It's similar to the BMessage object, but different in purpose. A BMessage
|
||
can hold a bunch of opaque data, and it's primarily meant for messaging,
|
||
not as the basis of a record manager. On the other hand, DataSet is the
|
||
basis for in-memory relational set operations, among other things. We
|
||
discovered that these objects have much greater use beyond that of their
|
||
initial database design. So this week I present a shadow of its former
|
||
self, the DataSet library:
|
||
</p><p>
|
||
ftp://ftp.be.com/pub/Samples/dataset.tgz
|
||
</p><p>
|
||
If nothing else, you'll find a bunch of funky C++ code straight from the
|
||
heart of darkness.
|
||
</p><p>
|
||
Geoffrey Woodcock has been at it again. His multi-user scratchpad
|
||
tutorial is coming along. It makes for an excellent tutorial on our
|
||
developer web pages. You'll learn about networking in our multithreaded
|
||
environment and some other funky threading issues.
|
||
</p><p>
|
||
But this guy just can't stop. No sooner does he finish his tutorial than
|
||
he starts on our developer support system. Under promise, over deliver,
|
||
that's our motto. When it's done, you'll be happy with the results. It's
|
||
quite impressive stuff, and it makes me happy to know that he's on our
|
||
side. This will be the basis for allowing our developers to be in closer
|
||
contact with us and have a better handle on the pitfalls that might be
|
||
known in the system.
|
||
</p><p>
|
||
Since we introduced the MacTech PowerPC version of the BeOS, there's been
|
||
quite a flood of activity for technical support. Well now has come the
|
||
time to differentiate "developer" support from "customer" support. Not
|
||
all people currently using the BeOS are developers. Questions like "how
|
||
do I partition my Mac hard disk" and "will the BeOS work on my PowerBook"
|
||
are not really software developer questions. As DR9 approaches, I'm sure
|
||
we'll get a rash more of these questions. So now you have a new place to
|
||
e-mail to for answers.
|
||
</p><p>
|
||
custsupport@be.com
|
||
</p><p>
|
||
Our web page reflects this change, and you can use this address whenever
|
||
you have a configuration type of question. The simple test is, if you
|
||
have a programming question, then fill out the Developer Support form in
|
||
the Registered Developer Area. This is also the case for questions
|
||
related to developer IDs, conference registrations, and general
|
||
introductions to the rich and powerful. If you have any other questions,
|
||
such as what Power Macs are supported or why you can't configure your
|
||
particular machine to run the BeOS, send them to the custsupport@be.com
|
||
address. What you'll find right now is that all of the questions will be
|
||
answered, no matter which way you send them, but it helps us to
|
||
categorize them. In addition, we want to encourage you to use our web
|
||
page for as much information as you can. It's extremely helpful if you
|
||
read the FAQ in our support area for typical questions regarding
|
||
installation.
|
||
</p><p>
|
||
Well the year's starting out smoothly, DR9 chugs along, and GCC has been
|
||
ported to the BeOS.
|
||
</p><p>
|
||
See you next week.
|
||
</p></div><hr class="pagebreak" /><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="Gassee2-6"></a>Heidi Roizen</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">Jean-Louis</span> <span class="surname">Gassée</span></span></div></div></div><p>
|
||
Yesterday Heidi Roizen announced that she was leaving Apple by February
|
||
19. She's been VP of Developer Relations since January of last year. Her
|
||
stated reason for leaving is her desire to spend more time with her two
|
||
young children. There's enough press dissection of the circumstances
|
||
surrounding her decision for me to leave it at that.
|
||
</p><p>
|
||
I'd rather pay tribute to Heidi. She came in and helped Apple through
|
||
difficult times when developers, unsure of the future of the MacOS,
|
||
needed someone to be their liaison with Apple's management, their
|
||
visible, believable champion. Heidi is a former Mac developer herself:
|
||
She headed T/Maker, sold in 1995 to DeLuxe. She had both the experience,
|
||
the skills, and the charisma to be the standard-bearer for the Mac
|
||
community. Words such as "irreplaceable" can sound excessive, but it will
|
||
be hard to find someone to replace Heidi, someone who will enjoy as much
|
||
trust and respect in the Mac development community as she does.
|
||
</p><p>
|
||
Closer to home, Heidi has been instrumental in helping us port the BeOS
|
||
to Power Macs and clones built by Power Computing, Motorola, UMAX, and
|
||
DayStar. She felt the PowerPC family needed more players, more momentum,
|
||
more excitement in order to reverse the market share slide, and she
|
||
thought we could help a little. When red tape or organizational flux got
|
||
in the way, she got things back on track. As a result, we were able to
|
||
show a first version of the BeOS running on Power Computing hardware in
|
||
August 1996, at Macworld Boston. Without her support we wouldn't be where
|
||
we are today. Her influence helped open a larger hardware playing field
|
||
for the BeOS and, as a result, for our developers. Moving to the Mac
|
||
hardware family and finding several attractive multiprocessor systems
|
||
allows us to focus solely on the area where we add the most value,
|
||
software.
|
||
</p><p>
|
||
We now have a simple goal: To become the OS of choice for creative
|
||
digital media applications. And we're in Heidi's debt for her role in
|
||
simplifying our business.
|
||
</p><p>
|
||
I don't know what Heidi will do now. Certainly she'll want to take a
|
||
break after a tumultuous year at Apple and spend time with her family.
|
||
Still, I can't imagine her not wielding her considerable skills and
|
||
influence on the Silicon Valley scene. I imagine venture capitalists
|
||
calling her, and I can see quite a few start-ups wanting to enlist her
|
||
leadership skills. It will be fun to watch.
|
||
</p></div><hr class="pagebreak" /><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="BeDevTalk2-6"></a>BeDevTalk Summary</h2></div></div></div><p>
|
||
BeDevTalk is an unmonitored discussion group in which technical
|
||
information is shared by Be developers and interested parties. In this
|
||
column, we summarize some of the active threads, listed by their subject
|
||
lines as they appear, verbatim, in the mail.
|
||
</p><p>
|
||
To subscribe to BeDevTalk, visit the mailing list page on our web site:
|
||
http://www.be.com/aboutbe/mailinglists.html.
|
||
</p><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id548473"></a>WEEK 3</h3></div></div></div><div class="sect3"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id548479"></a>Subject: GUI (in)consistency</h4></div><div xmlns:d="http://docbook.org/ns/docbook"><h5 xmlns="http://www.w3.org/1999/xhtml" class="subtitle">
|
||
AKA: Issues for PC makers (GUI & plug+play)<br />
|
||
AKA: More GUI questions
|
||
</h5></div></div></div><p>
|
||
Religious question of the week: Is anything intuitive on a computer?
|
||
Does the user bring inborn (or culturally developed) preferences for
|
||
the placement of menus, their stickiness, "moused-ness," and so on?
|
||
</p><p>
|
||
Practical issues and sound bites:
|
||
</p><ul class="itemizedlist"><li><p>
|
||
Main Menu Placement
|
||
</p><div class="blockquote"><table border="0" cellspacing="0" cellpadding="0" class="blockquote" summary="Block quote"><tr><td width="90%" valign="top"><p>
|
||
[H]aving a *defined* place for a main control menu is a good
|
||
[idea]... It's a lot quicker... than [digging] through a mess of
|
||
windows.
|
||
</p></td><td width="5%" valign="top"> </td></tr><tr><td width="100%" colspan="2" align="right" valign="top">—</td></tr></table></div><div class="blockquote"><table border="0" cellspacing="0" cellpadding="0" class="blockquote" summary="Block quote"><tr><td width="90%" valign="top"><p>
|
||
For a [new] user... the placement of the main menu is probably not
|
||
very easy to figure out. [But] once it's [found] I find it hard to
|
||
understand anyone saying that it's hard to remember... I think the
|
||
main problem with it is that it's awkwardly placed. It takes a lot of
|
||
mouse movement... to access it.
|
||
</p></td><td width="5%" valign="top"> </td></tr><tr><td width="100%" colspan="2" align="right" valign="top">—</td></tr></table></div><div class="blockquote"><table border="0" cellspacing="0" cellpadding="0" class="blockquote" summary="Block quote"><tr><td width="90%" valign="top"><p>
|
||
...in Windows you get a default menu by clicking on the
|
||
left-hand-side application button (used to be the kill box)... I
|
||
don't necessarily want BeOS to look anything like Windows, but the
|
||
advantage of this extra menu is that it's logically part of the
|
||
window it applies to. There's no need to mouse up to the top of the
|
||
screen.
|
||
</p></td><td width="5%" valign="top"> </td></tr><tr><td width="100%" colspan="2" align="right" valign="top">—</td></tr></table></div></li><li><p>
|
||
Window Clutter
|
||
</p><div class="blockquote"><table border="0" cellspacing="0" cellpadding="0" class="blockquote" summary="Block quote"><tr><td width="90%" valign="top"><p>
|
||
I (almost) always hold down the 'control' when opening windows,
|
||
because I *know* where I want to go... Another cool thing to do would
|
||
be able to open the *directory* a file was in with "open parent," in
|
||
case you killed all the windows on the way to the file.
|
||
</p></td><td width="5%" valign="top"> </td></tr><tr><td width="100%" colspan="2" align="right" valign="top">—</td></tr></table></div></li><li><p>
|
||
Modal Dialogs
|
||
</p><p>
|
||
Maarten L. Hekkelman asked “<span class="quote">when should a dialog be modal and when
|
||
non modal?</span>”
|
||
</p><div class="blockquote"><table border="0" cellspacing="0" cellpadding="0" class="blockquote" summary="Block quote"><tr><td width="90%" valign="top"><p>
|
||
I would take the position that a dialog should be modeless unless
|
||
the interaction HAS to be executed before it is meaningful for other
|
||
activities to continue.
|
||
</p></td><td width="5%" valign="top"> </td></tr><tr><td width="100%" colspan="2" align="right" valign="top">—</td></tr></table></div><div class="blockquote"><table border="0" cellspacing="0" cellpadding="0" class="blockquote" summary="Block quote"><tr><td width="90%" valign="top"><p>
|
||
Almost all algorithms can be structured such that the program
|
||
doesn't NEED the information to go back and 'do nothing' until the
|
||
information arrives. It's just a little more work for the programmer,
|
||
but it gives a MUCH better user experience.
|
||
</p></td><td width="5%" valign="top"> </td></tr><tr><td width="100%" colspan="2" align="right" valign="top">—</td></tr></table></div></li></ul><p>
|
||
General UI Look
|
||
</p><p>
|
||
Jon Ragnarrson has posted his opinions in the form of a Web page:
|
||
http://www.vortex.is/Islenska/Notendur/jonr/Be/BeGui.html
|
||
</p></div></div><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id548629"></a>WEEK 2</h3></div></div></div><div class="sect3"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id548636"></a>Subject: Be's hardware plans</h4></div><div xmlns:d="http://docbook.org/ns/docbook"><h5 xmlns="http://www.w3.org/1999/xhtml" class="subtitle">AKA: Problems with BeOS only on powermacs</h5></div></div></div><p>
|
||
A cleansing facial mask of eulogy and malediction for the late Blue Box
|
||
punctuated by colorful slurs against the corporate persona.
|
||
</p><p>
|
||
Listeners expressed interest in the specifics of the PIOS box; some
|
||
suggested that PIOS resurrect the BeBox design.
|
||
</p></div><div class="sect3"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id548659"></a>Subject: lets talk about cursors</h4></div></div></div><p>
|
||
A particular cursor designation suggestion from last week—each
|
||
window (or area within a window) could register (with the Application
|
||
Server) a custom cursor image—was debated. The primary advantage of
|
||
the system is that changing the cursor wouldn't require a lot of data
|
||
to be passed between the client and the server. The primary objection
|
||
from last week—context-sensitive cursors would be difficult in this
|
||
scheme—was considered to be either a price worth paying or a feature
|
||
that could be worked into the general plan.
|
||
</p></div></div><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id548672"></a>NEW</h3></div></div></div><div class="sect3"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id548678"></a>Subject: Mail transfer</h4></div></div></div><p>
|
||
Can you tell the mail_daemon to retrieve mail messages without deleting
|
||
them from the server, such that you can read your mail from different
|
||
machines without having to explicitly transfer the messages between
|
||
computers?
|
||
</p><p>
|
||
A listener suggested that the easiest solution is an IMAP server
|
||
(Internet Message Access Protocol; see www.imap.org/whatisIMAP.html).
|
||
</p><p>
|
||
Objections:
|
||
</p><ul class="itemizedlist"><li><p>
|
||
IMAP doesn't fit well with Be's philosophy of a-message-
|
||
is-a-database-record.
|
||
</p></li><li><p>
|
||
If you don't delete your messages occasionally, you start to use
|
||
up (possibly costly) server space.
|
||
</p></li><li><p>
|
||
IMAP security isn't strict enough.
|
||
</p></li></ul><p>
|
||
As an alternative, a listener suggested POP3, which (it was claimed)
|
||
has a feature set that's similar to IMAP—in particular, it can
|
||
support multiple remote readers.
|
||
</p></div><div class="sect3"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id548730"></a>Subject: Database-only items in DR9</h4></div></div></div><p>
|
||
In DR9, every database record will be stored in its own file, and the
|
||
notion of a table as a predefined template of attributes for a record
|
||
disappears. The implications of these decisions were discussed:
|
||
</p><ul class="itemizedlist"><li><p>
|
||
File-based records mean there's no hidden data. Some folks fear
|
||
that this could lead to hierarchy clutter; others think that the
|
||
approach is a desecration of database principles—they *want*
|
||
hidden data.
|
||
</p></li><li><p>
|
||
The lack of tables means that while you'll no longer be able to
|
||
make assumptions about the structure of a specific file, you'll be
|
||
able to query over a larger domain. A number of listeners wrote in to
|
||
support the idea that optional table-like functionality be added to
|
||
the new file system.
|
||
</p></li></ul><p>
|
||
Most folks are pleased with the record-is-a-file business. As Ficus
|
||
Kirkpatrick put it:
|
||
</p><p>
|
||
“<span class="quote">'Hiding' things in the database is sort of a security-
|
||
through-obscurity type of attitude. I've written a database editor that
|
||
I can browse tables and modify records with easily. It's just something
|
||
that you won't have to get a separate app to do anymore.</span>”
|
||
</p><p>
|
||
Nonetheless, the database-only crowd was persistent. David Evans:
|
||
</p><p>
|
||
“<span class="quote">What we seem to have... is a filesystem with some added database
|
||
'gizmos'... It basically removes the 'Record' abstraction and makes
|
||
database items an extra to files.</span>”
|
||
</p><p>
|
||
Other issues:
|
||
</p><p>
|
||
What happens to pre-DR9 tables? How are they converted?
|
||
</p><p>
|
||
Do the files that hold psuedo-records need to be named? Can the
|
||
system generate noncolliding "anonymous" names automatically?
|
||
</p><p>
|
||
What about security? Geoffrey Clements says he's working on DCE
|
||
(http://www.osf.org/dce) for the BeOS.
|
||
</p></div><div class="sect3"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id548817"></a>Subject: Highlighting ICONs</h4></div></div></div><p>
|
||
Icon highlighting questions: How do you highlight an icon? When should
|
||
it be highlighted/unhighlighted? When will icon animation be allowed?
|
||
</p></div></div></div></div><div id="footer"><hr /><div id="footerT">Prev: <a href="Issue2-5.html">Issue 2-5, February 5, 1997</a> Up: <a href="volume2.html">Volume 2: 1997</a> Next: <a href="Issue2-7.html">Issue 2-7, February 19, 1997</a> </div><div id="footerB"><div id="footerBL"><a href="Issue2-5.html" title="Issue 2-5, February 5, 1997"><img src="./images/navigation/prev.png" alt="Prev" /></a> <a href="volume2.html" title="Volume 2: 1997"><img src="./images/navigation/up.png" alt="Up" /></a> <a href="Issue2-7.html" title="Issue 2-7, February 19, 1997"><img src="./images/navigation/next.png" alt="Next" /></a></div><div id="footerBR"><div><a href="http://www.haiku-os.org"><img src="./images/People_24.png" alt="haiku-os.org" title="Visit The Haiku Website" /></a></div><div class="navighome" title="Home"><a accesskey="h" href="index.html"><img src="./images/navigation/home.png" alt="Home" /></a></div></div><div id="footerBC"><a href="http://www.access-company.com/home.html" title="ACCESS Co."><img alt="Access Company" src="./images/access_logo.png" /></a></div></div></div><div id="licenseFooter"><div id="licenseFooterBL"><a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/" title="Creative Commons License"><img alt="Creative Commons License" style="border-width:0" src="https://licensebuttons.net/l/by-nc-nd/3.0/88x31.png" /></a></div><div id="licenseFooterBR"><a href="./LegalNotice.html">Legal Notice</a></div><div id="licenseFooterBC"><span id="licenseText">This work is licensed under a
|
||
<a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/">Creative
|
||
Commons Attribution-Non commercial-No Derivative Works 3.0 License</a>.</span></div></div></body></html>
|