nephele
/
haiku-website
0
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
haiku-website/static/legacy-docs/benewsletter/Issue1-45.html

439 lines
36 KiB
HTML
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<?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 1: 1995–1996</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="volume1.html" title="Volume 1: 1995–1996" /><link rel="prev" href="Issue1-44.html" title="Issue 1-44, October 9, 1996" /><link rel="next" href="Issue1-46.html" title="Issue 1-46, October 23, 1996" /></head><body><div id="header"><div id="headerT"><div id="headerTL"><a accesskey="p" href="Issue1-44.html" title="Issue 1-44, October 9, 1996"><img src="./images/navigation/prev.png" alt="Prev" /></a> <a accesskey="u" href="volume1.html" title="Volume 1: 1995–1996"><img src="./images/navigation/up.png" alt="Up" /></a> <a accesskey="n" href="Issue1-46.html" title="Issue 1-46, October 23, 1996"><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 1: 1995–1996</div></div><div id="headerB">Prev: <a href="Issue1-44.html">Issue 1-44, October 9, 1996</a>  Up: <a href="volume1.html">Volume 1: 1995–1996</a>  Next: <a href="Issue1-46.html">Issue 1-46, October 23, 1996</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="Issue1-45"></a>Issue 1-45, October 16, 1996</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="Engineering1-45"></a>Be Engineering Insights: Junk Mail</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">Polic</span></span></div></div></div><p>
Internet e-mail was introduced as part of the recent DR8 release of the
<span class="trademark">BeOS</span>™. As a number of developers have pointed out, the DR8 version of
the mail system broke a bit too easily when confronted with certain
POP/SMTP servers. A new version that fixes these incompatibilities will
be included as part of the update to DR8 (coming soon to an FTP site near
you). In the mean time, this article explains the architecture of Be's
mail system.
</p><p>
The mail implementation consists of three parts: The mail daemon, which
sends and receives mail; the mail portions of the Network Kit, which
provide interfaces for applications that want to create their own
mail-reading and mail- authoring applications; and BeMail, which is a
simple application for viewing and authoring mail messages.
</p><p>
The mail daemon is a background application, which checks for and sends
mail according to a schedule that the user can configure through the
E-Mail preferences application. The daemon gathers new pieces of mail
from the server and stores each as a record in the Be database. Fields
that are defined in the "E-mail" database table (see headers/net/E-mail.h
for the table description) are scanned for in the message and added to
the record. The message header and content are stored unmodified in their
entirety in this record as well. If the message contains MIME enclosures,
the enclosures are extracted and saved into the /boot/Enclosures
directory; references to the enclosures are also added to the database
record. Enclosures encoded using base 64 are decoded automatically.
</p><p>
Using the database to store mail allows the user to sort mail in a number
of ways using queries. For instance, I can set up a Browser query to show
me all mail sent to me from Jean-Louis by using the Browser's Find Panel
and specifying "Name contains JLG"; to view only the mail that has
arrived since yesterday, I can create a query with the Find Panel and
specify "When since yesterday." (Hint: Open the Queries icon in the dock
to sees all queries that have been made. You can rename and drag these
queries to the dock for quick reference.)
</p><p>
For developers who want to add e-mail capabilities to their applications,
the Network Kit's <code class="classname">BMailMessage</code> provides an interface to the "E-mail"
table, and to the mail daemon's message-sending functions. An example for
an application that does automatic registration is as follows:
</p><pre class="programlisting cpp">
#define <code class="constant">COMPANY</code> "reg@be.com"
#define <code class="constant">SUBJECT</code> "registration"
<span class="type">void</span> <code class="function">register</code>(<code class="parameter">user</code>, <code class="parameter">id</code>)
{
<code class="classname">BMailMessage</code>* <code class="varname">mail</code>;
<code class="varname">mail</code> = new <code class="classname">BMailMessage</code>(); <span class="comment">// construct mail object</span>
<code class="varname">mail</code>-&gt;<code class="methodname">AddField</code>(<code class="constant">B_MAIL_TO</code>, <code class="constant">COMPANY</code>, strlen(<code class="constant">COMPANY</code>));
<code class="varname">mail</code>-&gt;<code class="methodname">AddField</code>(<code class="constant">B_MAIL_SUBJECT</code>, <code class="constant">SUBJECT</code>, strlen(<code class="constant">SUBJECT</code>));
<code class="varname">mail</code>-&gt;<code class="methodname">AddField</code>(<code class="constant">B_MAIL_CONTENT</code>, <code class="parameter">user</code>, strlen(<code class="parameter">user</code>));
<code class="varname">mail</code>-&gt;<code class="methodname">AddField</code>(<code class="constant">B_MAIL_CONTENT</code>, <code class="parameter">id</code>, strlen(<code class="parameter">id</code>), <code class="constant">TRUE</code>);
<code class="varname">mail</code>-&gt;<code class="methodname">Send</code>();
delete <code class="varname">mail</code>;
}
</pre><p>
This constructs a new <code class="classname">BMailMessage</code>, adds three fields to the message (the
<code class="constant">TRUE</code> for the second <code class="constant">B_MAIL_CONTENT</code>
<code class="varname">AddField</code> is a flag to append the new
data to the existing data for this field type), and queues the message to
be sent the next time the mail daemon is scheduled. The message will be
removed from the database after it has been sent successfully. Options to
Send include sending the message immediately and saving the message after
being sent.
</p><p>
Note: The only requirement for sending mail is that there be a recipient.
This means the message must have a <code class="constant">B_MAIL_TO</code>,
<code class="constant">B_MAIL_CC</code>, or <code class="constant">B_MAIL_BCC</code>
field.
</p><p>
The last part of the e-mail package is the mail reader (users can pick
the reader they prefer with the E-mail preferences application). With
DR8, we ship a simple application, called BeMail, which reads, replies
to, forwards, and constructs e-mail. For developers who want to create
more interesting mail readers, the only requirement is that they assign
the document type 'mail' to their application's APPI resource.
</p><p>
To help simplify the process of writing more interesting mail readers,
we're making the source for BeMail available on the FTP site. BeMail is a
fairly complete BeApplication. It has examples of database access,
threading, messaging, multiple views, and includes classes from a number
of different kits.
</p><p>
The source is broken down as follows:
</p><div class="informaltable"><table border="0"><colgroup><col /><col /></colgroup><tbody><tr><td>Mail.cpp</td><td>Application and window objects</td></tr><tr><td>Header.cpp</td><td>TextControl views for header fields</td></tr><tr><td>Content.cpp</td><td>TextView for the message content</td></tr><tr><td>Enclosures.cpp</td><td>ListView for enclosures list</td></tr><tr><td>Signature.cpp</td><td>Code for creating and editing signatures</td></tr><tr><td>Status.cpp</td><td>Simple modal dialog with a TextControl</td></tr></tbody></table></div><p>
The size of the object is greater than 64K so you won't be able to build
it with the version of CodeWarrior that ships with the BeOS (you'll need
to buy the unlimited version from Metrowerks).
</p><p>
I haven't commented the source code particularly well, but according to
the MS Word grammar-checker, it's written at the eigth-grade level, so
you shouldn't have too much trouble going through it.
</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="News1-45"></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, two weeks on the job so far and things are looking up. Like so many
new employees, I wanted to hit the ground running. Bright eyed and bushy
tailed. The world is a nail, and I have a big hammer!
</p><p>
From the outside looking in, I didn't realize how much enthusiasm there
really is in the Be community. But it's not just enthusiasm, there are a
boat load of truly good-looking applications in the works, or already on
our door steps. I would like to share some of the gems that show up at
the ftp.be.com site, just in case you haven't already noticed. Caveats
about favoritism, and objectivity aside, I think these are really cool
and needed applications.
</p><p>
Title: Audio Elements<br />
Location: ftp.be.com/pub/contrib/audio/ae10.tgz<br />
Author: Attila Mezei (amezei@m18.datanet.hu)
</p><div class="blockquote"><table border="0" cellspacing="0" cellpadding="0" class="blockquote" summary="Block quote"><tr><td width="90%" valign="top"><p>
"Oh boy! That's what we had in mind when we created the Media Kit!"
</p></td><td width="5%" valign="top"> </td></tr><tr><td width="100%" colspan="2" align="right" valign="top">—</td></tr></table></div><p>
If you haven't had a look at this yet, it's a
definite must see. Basically, you have the ability to graphically layout
what are known as audio networks. That is, you can hook up things like a
microphone to a speaker by drawing a line between their graphical
representations. That's about the simplest operation you can do. You can
add filters of all sorts and mangle your sound in a million different
ways. And get this... add-ons are an integral part of its architecture.
Creating your own add-ons is relatively easy. You kick start the process
by selecting from a menu, filling in a little bit of information, and
generating a stub. Now you're left to actually write the code to do
whatever it is you want.
</p><p>
There's just too much in this little (currently free) package to mention.
All I can say is, if you're interested in fiddling about with audio on
the BeBox, then give this thing a try.
</p><p>
Title: Kftp<br />
Location: ftp.be.com/pub/contrib/network/Kftp-2b1.tgz<br />
Author: Laurent Pontier (pontier@efrei.fr)
</p><p>
The BeOS ships with a standard command-line version of the ftp client.
This is good enough for UNIX hacks who may not be exposed to anything
much more elegant, but Windows and Mac users will be much more satisfied
with something that has a nice graphical user interface. Kftp is such a
program. It presents a nice GUI ftp client. Transferring files is a
matter of click, click, that's it.
</p><p>
Titles: Viewer, Rotator, Sphere, Gouraud<br />
Location: ftp.be.com/pub/contrib/gfx/demos, viewers<br />
Author: Tinic Urou
</p><p>
These are little graphic applettes. They typically perform a single
function, and they all have the same general structure. But boy is this
author (and associates) prolific! They all include informative source
code (although not commented). Play with a couple of these and you might
think, "I didn't know I could do that." I find these truly inspirational,
and every time I run them I get giddy and want to stay up until the wee
hours of the morning trying to do something better. You'll find in them
ways of manipulating a BBitmap directly and using messaging to run a loop
without using Pulse().
</p><p>
SOME HINTS
</p><p>
Be provides the ftp.be.com site as a convenience to the Be community. It
provides a central location for developers to share their wares. The site
provides this convenience, but has some low-level maintenance associated
with it. The maintenance is primarily provided by the users that take
advantage it, but we also do some work.
</p><p>
On a daily basis we download all the things that are in the incoming
directory and put them onto a BeBox. Then we unpackage and run each one.
This is to ensure that we aren't posting pornography and that we can
gunzip the packages run them on most machines. Then we make an entry in
the whatsnew file so that people can see what's come in lately. If it can
be run, then we move it over to the contrib area. We do not perform any
virus checks, or check for maliciousness, so you should be aware of this
when running an executable that doesn't supply source code. Use at your
own risk.
</p><p>
When you post something to the ftp.be.com site, you should fill out the
Developer Support form in the Registered Developers Area. That way we at
least know that it's there. Even though we look every day, some things
come in that we don't have the ability to gunzip due to corruption, so
they stay in place because we don't know who sent it. Also, feel free to
add an entry for it to the BeWare section of the web site. The form to do
so is available in the Registered Developer Area.
</p><p>
When posting, include both a .tgz file and a .readme file. That way
everyone knows at a glance what the package includes without having to
download it.
</p><p>
LAST THOUGHTS
</p><p>
Spreading excitement is relatively easy to do on this platform. There is
so much fuel for the fire that all I have to do is point in the right
direction and jump up and down. But it still remains the case that
developers need some hard questions answered, and not just cheerleading.
Most of the time, good developers just need to be sent in the right
direction to find out how to best utilize the BeOS.
</p><p>
This week's tutorial focus is the source code for the BeMail client.
You'll find the package at:
</p><p>
ftp.be.com/pub/Samples/BeMail.tgz
</p><p>
This is the source code straight from Robert Polic, who wrote it. The
only change is that the code has been commented in some areas to explain
what's going on. It's all pretty straightforward and should be beneficial
to anyone looking how to do mail, access the database, do messaging, use
menus, and generally use a lot of GUI stuff.
</p><p>
Creating these tutorials is an evolutionary process. This code release is
typical of a first pass, the code is commented. Like the Gamestick
tutorial last week, more information will be available later. Speaking of
which, the Gamestick tutorial actually has a tutorial now. More
explanation of what is actually going on and how to use the code
effectively.
</p><p>
Enough said.
</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="DevProfile1-45"></a>Be Developer Talk: Mike R. Manzano, BitBrothers Development Group</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">Mike R.</span> <span class="surname">Manzano</span></span></div></div></div><p>
OK, so I'm sitting in this room full of people I don't know. I'm staring
at a monitor hooked up to this gaudy looking oversized lego building
block, and all I can think is, "The application he closed just crashed.
It must have crashed... It went away too quickly." There was no "please
wait while the application shuts down," no hourglass spinning around and
around, ad nauseum—just *POOF*. No app.
</p><p>
I know, it seems like a small triviality, but the speed really impressed
me. So much that I formed BitBrothers to code on it, and teamed up with
Janine Terrano, a wonderful marketing magician and visionary. Together we
hope to produce applications under the name Matrix Softworks, Inc. My
brother just bought his box last week instead of his first choice, a
Power Computing machine. I had nothing to do with it. Really, I swear.
</p><p>
Well, it's a few months later, the bevel on the front of the machine we
bought is a bit toned down from the original (nice neutral gray), but the
snap-off thingies sitting atop the bevel are still an enigma to me. A
friend mentioned that they may snap off so you can stack BeBoxes on top
of each other. Legos again. Go figure.
</p><p>
Thinking about it twice, I suppose that even if the case isn't supposed
to be a lego, the operating system certainly reminds me of one. Want a
window? Sure, just make one. No hidden agendas like "you have to set X
and make sure a function handle in Y is set to Z." Building apps on the
BeBox reminds me of those plastic models I use to build in high school,
only you don't have to follow the instructions, you don't need glue, and
the parts talk to each other.
</p><p>
It was precisely my endeavors in learning this new API that lead to the
idea of creating Pixel Magic, a paint program that will hopefully see the
light of day early next year.
</p><p>
At first I wasn't so sure I should do it. I mean, come on, a PAINT
program? Everyone and his evil stepmother's twin was probably working on
one. Why should I? Or, perhaps that's what everyone else was thinking. So
maybe I should do it.
</p><p>
So I am.
</p><p>
I don't want to give too much away before Christmas (that wouldn't be
much fun, would it?), so let me mention a few phrases describing PM that
you can subliminalize: Independent layer animation plug-in filters tools
alpha datatypes multiple undo cool awesome neat. You'll see more at the
January show, I'm sure.
</p><p>
As for other products on the horizon, I'm itching to put out a really
fast 3D two-player heart-pounding adrenaline- coming-out-of-your-ears
game, perhaps based on the 3D Kit. I've gotten pretty far on it already.
You run the application and a tilted 3D box appears on a black
background. Okay, so I've got some work to do...
</p><p>
Anyway, Be's support has been exemplary. Well, almost. I'm still confused
as to whether or not <code class="methodname">CopyBits()</code> is buggy or if it's my code. Dominic? The
ubiquitous bug list idea comes into mind. Idea: Put a developer-editable
and repliable bug list in the developer's area of the web site. Allaire
(http://www.allaire.com) has something like this and it
works wonders. Other than that, I'm not too critical about the state of
the BeBox and its software. I applaud Be for not going Microsoft on their
products. I plan to follow suit and release PM as an infant application.
I figure at the very least it will give me more time to spelunk around
the insides of the machine.
</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="Gassee1-45"></a>Are PCs Killing Workstations?</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>
The short answer is no. Not exactly, not today. But, for a while, PCs
have been encroaching on traditional workstation applications. Windows
NT, with an effective combination of publicity and reality, has made the
invasion more obvious. But it started long ago and, as a result of the
age of the subject, it's surrounded with a good amount of folklore.
</p><p>
For the longest of times, workstation makers and users have wondered at
the proliferation of PCs. How could people use these? They don't even
have a real operating system, their networking is primitive, they're slow
as molasses, with ridiculously small memories and screens. And yes, PCs
were primitive when compared to UNIX workstations. The PCs had other
advantages, such as being affordable, friendlier—meaning useable by a
much larger constituency. Just as important, their hardware and software
were more standardized, meaning more individuals and companies would
invest to develop programs and add-ons for them. But UNIX- based
workstations reigned in server and technical applications, such as
computer-aided design and software engineering.
</p><p>
Over time, seeing the success of PCs, workstation companies tried various
approaches to what is, from their perspective, the low end—desktop
publishing and other office automation applications. They never scored
any notable success. Sun executives used to be irritated at the number of
Macs in their offices; they were used to make those lovely overheads for
their meetings. Silicon Graphics tried several times to capture the high
end of multimedia PC applications and, so far (they're trying again),
failed to make any money at it.
</p><p>
There are two likely factors to this persistent lack of success. The
first is the fact that software, and more generally computer
architectures, just don't scale down. Software poured into a smaller
vessel than the one it was designed for doesn't work very well. The other
factor is the babelization of the UNIX world. Workstations sold in much
smaller numbers than PCs, less than a tenth, and hardware and software
were very fragmented, thus making third-party investments less
attractive. PCs, on the other hand, were becoming more powerful and
started attracting CAD/CAE software. I remember, when we started Be, we
picked inexpensive 486 PCs to do logic design and to route motherboards.
DOS wasn't a pretty operating system, but it loaded the application and
got out of the way. And if the motherboard routing wasn't always very
fast, it got done anyway and got done very cheaply.
</p><p>
With Windows NT, one of the objections to PCs in some demanding
applications disappears. Windows NT is a real operating system, big,
brawny, likes lots of hardware, complicated—but real. Monitors,
graphics accelerators, memory, and network connections are on par with
workstations—only less expensive.
</p><p>
Does this mean Sun, Silicon Graphics, HP, and Digital should cry uncle
and give in to the combined might of Intel and Windows NT? Of course not.
Silicon Graphics, for instance, is shooting for the high end. They bought
Cray Research and have a very prosperous business of multiprocessor
servers and virtual-reality engines. These high-end machines are now used
in TV broadcasts to make a virtual studio around an anchor standing or
sitting against a blue background.
</p><p>
The next development to watch will be Intel's efforts to re- architect
PCs. Today's processors are already poorly served by current memory and
I/O systems. The basic PC/AT design goes back to 1984. We should see the
PC organ bank we're so fond of get much better components with the
arrival of Intel's next generation of processors.
</p><p>
And what about us, Be, in this PC vs. workstation border conflict? Border
is the right word. We'd like to be as friendly and affordable as a good
personal computer. And, with the BeOS, we hope to provide the brains and
the muscle of a workstation, with an agile OS optimized for demanding,
high-bandwidth digital media applications. Someone even called us the
poor man's Silicon Graphics.
</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="BeDevTalk1-45"></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="id502636"></a>WEEK 6</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="id502642"></a>Subject: AES/EBU</h4></div><div xmlns:d="http://docbook.org/ns/docbook"><h5 xmlns="http://www.w3.org/1999/xhtml" class="subtitle">AKA: BeBox sound</h5></div></div></div><p>
More debate over whether Be should (1) provide professional digital
audio in/out as part of the baseline hardware, (2) build a custom
AES/EBU card for the sound professional, or (3) let third parties fill
this demand.
</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="id502662"></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="id502668"></a>Subject: How to interface GeekPort and apps</h4></div></div></div><p>
The actual speed of the <span class="trademark">GeekPort</span>™ compared to the hardware spec was
noted and lamented. Where's the bottleneck?
</p><p>
THE BE LINE: In a quick test of the BA2D object, it was found that
reading at full throttle was, indeed, significantly slower (about 100
microseconds per sample) than promised by the spec. We'll look at the
GeekPort classes and drivers to figure out where the time is going.
</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="id502693"></a>Subject: There is no OS UI like no OS UI.</h4></div><div xmlns:d="http://docbook.org/ns/docbook"><h5 xmlns="http://www.w3.org/1999/xhtml" class="subtitle">AKA: hot boot<br />
AKA: Shutdown/Sleep/Suspend
</h5></div></div></div><p>
Is rebooting too slow? If you've crashed and have to re- index (or,
worse, rebuild) the database, then rebooting can be painful. Also, more
talk about "hot booting," a process whereby a CPU/RAM image is saved
for a subsequent context- restoring boot.
</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="id502716"></a>Subject: Real Desktop?</h4></div><div xmlns:d="http://docbook.org/ns/docbook"><h5 xmlns="http://www.w3.org/1999/xhtml" class="subtitle">AKA: HEY! Is anyone listening?!</h5></div></div></div><p>
The desktop-as-virtual-directory debate spawned a few alternative
solutions, which led to the "HEY!" thread, in which a respondant
wondered aloud whether Be was taking note of the good ideas that pop up
in BeDevTalk. It was suggested that using the BugForm to report a
feature request is the best way to announce such ideas to Be.
</p><p>
THE BE LINE: By all means, send us ideas and suggestions in the form of
feature requests.
</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="id502741"></a>Subject: Plug-in thought</h4></div></div></div><p>
The global add-on discussion broke into two streams: The fragile base
class problem needs to be addressed, and data formats need to be easily
transformable. SOM was conceded to be the most reasonable (if not the
prettiest) solution for the former. For the latter, Jon Watte wrote in
to remind folks of his datatypes library.
</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="id502760"></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="id502766"></a>Subject: A Be Developers Conference?</h4></div><div xmlns:d="http://docbook.org/ns/docbook"><h5 xmlns="http://www.w3.org/1999/xhtml" class="subtitle">AKA: Be IRC Server</h5></div></div></div><p>
This thread discussed the means for (and desirability of) creating an
Internet Relay Chat conference about the BeBox. Some folks think an IRC
can't replace a face-to-face conference. The response: The two aren't
mutually exclusive. Amid the discussion, a Be IRC Server was announced.
[Ed. note: The dates for the Be Developer Kitchens are still set for
October 31 and November 12.
</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="id502788"></a>Subject: FileSystem Idea: Virtual databases.....</h4></div></div></div><p>
Should each user in the (promised) multi-user BeOS have his or her own
database? How about a personalized table? The security of such a
feature was questioned.
</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="id502802"></a>Subject: A 'filesystem' for tomorrow, modular software</h4></div></div></div><p>
In this thread, it was suggested that the "file system" as we know it
(hierarchical organization of files identified by name) be replaced by
a purely database representation. Folders become files, and files (one
assumes) become records. This would let you create live queries on
files (for example).
</p><p>
Also, it was suggested that the database become more relational: The
user (or programmer) should be able to create "joins" between tables.
</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="id502825"></a>Subject: Deleted files</h4></div></div></div><p>
The thread started with a proposal that deleted files be erased only as
disk space is needed, and then in chronological order (of deletion).
Thereafter, different methods and philosophies for garbage-collecting
deleted files were discussed.
</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="id502840"></a>Subject: Floppy</h4></div></div></div><p>
Should Be abandon the (admittedly outdated) 3 MB floppy? Why not move
to a Zip, MO, or other &gt;100 MB drive? Mostly everyone agreed that Zip
(or one of its brethren) is much better in theory, but the new drives
are slow, expensive, and rare. The one philosophical objection was that
all computers should have a "lowest common denominator" media. Floppies
is it.
</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="id502857"></a>Subject: Secret about box + AE</h4></div><div xmlns:d="http://docbook.org/ns/docbook"><h5 xmlns="http://www.w3.org/1999/xhtml" class="subtitle">AKA: AudioElements Oscilloscope</h5></div></div></div><p>
Who's the man in the Browser's Easter-egg About box? Somehow, this led
to general applause (and feature requests) for the recently up-loaded
AudioElements application. THE BE LINE: Chris Herborth correctly
identified the Easter bunny as Don Cherry (and his dog, Blue). As the
first prize winner, Chris gets to port Doom.
</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="id502878"></a>Subject: Does link() work?</h4></div></div></div><p>
Links are promised as part of the DR9 file system. This thread saw a
few closing arguments for the way links should be implemented, and
which types of links should be supported.
</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="id502893"></a>Subject: Mac emulator??? Hmm what about UAE?</h4></div></div></div><p>
This thread looked at Mac OS emulation from various angles: Does a
common CPU (i.e., the PPC) make emulation easier? What are the
trade-offs between emulation and running native code? Could a dual-PPC
run the BeOS on one processor and the Mac OS on the other?
</p></div></div></div></div><div id="footer"><hr /><div id="footerT">Prev: <a href="Issue1-44.html">Issue 1-44, October 9, 1996</a>  Up: <a href="volume1.html">Volume 1: 1995–1996</a>  Next: <a href="Issue1-46.html">Issue 1-46, October 23, 1996</a> </div><div id="footerB"><div id="footerBL"><a href="Issue1-44.html" title="Issue 1-44, October 9, 1996"><img src="./images/navigation/prev.png" alt="Prev" /></a> <a href="volume1.html" title="Volume 1: 1995–1996"><img src="./images/navigation/up.png" alt="Up" /></a> <a href="Issue1-46.html" title="Issue 1-46, October 23, 1996"><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>
Reference in New Issue View Git Blame Copy Permalink