amiga-news.de - Fortnightly Q&A's with Fleecy Moss

17.Aug.2003
AmigaWorld (ANF) Fortnightly Q&A's with Fleecy Moss - episode 17
The English online magazine AmigaWorld has published episode 17 of the regular questions and answers session with Fleecy Moss, CTO at AMIGA, Inc. (Update 2012-03-15, cg: as the original document is no longer available, the following content was moved into our database):

1) alx: You have mentioned that OS5 should include "Orthogonal Persistence". I roughly understand that this means that you don't need to explicitly "save" a file, but can you give us a rough idea of what it is, how it would appear to the user, and how it would impact AmigaOS in particular?

Fleecy: First of all, here is a decent definition of Orthogonal Persistence (OP) which I googled.

"In geometry, orthogonal means "involving right angles" (from Greek ortho, meaning right, and gon meaning angled). The term has been extended to general use, meaning the characteristic of being independent (relative to something else). It also can mean: non-redundant, non-overlapping, or irrelevant. In computer terminology, something - such as a programming language or a data object - is orthogonal if it can be used without consideration as to how its use will affect something else. In itself, a programming language is orthogonal if its features can be used without thinking about how that usage will affect other features. Pascal is sometimes considered to be an orthogonal language, while C++ is considered to be a non-orthogonal language.

Features of a program that is compatible with its own earlier versions - this is called backward compatible - have an orthogonal relationship with the features of the earlier version, because they are mutually independent; you don't have to worry about how the use of one version's features will cause an unintended effect because of an interaction with those of the other version. Both the features and the programs can be said to be mutually orthogonal.

The length of time data is kept in storage in a computer system is known as its persistence. Orthogonal persistence is the quality of a programming system that allows a programmer to treat data similarly without regard to the length of time the data is kept in storage. Data is stored for varying lengths of time; some is stored very briefly and some is stored relatively permanently. Frequently, a programmer must use different approaches and separate coding to access data depending on whether it is stored for a long time or a short time. Using a programming system with orthogonal data persistence allows the programmer to treat data the same way regardless of its persistence characteristic, saving programming time and making it easier to enforce referential integrity (a type of constraint applied to ensure correct data validity)."

To a user, as you say, the biggest difference is that there is no distinction between objects being used at a specific time and those that are stored on a disk and which have to be loaded and saved. An object just 'is' and you access it directly using just one method. This affects the whole model of data usage, whether for a user or for a developer. You just access the object and it is there.

For AG2, this will mean that the user doesn't consider the individual data object 'as is', but will make use of semantic organisation - embedding the object itself into multiple relationships which can use any sort of paradigm, from explicit sets (a set in which the user puts an object because they want it there) to implicit sets (the set of all png files, for example). Such a system can simply build a hierarchical container relationship, which would manifest itself as the existing file system model, but to only use it for this would be a profound waste.

It sounds very different but it is actually a far more natural activity that the system existing computers use, which is very closely tied to hardware restrictions. In fact you are already using a similar system almost everyday - the Internet. An HTML page is a container for all sorts of data objects and you click on them to access them. It is a limited and controlled environment and uses a very simplistic space model but it provides a good example.

2) Crumb: When will we have an updated datatype/codec system? The level of optimization of Action/Moovid is quite good... but making a codec system we would see Premiere-like aplications developed more easily.

Fleecy: The entire datatypes system is up for an AG2 review for AmigaOS4.1. There is no point in implementing the new system until the new graphics and audio services are in place anyway since we'd have to reimplement all the codecs to take advantage of the new services.

3) Crumb: What about DVD Write support? There's no software for writting DVDs yet :-/

Fleecy: That's probably the only thing we won't be fitting into AmigaOS4.0 but it is pencilled in for AmigaOS4.1.

4) CanGuy: Apple is apparently replacing AppleTalk with Rendezvous. Has Amiga looked into using Apple's Rendezvous (or similar technologies like the IETF's in-development Zeroconf technolgy or jrendezvous, an open-souce implementation of the Rendezvous protocol) as an alternative to Envoy?

Fleecy: The "Rendezvous" protocol is a set of procedures for finding local services (printing, file sharing, etc.) offered in the local network and for assigning IP addresses to hosts. It's just that and does not imply any sort of file sharing or printing protocol. The Zeroconf protocol(s) are still in flux, but Apple took the plunge to deploy (and to publish MacOS X sample source code for the implementation) a solution. Hardly anybody else seems to be using it so far. And it may be wise to wait a little longer for information to trickle in how well it works and for other implementations to become available and to mature (the Apple supplied code is rather MacOS X specific).

For the time being, the TCP/IP stack to ship with AmigaOS4 will support automatic address assignment using one of the protocols of the Zeroconf specification. But that's it so far.

5) Asemoon: What do you consider the AmigaDE's most promising selling point or addition compared to standard Intent2 technology?

Fleecy: The content centric elements. Intent2 is a product that is focused heavily on the feedback the Tao-Group have received from their customers. These are chiefly OEMs and IHVS who are after embedded solutions to drive their hardware products. AmigaDE is focused on supplying content above that layer, and so we have not only a highly flexible packing, distribution and deployment solution but also services for content developers which free them from having to do common tasks - a good example being Astorage and AmiDB.

6) Jose: Do you sitll have the rights to the tick (or checkmark, as somepeople call it) logo? And the Amiga word in italic as it's stamped on the case of our Classic Amigas?

Fleecy: I believe so but I haven't checked. It's not within my domain.

7) Morka: Will be in OS4 something like Windows update or Symantec LiveUpdate?

Fleecy: There is a fundamental issue when considering an automatic maintenance system, and that is how do we have both a 100% knowable system and also allow power users to tinker? An AMS needs to assume that it has complete control of the maintenance domain (or at least that there is a formal way of identifying all changes that may have been made to its last knowable image) otherwise it will base its maintenance on knowledge that may just be completely wrong. A good example of this is the Windows architecture. Changes made through formal mechanisms are reflected in the registry but users can still move into the actual filing system itself and make changes which may/may not be reflected in the registry.

We are already looking at such a system but it will initially be for closed solutions - auto updates for Smartphones, STBS, Games consoles and the like. We have to look at whether power users would accept such control or else implement some sort of transaction logging/journaling and lock down all possible points of change.

8) mjohnson: Is Amiga reaching out to digital camera developers and producers of film scanners (Canon, Nikon, Minolta, Fuji, Kodak, Olympus), to enable the availability of drivers and custom viewer/raw-file software for these products for the A1/OS4? (or will it come for OS5) Also, will (digital image)-card readers be usable through OS4 without too much fuss?

Fleecy: The answer here is the same as for any third party hardware that requires drivers. We have approached and been approached by many of the big players but their answer is almost always the same - we'll support you when you have a market base that makes commercial sense for us.

Luckily there are many standards in play, and with the new datatypes system, there will be a good foundation for third parties to step in and offer solutions. Once we can get the market base to an attractive size then we will revisit these companies.

9) alx: A while ago, Amiga published a timeplan on their website for what features will be in OS4.x and 5. Will there be a new one released to reflect, for instance, the features of OS4.2 that are now in OS4.0?

Fleecy: As with any project plan, things change so yes, we will release a new snapshot of where we are going but it won't be until after AmigaOS4.0 is released. Given the complexity and number of threads in the AmigaOS4.0 development, it is always the case that some take a shorter time, some take a longer time, and with that, some of the developers decided that they'll start work on things pencilled in for AmigaOS4.1, except that they are very quick and are finished before AmigaOS4.0 is ready.

We may just release the overall feature plan from AmigaOS4.0 to AmigaOS5.0 rather than trying to release individual products that may constantly change.

10) alx: I understand that in one of the later 4.x OSes, the current implementation of workbench, icons etc will be replaced. Few other desktop operating systems that I can think of have had this chance for a fresh start in a long time - what features will you be able to introduce that will make the Amiga's implementation superior to other OSes?

Fleecy: The interactive environment obviously sits on top of a variety of foundation services - graphics, audio, events, composition etc and so there is little point in changing large parts of the AG1 system when they will have to be reimplemented when the AG2 foundations services are implemented.

You are correct though that we have a chance to start from scratch with the entire interactive environment and we are deep into that process at the moment, concentrating on developing a much better workflow model. To be honest, this is far more important that 32 bit icons and skinnable frames - these things are just eye candy and relatively simple to implement, although they rarely make an environment better to use. There are many examples of gorgeous looking interfaces and applications, particularly games where the project managers have completely missed the point - an interface is for doing things with, not staring at. Looks are important but secondary and as always with Amiga, we are seeking to advance the total experience, not a specific (and most obvious) part of it.

We are intending to really push the boundaries here, and some of the concepts and models need to go through IP assessment before they are made publicly so don't be surprised if you don't hear about it for some time, and then it is suddenly upon you. I'm not trying to dodge the question but interface design has been stuck for the last decade and we think we have some ideas that could break through that deadlock.We aren't about to give them away.

(Copyright © 2003 Amigaworld.net. All rights reserved.
Originally available at http://amigaworld.net/modules/fleecymoss/index.php?cat_id=18
You may freely redistribute this article, providing that a URL is provided to the original source,
and the copyright notices remain intact) (nba) (Translation: cb)

[News message: 17. Aug. 2003, 23:46] [Comments: 0]
[Send via e-mail] [Print version] [ASCII version]

< Next message

Prior message >