| |
LU1BUV > PSBBS 19.07.96 12:10l 106 Lines 5128 Bytes #-10165 (0) @ WW
BID : 39786-LU1BUV
Read: DO3SMK GUEST
Subj: BBS Effort
Path: DB0AAB<DB0KCP<DB0CZ<HB9EAS<HB9OS<HB9H<HB9OK<IW2FPO<IK2UUB<I2REO<
IW2KTL<IK2FMJ<IW4CNQ<IW4CQH<I4UJB<EA6PZ<EB3DQV<LU1BUV
Sent: 960716/0108 @:LU1BUV.#ADR.BA.ARG.SOAM #:99999 [Pkt2Tst V1.2ß]
[¯¯¯ TST HOST v1.42b, Local time: Mon Jul 15 21:30:15 1996 ®®®]
Hi out there,
I've been following with attention the initial scribbles of what might be
the next generation of BBS systems, lot's of ideas (one better than the
next around).
I've some opinions, both as a sysop and as a profesional developer, on
the subject.
I wonder to which extent we should continue to develop what seems to be
a proprietary approach for our messaging architecture. No doubts it was
the right decision time ago, not quite sure now.
There are needs in our activity that has no paralell in other networks
or uses; however we've to deal with the solution of common aspects such
as the presentation, message storing, etc. that are fairly common to any
message architecture. Wasting, in my humble opinion, huge amounts of
precious (and scarce) skilled efforts on that.
What happens if we concentrate instead into the development of some
sophisticated, even intelligent, layer between our unique hardware
and the vast number of packages available as freeware, shareware and
even commercial software for mail & news handling/routing, file transfer
and some zillion other applications.
I'm not meaning to reuse JNOS or something like that, but to develop
'something' that looks to packages such as Eudora, Netscape, IPhone or
many others as a 'TCP Stream' hidding the fact that data is actually
been moved thru an AX.25 non-TCP connection (we could even paralell
or emulate connection oriented and connection less links).
It's not efficient, isn't it? Ok, people out there are investing money
big time (several orders of magnitude what we represent as a market)
and perhaps we could move them inventing (supposing we'll invent) something
10-20% more efficient.... I don't think so.
There are already solutions to most of our needs out there, what doesn't
actually fit exactly I'm sure could be solved on the 'glue' layer (then
the 'intelligent' approach).
And even if we discover that we could need an application so specific and
so unique that there is nothing appropriate around we could even benefit
from the huge support from development toolkits and end user tools that
are available.
It's that crazy to think in something like Java having some meaning in
our network? Sure it is at 1K2, even perhaps at 9K6, but those speeds
eventually will improve if there is some drive for it beyond mail.
What about IPhone or IVideo? Avatars? Virtual reality? Agents?
The approach could pull of from our back some crucial decisions, such as
the operating system, the message architecture, the flavors of the
user interface and so on.... just use the one better fit your taste,
needs or possibility as long as it support some sort of TCP stack.
Transportation of a reasonable sized driver (no matter how big it could
result) across different platforms would be certainly easier than to move
a whole megapackage and certainly would be less risky than to select a
given platform and face a dead end if it found no acceptance on the
sysop community.
Even, if WE COULD grab something like Java at work in our networks, we
could think in some sort of platform independency.
I couldn't not think on anything so special, even with our current
proprietary approach to look at things, that couldn't be appropriately
emulated either at the layer aforementioned or perhaps with the aid of
a couple of specialized servers.
The released resources saved to be wasted on the 'non-essential' modules
(the ones that we could grab from around) could be invested into the
improvement of our routing scheme, or some really sound broadcast
forward protocol (how long it would take to stop the huge tax of B/W
we're doing forwarding N times the same bulletin within N nodes on a closed
area?), and some other application that I'm afraid I couldn't even foresee
right now.
To end, three additional benefits I could foresee right now.
A complete, all featured, intelligent 'driver' with all the companion
servers required could take months to develop assuming the brighest minds
in our network put hands at work; however, a stripped down (hardwired)
version for evaluation purposes (very inefficient in many respects) I
think could be written in weeks, even days. If something hidden are there
that sunks the concept then we could reorient ourselves in other direction.
Second; we could, almost instantly, give a try on our backbones of any
novel technology that some crazy non-amateur dares to imagine without
our consent.
Third; perhaps the better reason in my opinion, anything novel we could
develop or imagine (and we've a century in our backs creating crazy things)
will find it's way to non-amateur uses rather quickly. Perhaps, it could
even lead to close the huge technological gap (at least in some partial
areas) radioamateur technology is developing with the 'out_there_everyday_
use' technology.
Have fun, Pedro.
-----------------------------------------------------------------------------
Pedro E. Colla - Adrogue - Buenos Aires - Argentina [GF05TE]
Packet: LU1BUV@LU1BUV.#ADR.BA.ARG.SOAM Internet: colla@pec.pccp.com.ar
Read previous mail | Read next mail
| |
