#a4000 Impressions
35 messages in this thread
Thanks. About DataTypes, generally it's a whole new way of handling data
under the Amiga OS. Being supported by CBM, it's in at the "root" level,
so I think it'll be well supported and widespread. I've included a general
discussion from the CBM autodocs – no specifics, just the description of
what it is supposed to do. Unfortunately, the genesis of the discussion,
being technical docs, makes this come across as technobabble more than
anything else, unless you read it fairly carefully. My conclusion is that
this new capability will add a great deal of data-handling power to
applications that choose to use it – and the user will benefit. When we,
for instance, add a datatype for a particular image type, then an owner of
GVP software (assuming they support datatypes) could also load or save
that image type. Synergy is the key here.
Here's what CBM has to say:
Purpose
——-
The datatypes.library provides transparent data handling abilities to
applications. Application developers can register their data format with
datatypes.library and provide a class library for handling their data
within other applications.
Object Oriented
—————
datatypes.library implementation is object oriented, using the boopsi
functions of Intuition. Each data class is implemented as a shared system
library.
Embedded Objects
—————-
datatypes.library provides the ability to embed different object types
within an application. For example, an application can embed an picture
object or even an AmigaGuide document browser within their application's
window. Objects can also be embedded within other objects.
Gadget-like
———–
Embedded objects are actually boopsi gadgets. That means that input
handling is done on Intuition's task. Time intensive operations, such as
layout when the window size changes, are off-loaded to a sub-process.
Printing, clipboard operations, file read/write are also off-loaded to a
separate process on an as-needed basis.
<continued>
Ben:
Wow. While the specifics are beyond me, it appears as if the
Datatypes.library will allow a tremendous amount of interaction among
programs by developers smart enough to incorporate datatypes.library
support in their programs. I wonder if the datatypes.library is included
in AmigaDos 2.1 or if it is 3.0 specific?
With everything that the 4000 has going for it, I am personally very
anxious to see the what CBM will come up with as the next step forward
(and I hope that is _sooner_ than later!).
Michael,
I _think_ that datatypes starts with 3.0 (if you've heard of the new
'Multiview' program, that's what it uses… which lets it display ilbms,
ascii text, anims and play 8svx sampled sounds (as well as anything else
that gets developed as a library for it)).
I've been playing around with it since this morning… and in the
simplest cases, you merely open a window, call a routine passing it a
filename and it returns to you a gadget that you attach to your window. If
the filename were of an 8svx sampled sound, for example, you'd get a button
(with imagery) that, when clicked on would play the sound for you.
This is neat stuff, indeed…
– Keith
cool
Ahhh, is this datatypes a feature of 3.0 only and not 2.1? Would this
feature be usable on say a 2000 running the 3.0 OS? I thought the only
diffs in 2.1 and 3.0 where to do with the new graphics modes of the AGA
chips…Any more features of 3.0 that could benefit ECS machines? Should
we pester C= to release 3.0 for `the rest of us'?
…Steve
On AutoPilot! (at last)
Steve,
I'm still not _sure_, but others have said it is 3.0 (and I tend to
think the same thing). Yes, this would be usable on a 2000 running 3.0
(and was one of the things I mentioned a while back in a related thread).
There are some other (if not less obvious) features of 3.0 that would
benefit non-AGA machines… I'm sure that they will be releasing it for
non-AGA machines once they feel comfortable with it in that enviroment.
Remember that 2.0 was first only available on 3000s, then later came out
for the rest of the systems.
– Keith
Keith,
I don't think 3.0 can run on a 2000 because the ROM is 32bits wide and
the 2.0 rom is 16bits wide. How could we fit a 3.0 ROM in a 2000 and if
we can't how can we run 3.0?
Peter
Live from New York on Autopilot
They'd have to make a 2000 version of the 3.0 ROM. ie.. just like the
2.0 ROM for the 3000 won't work in a 2000.
– Keith
There are people running 3.0 on there 2000's by softbooting it (ROM) into
RAM.
-Jonathan
It would be usable on a 2000 running 3.0, or for that matter a 1000
running 3.0; Yes, you should pester C=. Yes, there are other features that
could benefit ECS, and earlier, machines – like the ability to edit your
busy pointer, etc.
–Ben
…via AutoPilot
This is true. Critical parts of the MultiView/DataTypes operation are
built into the 3.0 OS. Apparently they do not graft into 2.04 via
setfunction() all that well.
{@_@}
Datatypes are 3.0-specific; it's one of the reasons I'd like to see 3.0
for the other machines – though there ARE more reasons. :^)
–Ben
…via AutoPilot
Well, then forget anything I said about DATATYPES sounding neat. If it's
3.0 only, and 3.0 is not supposed to be used on any non-AGA machine, what
developer in their right mind will support it until until the majority of
Amiga users can use it?
I agree – it'll be used by PD types, who have no stake in anything but
being cool.
I think 3.0 needs to be released. We'll see what happens.
–Ben
…via AutoPilot
Sounds like fun. So when I write InterChange converters as class
libraries, then everyone will be able^O
del
Deleted
Sounds like fun. I eagerly await what CBM has to say about this. Do you
know who in CBM is working on this?
After seeing how Windows and the Mac reacted to embedding technology, I'm
still ambivalent about it, although I do think it's going to take over the
world. It offers a two-edged sword to developers, I think… on one hand,
smaller companies will get the opportunity to make embedders for larger
products. On the other, companies like Microsoft will become more
successful because their "products" become reduced to nothing more than
glorified hosts for embedding.
It raises a lot of questions. For example, if someone hands out a document
that should contain embedded fonts, does the other person get the right to
use that font? If someone's document requires a player, do they get the
player, too? Will consumers regard players and embedders as real software,
and be more likely to pirate them when they don't realize?
So when I write InterChange converters as class libraries, then everyone
will be able to pirate them and use them in other applications, right,
because stealing a library isn't really like stealing software, huh? 🙂
Don't you think it would be more likely for someone to pirate ImageMaster
and its neat new datatypes loaders and savers, if they owned a competing
product that would use them? What if Art Dept could suddenly use all your
loaders and savers? Or if I made a TIO converter for the Toaster that
could use all your existing PI modules? Yeah, pirates is pirates and
they'll steal anything… but interoperability makes it so much easier and
more "productive".
You have some good points, and in fact, taken to the extremes, datatype
libraries for file-conversions would make me a bit nervous if that were my
'business' too <grin>.
On the other hand, if I owned AdPro, I'd more likely buy ImageMaster if
I knew that both programs could use the same file-formats… just cuts out
the middle-man (unfortunately, InterChange, in (not neccesarily) this
case).
Ignoring pirates (hard to say if there be 'more' of them with regard to
libraries vs programs), there will now be a potential market for new
datatypes packages.
– Keith
But my deeper point is, it's obvious to see how something straightforward
like file format translation would be affected both positively and
negatively by completely open standard mechanisms for interchange, but it's
also possible that almost everything else will become "components" that
interact and play their information in essentially "gadgets" in the
terminology of datatypes, or "containers" in terms of Windows OLE. Will
these things called "applications" disappear, replaced by applications that
just manage containers and talk to behind-the-scenes engines?
Let's say you make a word processor. How many text editing datatype
libraries will someone need? Will CBM provide a minimal one? What could
you do to make your text class library appealing enough to sell as a
product? Will people be willing to buy yours if two other companies are
giving text libraries away with their application, because they didn't want
to license yours, and CBM's wasn't smart enough?
As I said, I'm ambivalent about this trend. It might mean the end of
software development as we know it; or at least the "fun" parts that we do
now. Or it might simply transform and evolve our present-day concepts.
I understand your concerns and share them to (probably) a lessor degree.
I see both up and down sides to this new trend, but tend to lean (out of
neccesity ?) towards your last proposal… that it might simply transform
and evolve our present-day concepts.
We've always had a great deal of flexability in the Amiga from both a
User's and Programmer's view (everything being treated like a device, so
you can "1> copy filename prt:" for example). This flexability keeps
expanding with more/better shared-libraries (with standard requesters,
freeing the programmer from having to 'invent' one) then ARexx, letting
users connect applications together in ways the programmer never thought
of.
I don't think datatypes will be capable in and of themselves to present
complex application-level concepts in a usable fasion… while some
programs may indeed just be containers for them (like Multiview), there
will still be plenty of room (programming-wise) for the nuts-n-bolts stuff
that makes one application different from the next.
You mentioned the end of the "fun" parts that we do now… I guess
that's pretty much a subjective issue. Personally, the area of programming
that I enjoy most is in the 'presentation' of the application (or in the
'way' something is implemented, including, but not limmited to the UI). As
an example, I have a great interest in 3d solid-modeling, and have been
having fun developing a 3-space engine (all the matrix operations, distance
calculations etc.) but what I'd _really_ prefer is to have a library of
those routines already available, so I could concentrate on "doing neat
things with it".
Anyway, time will tell I guess… for the time-being, I'm spending my
time thinking of the possibilities datatypes brings to the table. I'll
either think of something to cook, or get out of the kitchen <grin>.
– Keith
"…it might simply transform and evolve our present-day concepts."
John, it sounds like the datatypes.library implementation is the 'sleeper'
of the new OS, and you and Ben have correctly identified it as something
that s/w developers will have to come to terms with. This is exciting
stuff… you s/w developers will be shaping how Amiga s/w is constructed,
and distributed!
Am I wrong in seeing the datatypes.library 'stuff' as making Object
Oriented programming the norm of future Amiga s/w development?
It all depends on how they implemented it, as to whether we can call it
OOP. I'm sure there will be a way to get to it from straight C. These are
all just buzzwords anyways. 🙂
As for being useful… well, we'll see. Some things are standardizable,
others are not. In markets where the slightest improvement gives one
company a marketing edge over another, you can bet the standard is a
least-common-denominator and it won't do everything you want it to do. For
something like present-day bitmap images, it's easy to make a standard data
format. But a word processor? Maybe not. This all comes around to
device-independent graphics, too. On the Mac and PC, very often these
embedded objects are handled as the system's native structured graphic
format, in Windows it's the "metafile" and on the Mac it's "QuickDraw."
Except we don't have that on the Amiga yet…
Hey… take away my buzzwords, and I won't be able to understand ANYTHING
you guys talk about! 🙂
"Except we don't have that on the Amiga yet…" well, I've heard an awful
lot of people complain about that during the past year… standards may
mean compromise, but on the other hand, there's a lot to be said for
compatability.
I think it's simple – when you make a datatype, you are saying "here" to
everyone. So, your motivation needs to be other than the datatype itself.
I'm not one to particularly feel that file formats are something that
_should_ be a valuable commodity – It has become that way because there
are too many, and there wasn't anything LIKE datatypes around. I'd just as
soon see it end; I'd be perfectly happy to remove all file loading from
Imagemaster and depend on system resources – we can spend our time more
productively working on high level functions than we can on file formats
(blech!).
That's how *I* feel about it; so odds are, we'll do datatypes if it's
practical to do so (it won't be, while it's a 3.0 feature and 3.0 is
isolated to the 4000).
Others may feel differently; for me, all the time we spent on file formats
was pretty much forced on us – we'd be just as happy to get out of it.
Imagemaster is the best image manipulation program out there; I believe we
can keep it that way, even if all programs could load formats equally.
You have to look beyond the obvious here – the synergy of "all programs"
being able to load "all formats" and save 'em too, is more powerful and
useful than anything we, or you, could present. That's worth a sacrifice,
because anytime the marketplace, the Amiga community, powers-up in a
*really* significant way, the vast majority of developers will benefit as
we get to service that more powerful, more sophisticated community.
–Ben
…via AutoPilot
Ben,
I agree, point-by-point with your comments.. well stated.
– Keith
thanks.
–Ben
…via AutoPilot
. <applause>
gee… grin>
–Ben
…via AutoPilot
But your customers won't stop demanding file compatibility. If your
competitors wait for you to complete a datatype library for a format that
they don't want to do, you may as well have written them a check. And like
many other synergistic pieces of software, it gets harder and harder to
test, when someone else's software could be mucking up the system. This is
a silghtly different situation than simple multitasking, because now your
customers might be relying on something written by another company that
crashes when *your* screen is to the front.
Sure, our customers wouldn't stop demanding file compatibility; and yes,
if we do a datatypes library, we've added power to other applications,
some of which will no doubt be our competitors. That's ok with me, because
as I said, as the community powers up, the developers, us, will benefit by
servicing that community. This is a sure-fire way to encourage growth. As
for other software "mucking up", IE bad datatypes libs, it's just like
printer drivers, fonts, serial devices, etc – it's going to happen, but
the bad ones show up quickly and get weeded out; it's ok.
FYI, many of our customers have constantly been relying on something that
crashes when our screen is to the front – it's called AmigaDOS 1.3 –
remember that particularly buggy piece of software, unfixed for ages? :^)
I say that should datatypes go into common use, that file formats will NOT
be a viable money maker, although I believe that if a company produces
them regularly that the reputation of the company will benefit, an
intangable but nonetheless real positive note for a business.
I believe that it's a benefit, a large one – like most big changes, it
won't be without pain, but I see it as a win overall by a large margin.
–Ben
…via AutoPilot
Who said file format conversion was a "money maker" right now? 🙂 If
nothing else, it's been a lot of time for your company. It's been part of
your product's appeal to many people. And ASDG has been making, oh, I'd
guess a third of their money selling add-on converters for "high-end"
formats.
Is there anything from CBM yet as to specifics about datatype libraries?
Yes – complete Autodocs are available with the 3.0 devkit.
–Ben
…via AutoPilot
I don't think we've received the 3.0 devkit; is this a special-order item,
or do you get one when you buy an A4000 from them?
It's not special-order; it came in the mail, just as all the other dev
stuff does. We're" Commercial Developers" in CBM parlance; it may be that
the "Certified Developers" receive different tools.
–Ben
…via AutoPilot
Re fonts I would say not. After all this is the way it works with
PostScript as well, unless the font is embedded in the PostScript file.
(Which may be an illegal violation of CopyRight. It IS in a fuzzy area,
though.)
{@_@}