Epoc32 file formats
Jesper Zuschlag
regular basis both
in the comp.sys.psion.* new groups and in the epoc world news groups and
each time
psion/symbian has stubbornly refuse to publish any information at all
claiming that there exist
no such documentation and even if such documentation did exist then they
would not disclose
it to the general public as epoc32 developer should use the standard
stream store "API" and
not access the data directly on the file level.
Although I fully support the idea of only accessing file-based data
trough a standard API in
epoc applications (which often results in much more robust applications)
I find the resulting
policy of withholding all documentation on file formats a very serious
problem for many
developers of epoc32 related products myself included and I believe it
is done for the wrong
reasons.
Firstly I do not believe that symbian do not have any documentation on
the internal structure
of epoc files even though it is more complex than ordinary file formats.
if the opposite should
be to case then it would be a evidence of an exceptional lack of system
documentation by
Symbian, something I can not believe to be the case. However I suspect
that the real reason
behind this secrecy is that Symbian for some reason tries to guard the
details about the internal
functionality of epoc32.
Secondly I find that the lack of documentation on file formats severely
restricts the possibilities
of 3rd-party developers for producing products like file conversion
tools for alternative platforms
(like RISC OS, BeOS, Linux etc) that symbian do not have the resources
nor the interest in
supporting. The situation today dictates that the users of epoc32
devices has access to a Windows
or MacOS based computers in order to get the full benefit of their
epoc32 devices. Owners of
alternative platforms (a small but not insignificant minority) can not
hope for much more than to get
their files transferred onto their desktop computer, whereas any file
conversion for further work on
their documents is out of the question, something that is a great
annoyance for many epoc32 users.
Another area where disclosure of file formats would benefit is
development tools. Today, the only
development tools available are the official Symbian SDK's and the
build-in OPL translator/
interpreter. If for instance the format of exe/lib/dll files and details
about how they are functioning
internally were made public then it would possible for 3rd-party
developers to produce new
development tools thus giving other developers more options and
hopefully resulting in more
developers developing for the epoc32 platform and thus better
applications for the end user. An
example of such a development tool could be a java compiler producing
native epoc32 application
from a java source or an OPL translator/interpreter for other
desktop-based platforms, so that
OPL-programmer would not be forced to write their programs directly on
their epoc32 device -
an idea that I personally have been toying with for some time and that
is only possible if the format
of OPO/OPA files is known (although the work of Mike Rudin helps a lot,
it is not complete and so
it would not be possible to guarantee 100% comparability with epoc32
OPL, sigh!)
I that Symbian would reconsider their position on this matter and if
that is not the case then that the
community of eproc32 users and developers would join together in a
demand for Symbian to abandon
their current policy and release the much needed documentation on epoc32
file formats like it is the
case with most other operating system vendors.
Jesper Zuschlag
Ajai Khattri
<jes...@zuschlag.dk> wrote:
>However I suspect
>that the real reason
>behind this secrecy is that Symbian for some reason tries to guard the
>details about the internal
>functionality of epoc32.
Yes because in a future release of a new ROM or new machine the
internal structure of a file may change. And hence using the API only
makes perfect sense so your program will not break on every future
machine released.
>Secondly I find that the lack of documentation on file formats severely
>restricts the possibilities
>of 3rd-party developers for producing products like file conversion
>tools for alternative platforms
>(like RISC OS, BeOS, Linux etc) that symbian do not have the resources
>nor the interest in
>supporting.
Sounds like sound business sense to me to target fewer more common
platforms rather than every esoteric system under the sun.
> The situation today dictates that the users of epoc32
>devices has access to a Windows
Well yeah - with 90% desktop penetration that makes sense too.
>their documents is out of the question, something that is a great
>annoyance for many epoc32 users.
I suspect "most" users means your average person in the street which
means they will most probably have a PC. A few vocal users making
comments here cannot be taken to mean the majority.
>interpreter. If for instance the format of exe/lib/dll files and details
>about how they are functioning
>internally were made public then it would possible for 3rd-party
>developers to produce new
>development tools thus giving other developers more options and
>hopefully resulting in more
The Java SDK is coming... with OPL and C++ this represents more
development options than most other handhelds.
>example of such a development tool could be a java compiler producing
>native epoc32 application
See above.
--
Aj. (aj...@ibm.net)
Keld Laursen
Ajai Khattri skrev i meddelelsen <372fe4f2...@news.compuserve.com>...
>On Thu, 22 Apr 1999 23:50:06 +0200, Jesper Zuschlag
><jes...@zuschlag.dk> wrote:
>
>>However I suspect
>>that the real reason
>>behind this secrecy is that Symbian for some reason tries to guard the
>>details about the internal
>>functionality of epoc32.
>
>Yes because in a future release of a new ROM or new machine the
>internal structure of a file may change. And hence using the API only
>makes perfect sense so your program will not break on every future
>machine released.
In the S3 days, you had documentation for the various file formats. This
didn't dissuade Psion from changing e.g. the World database format, thus
making old version converters/files non-functional.
If you have a new ROM, and old API's, will these be able to read the *new*
formats - not!
I'm not sure I can see the difference.
AFAICS, if you have a stream store, the various parts (objects) in the store
must be identifiable in order for some API to read them.
Or are we dealing in miracles here?
What I see as the biggest hurdle is that any single converter more or less
has to know about all the possible objects in order to be able to safely
read any stream-store.
Sorry, I know this has been haggled over before, but i just couldn't resist.
I will immediately crawl back under my rock :-)
Best regards,
Keld Laursen
Jesper Zuschlag
Ajai Khattri wrote:
> Yes because in a future release of a new ROM or new machine the
> internal structure of a file may change. And hence using the API only
> makes perfect sense so your program will not break on every future
> machine released.
And then all your old files needs to be converted - no that is not the
reason.
If Symbian later would alter some of the file formats if will properly be by
extending the current formats. The reason that working through a well defined
API makes sense is to ensure the integrity of the files.
> Sounds like sound business sense to me to target fewer more common
> platforms rather than every esoteric system under the sun.
Yes I agree (surprised?) It makes perfectly sense for Symbian to concentrate
their effort to as few platforms as possible, but that should not be a reason
for preventing that other 3rd-party developers can producing connectivity
and conversion tools for alternative platforms.
> > The situation today dictates that the users of epoc32
> >devices has access to a Windows
>
> Well yeah - with 90% desktop penetration that makes sense too.
First of all, I suspect that more than 10% of epoc32 users also uses
a non-Windows computer as their first choice desktop platform,
secondly why prevent users and developers of these platforms from
developing their own connectivity tools when Symbian neither has the
resources nor the interest in doing so? Some of us do believe in the
freedom of choice and that there are a better world outside the
Windows-zone ;-)
> The Java SDK is coming... with OPL and C++ this represents more
> development options than most other handhelds.
Yes the Java SDk is finally coming out, but all development tools are
Symbian products which means that their exist no competition in this
market and the lack competition/monopoly has benefited other than
those who sit on the monopoly (just see Microsoft, that is a perfect
example). For many epoc32 users for whom the C++ SDK/Microsoft
Visual Basic option is just too expensive, the OPL option is a
reasonable alternative, but would it not be preferable to have a desktop-
based OPL tool where you could edit, translate and run your programs
and then transfer the final program to your epoc32 device instead of
sitting bent over your Psion 5 trying to debug a 1000 line OPL program?
>>example of such a development tool could be a java compiler producing
>>native epoc32 application
>See above.
I am sorry to inform you but Symbian will not bring out a native Java
compiler
producing binary ARM executables. That was what I meant.
To restate my opinion. I do not in any way want Symbian to begin supporting
other platform or bringing out other kinds of development tools I just urge
them to release the information that give 3rd-party developers a chance
for producing a grater variety of software for a greater range of platforms
which
only can be a benefit for the epoc32 platform. I also find Symbians policy a
little bit odd in comparison with most other OS's where a much wider range
of documentation is available. In the era of open-source the idea of keeping
the
documentation to yourself is somewhat old fashion.
Jesper Zuschlag
John Forrest
Jesper Zuschlag <jes...@zuschlag.dk> wrote in message
news:371F998E...@zuschlag.dk...
> The question about the file formats of epoc32 has been popping up on a
> regular basis both
> in the comp.sys.psion.* new groups and in the epoc world news groups and
> each time
> psion/symbian has stubbornly refuse to publish any information at all
> claiming that there exist
> no such documentation
> Firstly I do not believe that symbian do not have any documentation on
> the internal structure
> of epoc files even though it is more complex than ordinary file formats.
> if the opposite should
> be to case then it would be a evidence of an exceptional lack of system
> documentation by
> Symbian, something I can not believe to be the case.
I recently got hold of info about one of the internal formats on the
Support.C++ epocworld newsgroup. This was not in terms of the file layout,
but told me how to access the internal streams and how the decode is
organised. This is exactly what the case would be if I were to tell you the
underlying format of one of my applications' files. Asking for lower level
info is a bit like asking an applications programmer how the bytes in the
heap are organised - you don't know and you couldn't usually care. Things
are documented in terms of the objects/struct format and how they are
connected. You expect the heap routines to do the rest. The same is true for
stream store access - the only difference is that streams are accessed in a
serial manner, and typically loaded into or stored from related run-time
objects in the heap.
Implication: the low level documentation does not exist because Symbian have
little internal need for it. Exceptions include the Record file format,
which is not a proper EPOC file and can be accessed very simply by cheating.
AFAIK no other main app's documents can be easily accessed by bypassing the
stream store.
> I that Symbian would reconsider their position on this matter and if
> that is not the case then that the
> community of eproc32 users and developers would join together in a
> demand for Symbian to abandon
> their current policy and release the much needed documentation on epoc32
> file formats like it is the
> case with most other operating system vendors.
I don't see most users out there bothering, and the "developers" who are
moaning and in the main those who don't want to use Windows. As far as I can
tell, the people who are really bothered are not developers because they
don't want to use PCs. So these can hardly stop being developers;-)
As I see it there is a real requirement for Mac-based file conversion, and
to a less extent, Linux-based conversion. The solution to this is nothing,
really, about file formats. What is required is an equivalent of the WINC
run-time environment, and a back end compiler (Linux might be easier,
especially if the same version of gcc were used). Then similar convertors as
the PCs could be run. This involves access to the internals, and I see no
propect of Symbian providing this to arbitrary 3rd parties - EPOC is their
major earner.
John
Stephen Gennard
I think that symbian could help the community by making the APIs available to
manipulate the internal psion format 'open source'. This allow developers
to take these APIs and wrap them for different environments.
During this process the developer may find issues/bugs and fix them,
under the 'open source' agreement the developer can then feed them back
to symbian. Hence they would gain extra product stability and testing for free.
I think symbian should seriously consider doing this. Even Microsoft are
considering 'open souring' parts of their products!
What do you think symbian? or anyone else for that matter....
--
Stephen Gennard, Merant.com, Newbury, Berkshire, England.
Unix Runtime Development, ESS Group. Email: stephen...@merant.com
WWW: http://www.merant.com
--
Jesper Zuschlag wrote:
>
> The question about the file formats of epoc32 has been popping up on a
> regular basis both
> in the comp.sys.psion.* new groups and in the epoc world news groups and
> each time
> psion/symbian has stubbornly refuse to publish any information at all
> claiming that there exist
> no such documentation and even if such documentation did exist then they
> would not disclose
> it to the general public as epoc32 developer should use the standard
> stream store "API" and
> not access the data directly on the file level.
>
> Although I fully support the idea of only accessing file-based data
> trough a standard API in
> epoc applications (which often results in much more robust applications)
> I find the resulting
> policy of withholding all documentation on file formats a very serious
> problem for many
> developers of epoc32 related products myself included and I believe it
> is done for the wrong
> reasons.
>
> Firstly I do not believe that symbian do not have any documentation on
> the internal structure
> of epoc files even though it is more complex than ordinary file formats.
> if the opposite should
> be to case then it would be a evidence of an exceptional lack of system
> documentation by
> Symbian, something I can not believe to be the case. However I suspect
> that the real reason
> behind this secrecy is that Symbian for some reason tries to guard the
> details about the internal
> functionality of epoc32.
>
> Secondly I find that the lack of documentation on file formats severely
> restricts the possibilities
> of 3rd-party developers for producing products like file conversion
> tools for alternative platforms
> (like RISC OS, BeOS, Linux etc) that symbian do not have the resources
> nor the interest in
> supporting. The situation today dictates that the users of epoc32
> devices has access to a Windows
> or MacOS based computers in order to get the full benefit of their
> epoc32 devices. Owners of
> alternative platforms (a small but not insignificant minority) can not
> hope for much more than to get
> their files transferred onto their desktop computer, whereas any file
> conversion for further work on
> their documents is out of the question, something that is a great
> annoyance for many epoc32 users.
>
> Another area where disclosure of file formats would benefit is
> development tools. Today, the only
> development tools available are the official Symbian SDK's and the
> build-in OPL translator/
> interpreter. If for instance the format of exe/lib/dll files and details
> about how they are functioning
> internally were made public then it would possible for 3rd-party
> developers to produce new
> development tools thus giving other developers more options and
> hopefully resulting in more
> developers developing for the epoc32 platform and thus better
> applications for the end user. An
> example of such a development tool could be a java compiler producing
> native epoc32 application
> from a java source or an OPL translator/interpreter for other
> desktop-based platforms, so that
> OPL-programmer would not be forced to write their programs directly on
> their epoc32 device -
> an idea that I personally have been toying with for some time and that
> is only possible if the format
> of OPO/OPA files is known (although the work of Mike Rudin helps a lot,
> it is not complete and so
> it would not be possible to guarantee 100% comparability with epoc32
> OPL, sigh!)
>
> I that Symbian would reconsider their position on this matter and if
> that is not the case then that the
> community of eproc32 users and developers would join together in a
> demand for Symbian to abandon
> their current policy and release the much needed documentation on epoc32
> file formats like it is the
> case with most other operating system vendors.
>
> Jesper Zuschlag
John Forrest
Stephen Gennard <stephen...@merant.com> wrote in message
news:37203045...@merant.com...
> Hi,
>
> I think that symbian could help the community by making the APIs available
to
> manipulate the internal psion format 'open source'. This allow developers
> to take these APIs and wrap them for different environments.
Do you mean the internals? Since these often depend on whole swathes of the
underlying EPOC system (and I don't just mean the implementation), I don't
see how.
John
Stephen Gennard
The file format in Epoc is based around "Objects" saving their own data,
therefore the only part of Epoc we may need to know is how to access data that
is saved via a object. Ie: similar to MFC's Serialize functions.
On Unix various people have created set of library functions for Ole data
access that allows information to be retrieved from these files, eg:
MSWordView on linux uses this technology. What we need is something
similar to this for Epoc.
--
Stephen Gennard, Merant.com, Newbury, Berkshire, England.
Unix Runtime Development, ESS Group. Email: stephen...@merant.com
WWW: http://www.merant.com
--
Brian Ritchie - remove 'no f***ing junk' acronym to reply
> In the S3 days, you had documentation for the various file formats. This
> didn't dissuade Psion from changing e.g. the World database format, thus
> making old version converters/files non-functional.
> If you have a new ROM, and old API's, will these be able to read the *new*
> formats - not!
Not "not!" but "maybe". Don't know how it'd work with EPOC32, but the SIBO
file formats all had "spare" fields, which allowed for at least some
future extension that didn't compromise old code. And stream-stores are
probably pretty future-proof, see below.
> I'm not sure I can see the difference.
>
> AFAICS, if you have a stream store, the various parts (objects) in the store
> must be identifiable in order for some API to read them.
> Or are we dealing in miracles here?
It's only a miracle if you don't understand it :-)
> What I see as the biggest hurdle is that any single converter more or less
> has to know about all the possible objects in order to be able to safely
> read any stream-store.
Not really. At one level, it only needs to know to which object it
should next delegate the job of reading the next portion of the
stream; and at another level, even that could be generalised. In
theory at least, a stream-store reader could be used to (initiate) the
reading of objects whose definitions didn't exist when the reader was
compiled. No idea if that's what actually happens in EPOC; I just
wanted to point out that your hurdle isn't necessarily the case.
--
Dr. Brian Ritchie, W3 Group, Rutherford Appleton Laboratory, UK
<http://www.dci.clrc.ac.uk/Person.asp?B.Ritchie>
John Forrest
Brian Ritchie - remove 'no f***ing junk' acronym to reply
<b.ri...@rnfjl.ac.uk> wrote in message news:vkyajj2...@rl.ac.uk...
> > What I see as the biggest hurdle is that any single converter more or
less
> > has to know about all the possible objects in order to be able to safely
> > read any stream-store.
>
> Not really. At one level, it only needs to know to which object it
> should next delegate the job of reading the next portion of the
> stream; and at another level, even that could be generalised. In
> theory at least, a stream-store reader could be used to (initiate) the
> reading of objects whose definitions didn't exist when the reader was
> compiled. No idea if that's what actually happens in EPOC; I just
> wanted to point out that your hurdle isn't necessarily the case.
I don't believe this isreally true for EPOC, except for a caveat that I'll
come to. When reading a stream, the reader literally has to know what to
expect. There is *no* way of finding out the size of something and thus no
way of skipping unknown objects. There is *no* provision for dealing with
extra fields (unless a size field is encoded as part of the object, which is
only done for variable arrays etc).
The caveat is that only applies to individual streams. If extra streams are
present in a store, then the original reader will ignore them - that is how
EPOC apps are supposed to deal with upwards compatability (by putting new
stuff into extra streams). Thus you may find parts of objects stored in
different streams.
John
Ajai Khattri
<stephen...@merant.com> wrote:
>Even Microsoft are
>considering 'open souring' parts of their products!
You mean that recent story about them "maybe" opening parts of NT
source? I think it was just a red herring - another great M$ PR
exercise. M$ are too busy milking their cash cow to the
computer-illiterate masses. And the "good" news is that Windows 98
Update will cost the same as Windows 98 (which in turn is really a
bug-fix for Windows 95 which also cost the same!).
--
Aj. (aj...@ibm.net)
Ajai Khattri
<jes...@zuschlag.dk> wrote:
>Yes I agree (surprised?) It makes perfectly sense for Symbian to concentrate
>their effort to as few platforms as possible, but that should not be a reason
>for preventing that other 3rd-party developers can producing connectivity
>and conversion tools for alternative platforms.
If it means devoting valuable resources to do this then yes it would
be a problem... I think you forget that Symbian is a *software*
company and that is how they make their money.
>First of all, I suspect that more than 10% of epoc32 users also uses
>a non-Windows computer as their first choice desktop platform,
I was referring to desktop computers. If 90% use PCs, then the
remainder 10% would include Macs, Linux, OS/2, etc. And then out of
those tiny percentages, how many would have S5's? I suspect it would
be a very small number.
>reasonable alternative, but would it not be preferable to have a desktop-
>based OPL tool where you could edit, translate and run your programs
>and then transfer the final program to your epoc32 device instead of
>sitting bent over your Psion 5 trying to debug a 1000 line OPL program?
This is exactly what the OPL SDK gives you.
>I am sorry to inform you but Symbian will not bring out a native Java
>compiler
>producing binary ARM executables. That was what I meant.
Of course not - Java programs don't compile into native
machine-dependant code otherwise it wouldn't be platform-independant
would it!
You can access native methods using the EPOC JVM - this gives you
access to libraries and objects in a similar fashion and just as
efficiently as a C++ program (but of course, then the code is no
longer 100% Pure Java(tm) anymore ;-)
>I also find Symbians policy a
>little bit odd in comparison with most other OS's where a much wider range
>of documentation is available.
Not really. Just remember EPOC32 is more like an embedded system and
not like a desktop OS. In the embedded systems world there is no such
thing as "normal" ;-)
>In the era of open-source the idea of keeping
>the documentation to yourself is somewhat old fashion.
If its documentation you're after then go download the eval. SDK -
tons of documentation in that. Of course, Symbian is not "keeping the
documentation" to itself at all - you can pay up and buy it yourself.
If Symbian refused to sell it to anyone then what you say would be
correct.
--
Aj. (aj...@ibm.net)
Ajai Khattri
wrote:
>In the S3 days, you had documentation for the various file formats. This
>didn't dissuade Psion from changing e.g. the World database format, thus
>making old version converters/files non-functional.
Bad example - the World file is a known-problem between machines. You
couldn't copy a 3a World file onto a 3c and open it without getting a
runtime error.
>AFAICS, if you have a stream store, the various parts (objects) in the store
>must be identifiable in order for some API to read them.
>Or are we dealing in miracles here?
Yes they are - each stream as its own ID.
>What I see as the biggest hurdle is that any single converter more or less
>has to know about all the possible objects in order to be able to safely
>read any stream-store.
This is why we have application engine API's in the SDK - these enable
you to open EPOC documents for which an engine API is available. The
same code is used for the convertors in PsiWin 2.x for example.
--
Aj. (aj...@ibm.net)
Jesper Zuschlag
Ajai Khattri wrote:
> On Fri, 23 Apr 1999 10:34:37 +0200, Jesper Zuschlag
> <jes...@zuschlag.dk> wrote:
>
> >Yes I agree (surprised?) It makes perfectly sense for Symbian to concentrate
> >their effort to as few platforms as possible, but that should not be a reason
> >for preventing that other 3rd-party developers can producing connectivity
> >and conversion tools for alternative platforms.
>
> If it means devoting valuable resources to do this then yes it would
> be a problem... I think you forget that Symbian is a *software*
> company and that is how they make their money.
But they do not have to spend large amount of resource on this effort. My
point is all the time that I suspect that this information is already exist,
maybe not as a traditional file format but then as a description who the
various serialize and deserialize them self to and from a stream store
(but that is just two different was of describing the same thing), how do
you else think that new employees at Symbian are able to further develop
their product - reading through millions of line of code - I do not think
so, what about you?
About the fact that Symbian is a *software* company, that is correct. But
they are also a company with a alternative operating system competing other
OS vendors about the market lead, and all experience tells us that the quality
of your operating system do not count a bit if you not have wide array of
3rd party developers producing all kind of software so that the users has
a many choices as possible (any the Windows case clearly show us that even
if you got a inferior product then a wide software portfolio and a massive
marking effort can still do the job for you). It is a accelerating development,
more more and better software titles gives more users and thus making it
profitable for more developers to produce more titles and so on... And this
goes for both developing tool/programming languages as well as end user
applications.
> >First of all, I suspect that more than 10% of epoc32 users also uses
> >a non-Windows computer as their first choice desktop platform,
>
> I was referring to desktop computers. If 90% use PCs, then the
> remainder 10% would include Macs, Linux, OS/2, etc. And then out of
> those tiny percentages, how many would have S5's? I suspect it would
> be a very small number.
My experience tells me that even if only 10% of desktop users use alternative
platforms they are more likely to choose a non-Microsoft platform for their
PDA and hence more that 10% of the epoc/psion users prefer a non-Windows
desktop platform. Remember that many Windows users are likely to go for
the Windows CE alternative as they think they get a similar product (and in
many sense they are, it is almost as unstable as Windows itself)
> >reasonable alternative, but would it not be preferable to have a desktop-
> >based OPL tool where you could edit, translate and run your programs
> >and then transfer the final program to your epoc32 device instead of
> >sitting bent over your Psion 5 trying to debug a 1000 line OPL program?
>
> This is exactly what the OPL SDK gives you.
Ok, I have never seen the OPL SDK, so I can not confirm that this product is
similar to what I thought about, but even if that is the case then we have a
classic example of a monopoly, where only Symbian is able to offer such
a product to the user, meaning that there exist no competition on neither
price nor quality. It is exactly the opposite situation that has ensured Windows
it success (not the quality of Window itself that is for sure)
> >I am sorry to inform you but Symbian will not bring out a native Java
> >compiler
> >producing binary ARM executables. That was what I meant.
>
> Of course not - Java programs don't compile into native
> machine-dependant code otherwise it wouldn't be platform-independant
> would it!
There exist Java-to-native code compiler for most platforms, just not for the
epoc platform as Symbian is not interested in it and they have not
released any information that enable 3rd-party developers to do it instead ;-)
You can choose to use Java as a portable distribution format and then
execute it via interpretation or some kind of late time compilation, or you
can choose to use it as more like ordinary programming language, compile
it to native binary code and the distribute this executable. The choice is all
yours and depends of what market you are targeting and what kind
of application you are developing. In many situations where cross-platform
distribution not is an issue I will prefer to use Java has it is a very elegant
language, and remember that the application is still cross-platform in the sense
that I still can take the exact same source and compile it to some other
platforms native binary or to bytecode format without changing the source
at all.
> >I also find Symbians policy a
> >little bit odd in comparison with most other OS's where a much wider range
> >of documentation is available.
>
> Not really. Just remember EPOC32 is more like an embedded system and
> not like a desktop OS. In the embedded systems world there is no such
> thing as "normal" ;-
The market that Symbian is targeting is far from similar to the embedded market
where the hardware and software is invisible to the user. It the PDA/small
consumer
appliance / mobile phone market the name branding and the size and quality of the
software portfolio is a very important factor much like in the desktop market. Why
do you think that ordinary consumers would consider a Windows CE based machine
instead of a epoc based? That is because that they know the Windows/Microsoft
brand and because they expect that there will be tons a software titles available
(if
they only knew). So any action that could lead to a wider software selection and
support for more platforms (especially Linux as nobody can afford to ignore this
platform anymore not even Microsoft) would benefit the epoc market and hence
Symbian.
> >In the era of open-source the idea of keeping
> >the documentation to yourself is somewhat old fashion.
>
> If its documentation you're after then go download the eval. SDK -
> tons of documentation in that. Of course, Symbian is not "keeping the
> documentation" to itself at all - you can pay up and buy it yourself.
> If Symbian refused to sell it to anyone then what you say would be
> correct.
I'm already a epoc world member and I got the C++ SDK and I would say
that the documentation is far from complete and the quality is much to desire,
and do not include the information that arguing for them to release.
Jesper Zuschlag
John Forrest
> But they do not have to spend large amount of resource on this effort. My
> point is all the time that I suspect that this information is already
exist,
> maybe not as a traditional file format but then as a description who the
> various serialize and deserialize them self to and from a stream store
> (but that is just two different was of describing the same thing), how do
> you else think that new employees at Symbian are able to further develop
> their product - reading through millions of line of code - I do not think
> so, what about you?
Let's assume the documentation did not exist. You would not have to read
through millions of lines of source - just look at the appropriate
InternalizeL methods. So it is quite possible that the documentation is via
the source and comments. Also these things tend to be recursive.
> > >First of all, I suspect that more than 10% of epoc32 users also uses
> > >a non-Windows computer as their first choice desktop platform,
> >
> > I was referring to desktop computers. If 90% use PCs, then the
> > remainder 10% would include Macs, Linux, OS/2, etc. And then out of
> > those tiny percentages, how many would have S5's? I suspect it would
> > be a very small number.
>
> My experience tells me that even if only 10% of desktop users use
alternative
> platforms they are more likely to choose a non-Microsoft platform for
their
> PDA and hence more that 10% of the epoc/psion users prefer a non-Windows
> desktop platform. Remember that many Windows users are likely to go for
> the Windows CE alternative as they think they get a similar product (and
in
> many sense they are, it is almost as unstable as Windows itself)
Do you have any evidence about this, or is it just supposition or hearsay?
This is oft quoted, but I've yet to see any reason to believe it. Windows
people are just as likely to go for Palm machines - after all they have sold
the most.
> > >reasonable alternative, but would it not be preferable to have a
desktop-
> > >based OPL tool where you could edit, translate and run your programs
> > >and then transfer the final program to your epoc32 device instead of
> > >sitting bent over your Psion 5 trying to debug a 1000 line OPL program?
> >
> > This is exactly what the OPL SDK gives you.
>
> Ok, I have never seen the OPL SDK, so I can not confirm that this product
is
> similar to what I thought about, but even if that is the case then we have
a
> classic example of a monopoly, where only Symbian is able to offer such
> a product to the user, meaning that there exist no competition on neither
> price nor quality. It is exactly the opposite situation that has ensured
Windows
> it success (not the quality of Window itself that is for sure)
The competition is surely other OSs.
> There exist Java-to-native code compiler for most platforms, just not for
the
> epoc platform as Symbian is not interested in it and they have not
> released any information that enable 3rd-party developers to do it instead
;-)
>
> You can choose to use Java as a portable distribution format and then
> execute it via interpretation or some kind of late time compilation, or
you
> can choose to use it as more like ordinary programming language, compile
> it to native binary code and the distribute this executable. The choice is
all
> yours and depends of what market you are targeting and what kind
> of application you are developing.
You are assuming that a useful Java subset could be formed based on what can
be directly implemented on the EPOC machine. I have severe doubts as to
this. For example, the posix/standard C subset is limited - especially when
it comes to writing interactive code. There are major problems in using
threads (threads can't share resources, so techniques such as using several
threads to wait for I/O don't work). My guess is that the java machine will
simulate java threads on top of a standard EPOC thread, rather than
translate them. That will be inefficient, but for an interpreted system
probably OK. For native code that would be a major overhead. The alternative
is to write Java code as a sort of psuedo-C++, trying to provide a sort of
one to one comparison with the the EPOC C++ system. Where would that get
you?
> I'm already a epoc world member and I got the C++ SDK and I would say
> that the documentation is far from complete and the quality is much to
desire,
> and do not include the information that arguing for them to release.
If you want to moan about the system, then fine, but that is I believe a
different point. The SDK is not, I believe, a shrink wrapped product. That
is why the package allows you to ask questions of Symbian. However, if they
have made a commercial decision not to release certain key details then that
is their business (literally). Remember that their primary customers are
people like Psion, Nokia, Ericsson etc who quite possibly prefer things to
be kept the way they are. I don't see how moaning in this newsgroup is going
to change things - a carefully researched and argued case would, I have
thought, have a better chance.
John
Ajai Khattri
<jes...@zuschlag.dk> wrote:
>maybe not as a traditional file format but then as a description who the
>various serialize and deserialize them self to and from a stream store
>(but that is just two different was of describing the same thing), how do
>you else think that new employees at Symbian are able to further develop
>their product - reading through millions of line of code - I do not think
>so, what about you?
This is what the application engine API is for - it handles all this
for you. You can't make a point if you haven't even read the SDK
documentation yourself.
>Ok, I have never seen the OPL SDK, so I can not confirm that this product is
>similar to what I thought about, but even if that is the case then we have a
>classic example of a monopoly, where only Symbian is able to offer such
>a product to the user, meaning that there exist no competition on neither
>price nor quality. It is exactly the opposite situation that has ensured Windows
>it success (not the quality of Window itself that is for sure)
Not really - there's nothing to stop a company licensing EPOC and
making their own development kit. This is different from say M$ that
would prob. refuse to license parts of the OS or give source code
away.
>There exist Java-to-native code compiler for most platforms,
I think you are getting confused. What you are talking about are the
JIT (Just-In-Time) Java machines that compile on the fly as the
program is interpreted. A Java program is not compiled into fully
native code in this case either. If JIT exists on the JVM it will be
used otherwise it will be interpreted just like any other Java
program.
>just not for the
>epoc platform as Symbian is not interested in it and they have not
>released any information that enable 3rd-party developers to do it instead ;-)
If they plan to release a Java SDK then why would they spend all the
resources and then give it away to 3rd party developers? If you want
to write a JVM yourself, you can do that if you want, but don't expect
Symbian to give you their product or SDK for nothing.
>I will prefer to use Java has it is a very elegant
>language, and remember that the application is still cross-platform in the sense
>that I still can take the exact same source and compile it to some other
>platforms native binary or to bytecode format without changing the source
>at all.
If you use Java this way, then what is the difference using C and
Java? Answer: none! Using Java this way completely misses the point of
using Java in the first place. If you want only source-level
compatibility then stick to C or C++ or some other widely available
language.
>The market that Symbian is targeting is far from similar to the embedded market
>where the hardware and software is invisible to the user. It the PDA/small
Erm, do you know what OS runs in my digital cellular phone? No? I
don't know either and furthermore I don't care. Symbian are targetting
mobile phones, pagers, communicators and handhelds. I think phones are
very much embedded systems. Most people don't care what the OS is as
long as the software works reliably. A lot of S5 users don't know what
EPOC is for example.
>do you think that ordinary consumers would consider a Windows CE based machine
>instead of a epoc based?
Ooh I don't know - maybe spending $100 million on PR might have
something to do with it... or maybe because the average user doesn't
really know much about alternative operating systems in general... or
maybe because up until very recently it was very hard to buy a PC from
a name-brand dealer *without* Windoze pre-installed on it.
>I'm already a epoc world member and I got the C++ SDK and I would say
>that the documentation is far from complete and the quality is much to desire,
>and do not include the information that arguing for them to release.
I think the amount of documentation is enormous personally.
--
Aj. (aj...@ibm.net)
Jesper Zuschlag
> On Sat, 24 Apr 1999 14:23:33 +0200, Jesper Zuschlag
> <jes...@zuschlag.dk> wrote:
>
> >maybe not as a traditional file format but then as a description who the
> >various serialize and deserialize them self to and from a stream store
> >(but that is just two different was of describing the same thing), how do
> >you else think that new employees at Symbian are able to further develop
> >their product - reading through millions of line of code - I do not think
> >so, what about you?
>
> This is what the application engine API is for - it handles all this
> for you. You can't make a point if you haven't even read the SDK
> documentation yourself.
Oh, how stupid of me, the API clearly document the layout of the files. I'm
sorry to inform you, that this is not the case.
> >Ok, I have never seen the OPL SDK, so I can not confirm that this product is
> >similar to what I thought about, but even if that is the case then we have a
> >classic example of a monopoly, where only Symbian is able to offer such
> >a product to the user, meaning that there exist no competition on neither
> >price nor quality. It is exactly the opposite situation that has ensured Windows
> >it success (not the quality of Window itself that is for sure)
>
> Not really - there's nothing to stop a company licensing EPOC and
> making their own development kit. This is different from say M$ that
> would prob. refuse to license parts of the OS or give source code
> away.
I don't what to license any part of epoc and I don't need the source code I just want
them
to release proper documentation on their product, nothing more or less. Licensing the
OS
just for providing alternative developing tools is not an option for most of the
developers
in the epoc market as the license free starts about 1.5 million pounds, and it is a
bit
overkill for licensing a whole operation system just for this purpose.
> >There exist Java-to-native code compiler for most platforms,
>
> I think you are getting confused. What you are talking about are the
> JIT (Just-In-Time) Java machines that compile on the fly as the
> program is interpreted. A Java program is not compiled into fully
> native code in this case either. If JIT exists on the JVM it will be
> used otherwise it will be interpreted just like any other Java
> program.
Confused? maybe, but not on this matter, not after spending more than
two years developing af Java VM with on-line compilation. Traditional
off-line Java compilers producing native code are really something that
exist and are clearly superior to on-line compilers (a.k.a. jit-compilers)
because they can explore all the advanced optimization techniques that
are to time-consuming for on-line compilation. Supercede is just one
example of a commercial product that includes a off-line compiler and I
can supply you with numerous of references on the subject if you desire.
> >just not for the
> >epoc platform as Symbian is not interested in it and they have not
> >released any information that enable 3rd-party developers to do it instead ;-)
>
> If they plan to release a Java SDK then why would they spend all the
> resources and then give it away to 3rd party developers? If you want
> to write a JVM yourself, you can do that if you want, but don't expect
> Symbian to give you their product or SDK for nothing.
Again, I don't what Symbian's product or SDk, I just what the proper documentation
and I'm willing to pay just as I paid for the C++ SDK. If I or somebody else were
to develop an alternative Java VM for epoc then there would exist an alternative
to Symbian's product, thus giving competition, thus inspire to producing better
products
and thus giving the users more and better products - that what competition is all
about.
> >I will prefer to use Java has it is a very elegant
> >language, and remember that the application is still cross-platform in the sense
> >that I still can take the exact same source and compile it to some other
> >platforms native binary or to bytecode format without changing the source
> >at all.
>
> If you use Java this way, then what is the difference using C and
> Java? Answer: none! Using Java this way completely misses the point of
> using Java in the first place. If you want only source-level
> compatibility then stick to C or C++ or some other widely available
> language.
Since when has C/C++ offered garbage collection, lack of pointers (and thus no
illegal memory references), build-in multi-threading just for mention some of Java
advantage. And claiming that C/C++ has cross-platform compatibility on source
level is rather bold. Even the C and C++ standards includes numerous of details
that are left implementation dependent and when you add that almost no compilers
are confirm fully to the standard, then the source level compatibility is more than
doubtful. This is a fact that all programmers that has tried to use the same code
base across multiple platforms has experienced.
> >The market that Symbian is targeting is far from similar to the embedded market
> >where the hardware and software is invisible to the user. It the PDA/small
>
> Erm, do you know what OS runs in my digital cellular phone? No? I
> don't know either and furthermore I don't care. Symbian are targetting
> mobile phones, pagers, communicators and handhelds. I think phones are
> very much embedded systems. Most people don't care what the OS is as
> long as the software works reliably. A lot of S5 users don't know what
> EPOC is for example.
Not now, but i Microsoft is able to associate their brand with these kinds ofproducts
then people will care and then it is to late for Symbian and that is
something I do not what to se happen.
> >I'm already a epoc world member and I got the C++ SDK and I would say
> >that the documentation is far from complete and the quality is much to desire,
> >and do not include the information that arguing for them to release.
>
> I think the amount of documentation is enormous personally.
You have not seen much OS documentation have you?
Jesper Zuschlag
Alan Morris, G4ENS
>
>Ajai Khattri wrote:
>
>> Yes because in a future release of a new ROM or new machine the
>> internal structure of a file may change. And hence using the API only
>> makes perfect sense so your program will not break on every future
>> machine released.
>
>And then all your old files needs to be converted - no that is not the
>reason.
>If Symbian later would alter some of the file formats if will properly be
by
>extending the current formats. The reason that working through a well
defined
>API makes sense is to ensure the integrity of the files.
There was a time when developers needing to enhance their product's file
structures would issue a conversion .EXE file.
This would be run once on the existing data to convert it to the new
structure. Some programs would automatically recognise their older format
and use it or convert it to the new format. On a small device like a Psion
a single conversion would save disk space.
Alan, G4ENS.
Bury St Edmunds, Suffolk, UK.
Where do you want to go today ? Away from Windows.
Pim van der Eijk
much point in releasing the EPOC file formats. The fashionable (and
imho right) thing to do would be to have the EPOC network client
automagically convert from EPOC file formats (on the PDA/communicator)
to XML when exchanging data over a network.
Keld Laursen
>
>Brian Ritchie - remove 'no f***ing junk' acronym to reply
><b.ri...@rnfjl.ac.uk> wrote in message news:vkyajj2...@rl.ac.uk...
>less
>> > has to know about all the possible objects in order to be able to
safely
>> > read any stream-store.
>>
>> should next delegate the job of reading the next portion of the
>> stream; and at another level, even that could be generalised. In
>> theory at least, a stream-store reader could be used to (initiate) the
>> reading of objects whose definitions didn't exist when the reader was
>> compiled. No idea if that's what actually happens in EPOC; I just
>> wanted to point out that your hurdle isn't necessarily the case.
>
>I don't believe this isreally true for EPOC, except for a caveat that
I'll
>come to. When reading a stream, the reader literally has to know what to
>expect. There is *no* way of finding out the size of something and thus no
>way of skipping unknown objects. There is *no* provision for dealing with
>extra fields (unless a size field is encoded as part of the object, which
is
>only done for variable arrays etc).
>
>The caveat is that only applies to individual streams. If extra streams are
>present in a store, then the original reader will ignore them - that is how
>EPOC apps are supposed to deal with upwards compatability (by putting new
>stuff into extra streams). Thus you may find parts of objects stored in
>different streams.
>
store as different streams. In some way, it then identifies the parts it
understands, and discards the rest.
BUT STILL: Somewhere in there, some kind of code must be able to determine
what kind of object it is reading, if not for any other reason than to find
the correct API/DYL/APP to handle the object, and this might just be for the
reason of skipping the object.
I also have some problems with coming to terms with the *fact* that some
program can recognise, and use, some kind of heap dump without knowing how
that heap were organised.
Does it all come down to how the OOP compiler/system, supporting this,
handles its data (unbeknownst to the actual programmer)?
AARRRRRRRRRRGH
It might be smart, but I'll get out of this discussion before my headache
gets any worse.
Best regards
Keld Laursen
Keld Laursen
>>changing e.g. the World database format, thus making old version
>>converters/files non-functional.
>
>Bad example - the World file is a known-problem between machines. You
>couldn't copy a 3a World file onto a 3c and open it without getting a
>runtime error.
Exactly what I wanted to point out. I just wanted to say that it is not the
(lack of) documentation that allows Symbian to change the file formats.
Maybe I have just not looked into the problem carefully enough (I know I
haven't), but I fail to see how you can extend a file format without giving
somebody headaches. Either the *old* version will miss out on the new data,
or the new version *might* fall on its heels like the S3a/S3c world program.
>
[snip]
>>Or are we dealing in miracles here?
>
>Yes they are - each stream as its own ID.
First part of the mechanism with which we find out what is stored here,
right?
>
>>What I see as the biggest hurdle is that any single converter more or less
>>has to know about all the possible objects in order to be able to safely
>>read any stream-store.
>
>This is why we have application engine API's in the SDK - these enable
>you to open EPOC documents for which an engine API is available. The
>same code is used for the convertors in PsiWin 2.x for example.
And this API should be portable to other platforms, if the source code could
be made available.
Here, we probably stumble about the block that parts of this source will be
the lifeblood of Symbian. (This has been discussed elsewhere in this thread)
Best regards,
Keld Laursen
John Forrest
Keld Laursen <k...@mse-dk.com> wrote in message
news:YkWU2.143$la7...@news.get2net.dk...
> BUT STILL: Somewhere in there, some kind of code must be able to determine
> what kind of object it is reading, if not for any other reason than to
find
> the correct API/DYL/APP to handle the object, and this might just be for
the
> reason of skipping the object.
What actually happens is that the system knows from what UID the *store* has
to call a particular program, and then that program has to "know" how the
store and streams are organised. There is no other method of determining the
objects. A particular program might know that one of its streams (typically
identified by UID and look up in an index) contains a few integers followed
by a descriptor (read string). That is the level of the internals - they
have been deliberately stripped of any size and identification info to save
space.
>
> I also have some problems with coming to terms with the *fact* that some
> program can recognise, and use, some kind of heap dump without knowing how
> that heap were organised.
> Does it all come down to how the OOP compiler/system, supporting this,
> handles its data (unbeknownst to the actual programmer)?
Who mentioned heap dumps? The stores are not heap dumps in the conventional
sense (memory saved to files). They are formed by recursively calling StoreL
and ExternalizeL methods. ExternalizeL must be defined for all classes that
you should be able to save to streams (AKA "stream aware"). StoreL is the
outer wrapper that writes a (potential) network of objects to a store.
I mentioned heaps as a sort of parallel example at one point, and perhaps I
did not explain it very well. The point is that on one level the
applications programmer thinks in terms of objects linked up in the streams.
The objects are defined as classes, and the user does not think in terms of
the byte offsets in the class, let alone how those objects are mapped onto
the heap memory. That is all dealt with by the system and taken as "magic".
Similarly for stream-stores - you know the logical organisation but not the
internals. Any documentation is of the logical organisation and the low
level data format is ignored.
John
Chris Brown
Ajai Khattri <aj...@ibm.net> wrote:
>
>I suspect "most" users means your average person in the street which
>means they will most probably have a PC.
...and a Palmpilot.
--
/* _ */main(int k,char**n){char*i=k&1?"+L*;99,RU[,RUo+BeKAA+BECACJ+CAACA"
/* / ` */"CD+LBCACJ*":1[n],j,l=!k,m;do for(m=*i-48,j=l?m/k:m%k;m>>7?k=1<<m+
/* | */8,!l&&puts(&l)**&l:j--;printf(" \0_/"+l));while((l^=3)||l[++i]);}
/* \_,hris Brown -- All opinions expressed are probably wrong. */
Charlie Stross
<aj...@ibm.net> wrote:
>This is why we have application engine API's in the SDK - these enable
>you to open EPOC documents for which an engine API is available. The
>same code is used for the convertors in PsiWin 2.x for example.
But it's still utterly inaccessible to non-Windows users.
Look, I write a magazine column about Linux. In my next column I'm going
to be talking about PDAs. I can see *no alternative* to telling my readers
to avoid all EPOC/32 machines like the plague, because there is *no way*
of converting EPOC/32 documents into something useable on a Linux system.
I should add: I've been a Psion user for quite a few years. I depend on
a Series 3. The ability to do useful things with the Series 3's files on
other platforms is important -- it interoperates very nicely with Linux.
But Symbian/Psion's attitude to non-Windows platforms is so bad that
they're turning one of their fans -- me -- into a carping critic who will
advise people to use a Palm Pilot instead.
Not providing open APIs is damaging to their credibility outside their own
captive vertical market. It may have seemed reasonable to ignore the
non-Windows world in 1996-97, but it is _not_ reasonable today; if Linux
continues its current growth it will be bigger than Windows NT and MacOS
combined in less than eighteen months, and you ignore the second-largest
computing platform at your peril.
-- Charlie
Andrew Johnson
>
> Look, I write a magazine column about Linux. In my next column I'm going
> to be talking about PDAs. I can see *no alternative* to telling my readers
> to avoid all EPOC/32 machines like the plague, because there is *no way*
> of converting EPOC/32 documents into something useable on a Linux system.
It *is* possible to do conversions, but nobody has written the tools yet.
The secret is that you have to do at least part of the work on the S5,
rather than all of it under Linux or whatever. That way you can utilize
Psion's APIs and get all the forwards compatibility they offer. Heck you
could even write most of them in OPL using the various OPXs that are
around.
I would favour trying to integrate the EPOC32 end with the RS232/IR
transfer protocol, because then you can use the same EPOC32 software for a
variety of different hosts and target formats, but this could complicate
the communications architecture and isn't essential.
Perhaps you could sow that seed in the minds of your readers - I think
it's the best avenue given the circumstances. I don't think you should
scare them away completely given the other advantages which EPOC32 has
over WinCE.
- Andrew
--
New country, job, address, car and signature; same old Andrew Johnson
Peter Seebach
Andrew Johnson <a...@aps.anl.gov> wrote:
>Perhaps you could sow that seed in the minds of your readers - I think
>it's the best avenue given the circumstances. I don't think you should
>scare them away completely given the other advantages which EPOC32 has
>over WinCE.
Yes, but the Palm people are open and encouraging of third parties. If
they had a machine with a keyboard, Psion would have very little to offer
people who aren't registered Microsoft citizens.
As is, the Psion is an interesting toy, but I have to use CF cards for
backups, or send files as typeless raw data, because some *MORON* thought
it would be a brilliant idea not to have a file format.
Sorry, but the design reasons for standardized data formats have been well
known for a decade or two. The only argument against them is "if it's
documented, people aren't locked in to our product base".
-s
--
Copyright 1999, All rights reserved. Peter Seebach / se...@plethora.net
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Will work for interesting hardware. http://www.plethora.net/~seebs/
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
John Forrest
Peter Seebach <se...@plethora.net> wrote in message
news:z3bV2.1285$WA4.2...@ptah.visi.com...
> Sorry, but the design reasons for standardized data formats have been well
> known for a decade or two. The only argument against them is "if it's
> documented, people aren't locked in to our product base".
If you mean Psion should use, say, RTF as its native Word format, as at
least some CE versions have, then there are some pretty good arguments to do
with file size and efficiency. From what I can work out, if the Psion5 had
more convertors on board we would not be having this debate.
John
Keld Laursen
>
>Keld Laursen <k...@mse-dk.com> wrote in message
>news:YkWU2.143$la7...@news.get2net.dk...
>> BUT STILL: Somewhere in there, some kind of code must be able to
determine
>What actually happens is that the system knows from what UID the *store*
has
>to call a particular program, and then that program has to "know" how the
>store and streams are organised. There is no other method of determining
the
>objects. A particular program might know that one of its streams (typically
>identified by UID and look up in an index) contains a few integers followed
>by a descriptor (read string). That is the level of the internals - they
>have been deliberately stripped of any size and identification info to save
>space.
I think I got it now.
The methods used is not different from what I use on a more or less everyday
basis when I put various data into a file. Upon parsing the file, I find out
what kind of data is stored here (the stream type). I then call a function
that will determine how it will handle these data (the specific program's
index lookup). From this, I use some function(s) to read the actual data.
What makes the stream store difficult to document is that the data can come
from so many different places internal to the file-owning program (eg.
Word), the various stream-owning program(s) (eg. Sheet or Sketch), which in
turn might rely on various EPOC OS functions.
If a file format were to be devised, this would have to take all the various
ExternalizeL functions output possibilities and compile it all into one big
definition. This would probably be pulky and messy, but in no way un-doable.
From previous postings, I will have to assume that the various InternalizeL
functions have some method of finding out whether or not the data are
correct (read from a later version that has added functionality), or will
later additions have to be done by extending the index on the individual
stream in order to maintain backwards compatibility? If not, I can only see
forward compatibility in this system.
As I, and probably others, wrote: What we need is either conversion programs
created on the S5, or source code for the whole API, which will mean source
for large chunks of EPOC, in order to cross-compile these to other
platforms?
Best regards,
Keld Laursen
(Who is getting increasingly aware of how far behind he is in some computing
areas, but has realised that he can't do it all!)
John Forrest
> From previous postings, I will have to assume that the various
InternalizeL
> functions have some method of finding out whether or not the data are
> correct (read from a later version that has added functionality), or will
> later additions have to be done by extending the index on the individual
> stream in order to maintain backwards compatibility? If not, I can only
see
> forward compatibility in this system.
I personally tend to do something like that, but the official way is that
you use multiple streams with the original stream(s) being identical to
earlier versions and new streams being added. The original program will
simply ignore the new streams. Symbian don't always stick to this method,
and it is complex, but it does ensure backwards compatability to a fairly
high extent.
>
> As I, and probably others, wrote: What we need is either conversion
programs
> created on the S5, or source code for the whole API, which will mean
source
> for large chunks of EPOC, in order to cross-compile these to other
> platforms?
I personally prefer the former, as we'd need no info from Symbian as to how
to do it!
John
Stephen Gennard
is not being able to "Import/Export" data in a standard manor for example:
o The agenda could import/export data in vCalendar format, which is
understood my many Calendars/Schedulers
(see: http://www.imc.org/ietf-calendar/ for more information)
If I could "export" everything created in the last week.... well I would
be a happy chap.
o The word processor could import/export data in HTML/XML/PDF or even RTF
o The spreadsheet could import/export data in CSV, not perfect but it would
help keep some of the content
If Psion were able to-do this, it would help people using non-windows machines.
What does anyone else think?
--
Stephen Gennard, Merant.com, Newbury, Berkshire, England.
Unix Runtime Development, ESS Group. Email: stephen...@merant.com
WWW: http://www.merant.com
Charlie Stross
as <a...@aps.anl.gov> declared:
>Perhaps you could sow that seed in the minds of your readers - I think
>it's the best avenue given the circumstances. I don't think you should
>scare them away completely given the other advantages which EPOC32 has
>over WinCE.
Maybe. I _will_ be saying that the 3MX is the bee's knees, and that
the Series 5 interoperates brilliantly with Linux if you run one piece of
software on it -- namely, Linux. (Something which you can't do on a
WinCE box, AFAIK.) But I don't want to mislead people into thinking
that the Series 5 is linux-friendly today, when it isn't.
-- Charlie
Alasdair Manson
Stross) wrote:
>I can see *no alternative* to telling my readers
>to avoid all EPOC/32 machines like the plague, because there is *no way*
>of converting EPOC/32 documents into something useable on a Linux system.
While I know it's far from ideal, are Linux applications not able to
use text files and delimited data files?
regards
Alasdair
A Symbian employee in a personal capacity
Peter Seebach
John Forrest <j.fo...@dial.pipex.com> wrote:
>
>Peter Seebach <se...@plethora.net> wrote in message
>news:z3bV2.1285$WA4.2...@ptah.visi.com...
>> Sorry, but the design reasons for standardized data formats have been well
>> known for a decade or two. The only argument against them is "if it's
>> documented, people aren't locked in to our product base".
>If you mean Psion should use, say, RTF as its native Word format, as at
>least some CE versions have, then there are some pretty good arguments to do
>with file size and efficiency. From what I can work out, if the Psion5 had
>more convertors on board we would not be having this debate.
Probably not. If my Series 5 could export Word files as RTF, and print them
as PostScript, I probably wouldn't care. Similarly, I'd mostly be okay
with the ability to export Sheet and Data in variants of CSV, because, in
most cases, that's something I can munge.
I'm a programmer at heart; it doesn't bother me to spend 20 minutes hacking
together perl enough to take one data format and mangle it into another. What
bugs me is not being able to get the data in *ANY* standard format.
It's very Microsoft; embrace and extend, and try to make sure there's no way
back out.
David H Wild
Charlie Stross <cha...@pc.antipope.org> wrote:
> But it's still utterly inaccessible to non-Windows users.
> Look, I write a magazine column about Linux. In my next column I'm going
> to be talking about PDAs. I can see *no alternative* to telling my
> readers to avoid all EPOC/32 machines like the plague, because there is
> *no way* of converting EPOC/32 documents into something useable on a
> Linux system.
You're not being quite fair. I use my Psion5 along with an Acorn RiscPC. I
have a program that allows me to transfer files from one machin to the
other, and convert Word files to text on transfer. On the much rarer
occasions that I need to transfer database files from one machine to the
other I can do it using CSV files.
I also use this program for transferring JPEG files from my Kodak DC210+
camera to the RiscPC>
I admit that it's more awkward, but it's not impossible. Although I have a
PC card inside the RiscPC I have never felt the need to load PsiWin, of any
description.
--
__ __ __ __ __ ___ _____________________________________________
|__||__)/ __/ \|\ ||_ | / Acorn StrongArm Risc_PC
| || \\__/\__/| \||__ | /...Internet access for all Acorn RISC machines
___________________________/ dhw...@argonet.co.uk
Peter Seebach
Steve Waddicor <steve.w...@virgin.net> wrote:
>On Tue, 27 Apr 1999 04:30:23 GMT, se...@plethora.net (Peter Seebach)
>wrote:
>>Yes, but the Palm people are open and encouraging of third parties. If
>>they had a machine with a keyboard, Psion would have very little to offer
>>people who aren't registered Microsoft citizens.
>And if a Porche didn't have a big engine, it would have little to
>offer the Ford owner.
Not a fair comparison. Keyboards aren't as expensive to design as
cars are. ;)
>The Psion 5 and the Palm are different machines
>for different markets.
Yes.
>Different people have different needs. As a
>Unix programmer, I understand that you do not find a Psion 5 is an
>ideal fit for your needs. For many people, it is.
Yes.
But it would be much easier for Psion to make a Series 5 with support for
a standard format, or even just to document a file format, than it would
be for Palm to make a Palm III with a keyboard.
>>Sorry, but the design reasons for standardized data formats have been well
>>known for a decade or two. The only argument against them is "if it's
>>documented, people aren't locked in to our product base".
>Presumably only a moron would believe there could be any other
>arguments...
:)
Well, I'd love to see an argument that explains how the consumer can benefit
from not having access to file format documentation.
There are a lot of design wins to making a system accessible to the user.
I am not aware of design wins to not making it accessible.
Keld Laursen
John Forrest skrev i meddelelsen <7g3ums$an6$1...@lure.pipex.net>...[snip]
>>If not, I can only
>see
>> forward compatibility in this system.
>
>I personally tend to do something like that, but the official way is that
>you use multiple streams with the original stream(s) being identical to
>earlier versions and new streams being added. The original program will
>simply ignore the new streams. Symbian don't always stick to this method,
>and it is complex, but it does ensure backwards compatability to a fairly
>high extent.
Let's see if I get this right. Steve Waddicor wrote something in the same
line to me directly.
A new version of a program will have to be able to recognise "old" streams,
possibly by UID.
The new program must in itself have a unique UID.
When writing back, the "old" streams have to be written with the old UID,
and the new streams with the new UID?
When the differences is placed in individual streams, any program can easily
ignore the un-understood data, whereas "new" data in an old stream will be
virtually impossible to get around.
Is that about it?
Best regards,
Keld Laursen
John Forrest
> Let's see if I get this right. Steve Waddicor wrote something in the same
> line to me directly.
> A new version of a program will have to be able to recognise "old"
streams,
> possibly by UID.
> The new program must in itself have a unique UID.
> When writing back, the "old" streams have to be written with the old UID,
> and the new streams with the new UID?
> When the differences is placed in individual streams, any program can
easily
> ignore the un-understood data, whereas "new" data in an old stream will be
> virtually impossible to get around.
>
> Is that about it?
Yes. They are looked up by UID. Because programs look up streams by UID, any
additional streams are simply ignored. This technique works as long as
upgrades are evolutionary. It obviously does not work when updates are more
complex.
John
Ajai Khattri
<jes...@zuschlag.dk> wrote:
>Oh, how stupid of me, the API clearly document the layout of the files. I'm
>sorry to inform you, that this is not the case.
I never said it did - I said it takes care of these details for you
(i.e. you don't need to know the low-level stuff). You can pick out
whatever information you need from the document in question via the
app. engine.
>And claiming that C/C++ has cross-platform compatibility on source
>level is rather bold.
Relatively speaking, if you stick to standard APIs then yes you can
make that statement. The same is not true of C++ used in the EPOC32
SDK which is not standard ANSI C++.
>Even the C and C++ standards includes numerous of details
>that are left implementation dependent
True - but it is possible to write code without using many
platform-dependencies. At the very least, you can take the lowest
common denominator if need be and work with that. You shouldn't write
such dependant code anyway.
>Not now, but i Microsoft is able to associate their brand with these kinds ofproducts
M$ needs to partner with big players to do this - I don't see that is
the case.
>You have not seen much OS documentation have you?
I will not dignify that inflamatory remark with a response...
--
Aj. (aj...@ibm.net)
Ajai Khattri
<al...@mainline.co.uk> wrote:
>There was a time when developers needing to enhance their product's file
>structures would issue a conversion .EXE file.
>
>This would be run once on the existing data to convert it to the new
>structure. Some programs would automatically recognise their older format
>and use it or convert it to the new format. On a small device like a Psion
>a single conversion would save disk space.
There's nothing to stop a programmer supplying such a program.
--
Aj. (aj...@ibm.net)
Ajai Khattri
wrote:
>As I, and probably others, wrote: What we need is either conversion programs
>created on the S5, or source code for the whole API, which will mean source
>for large chunks of EPOC, in order to cross-compile these to other
>platforms?
Since the application engine libraries are also available under WINC,
you could use the EPOC Connectivity SDK to access S5 documents via the
same APIs as in the S5 application engines.
The only problem with this scheme is that third-party programmers may
not be willing to supply you with a WINC version of their application
engine.
--
Aj. (aj...@ibm.net)
Ajai Khattri
>But it's still utterly inaccessible to non-Windows users.
True - Symbian have targetted PC users primarily (again, this makes
sound business sense to me even if as programmers we don't like it).
>Look, I write a magazine column about Linux. In my next column I'm going
>to be talking about PDAs. I can see *no alternative* to telling my readers
>to avoid all EPOC/32 machines like the plague, because there is *no way*
>of converting EPOC/32 documents into something useable on a Linux system.
Apart from writing programs that run on the S5 itself...
>But Symbian/Psion's attitude to non-Windows platforms is so bad that
>they're turning one of their fans -- me -- into a carping critic who will
>advise people to use a Palm Pilot instead.
I also program on Linux systems a lot but there's no way I would not
recommend an S5 to someone purely because there is no Linux version of
PsiWin. You sound too much like a Linux zealot and less like someone
who is looking at what a person uses a PDA for and what sort of
platform they want to interface with. You can't assume that everyone
is using Linux or will even want to connect their computers to their
PDA.
>Not providing open APIs is damaging to their credibility outside their own
>captive vertical market. It may have seemed reasonable to ignore the
>non-Windows world in 1996-97, but it is _not_ reasonable today; if Linux
>continues its current growth it will be bigger than Windows NT and MacOS
>combined in less than eighteen months, and you ignore the second-largest
>computing platform at your peril.
Whilst this may or may not happen (7 million Linux users is not much
when compared with 90 million Windoze users), Ill believe it when I
see it. I am not against Linux being successful but you can't run a
business on "maybe's" - only the big guys (IBM, Compaq, etc) can
afford to do that.
--
Aj. (aj...@ibm.net)
Ajai Khattri
wrote:
>Exactly what I wanted to point out. I just wanted to say that it is not the
>(lack of) documentation that allows Symbian to change the file formats.
>Maybe I have just not looked into the problem carefully enough (I know I
>haven't), but I fail to see how you can extend a file format without giving
>somebody headaches. Either the *old* version will miss out on the new data,
>or the new version *might* fall on its heels like the S3a/S3c world program.
See John Forest's informative posting about new streams being added
alongside older streams in the same document.
>First part of the mechanism with which we find out what is stored here,
>right?
Well from the document UID it can work out what app is needed.
However, each app. may use its own IDs internally to identify streams
it needs to look at.
>And this API should be portable to other platforms, if the source code could
>be made available.
>Here, we probably stumble about the block that parts of this source will be
>the lifeblood of Symbian. (This has been discussed elsewhere in this thread)
Not to mention the fact that the way C++ is used in EPOC32 is not
standard. Programming an embedded system has never been standardised
and EPOC32 is no exception! ;-)
--
Aj. (aj...@ibm.net)
Ajai Khattri
wrote:
>I would favour trying to integrate the EPOC32 end with the RS232/IR
>transfer protocol, because then you can use the same EPOC32 software for a
>variety of different hosts and target formats, but this could complicate
>the communications architecture and isn't essential.
Exactly - which is why someone has been working on this already.
>it's the best avenue given the circumstances. I don't think you should
>scare them away completely given the other advantages which EPOC32 has
>over WinCE.
Thanks - my point exactly - only a zealot would not see the other
point of view.
--
Aj. (aj...@ibm.net)
Ajai Khattri
wrote:
>Yes, but the Palm people are open and encouraging of third parties. If
>they had a machine with a keyboard, Psion would have very little to offer
>people who aren't registered Microsoft citizens.
Don't you think this is an oversimplification on your part?
EPOC32 has many unique features that would not apply to the PalmOS.
>As is, the Psion is an interesting toy, but I have to use CF cards for
>backups, or send files as typeless raw data, because some *MORON* thought
>it would be a brilliant idea not to have a file format.
We have a stream format instead - which is a good idea. It doesn't fit
into your cosy traditional file formats world and so you call it
moronic!
--
Aj. (aj...@ibm.net)
Niel Markwick
Peter Seebach wrote:
> Well, I'd love to see an argument that explains how the consumer can benefit
> from not having access to file format documentation.
Most customers don't need file format documentation (and I mean customers both in the sense of Symbian's customers (ie Psion etc) and the people who buy the S5) - they just use the programs and 'shock horror' they work (most of the time!)...
Object Oriented Programming makes it relatively easy to instantly create a output file containing the information required to reconstruct your document using serialization of the in-memory objects - basically, each object saves its own data, and then instructs it's parent, and contained objects to save themselves...
(Java and MFC both push this technique as 'the one true way', and the 'stream store' sounds similar)
So, why bother spending a lot of development time explicitly designing a file format that will contain all the information you need (and writing and testing the read/write conversion routines) when your objects can do it themselves 'magically'!
So there's your answer - the customer benefits by getting a cheaper product due to the lower development cost.
I do agree however, that in this age of multi platform environments, that Symbian should have included on-Psion (or should that be in-EPOC!) converters to other, more recognisable file formats for each of the major programs...
Something like an EPOC version of the 'Convert files' app of Psiwin 2.1+ would be adequate (maybe with optional conversion modules to save on disk space)...
Niel.
--
Niel Markwick
Kontich, Belgium
Charlie Stross
>On Mon, 26 Apr 1999 22:30:35 +0100, cha...@pc.antipope.org (Charlie
>Stross) wrote:
>
>>I can see *no alternative* to telling my readers
>>to avoid all EPOC/32 machines like the plague, because there is *no way*
>>of converting EPOC/32 documents into something useable on a Linux system.
>
>While I know it's far from ideal, are Linux applications not able to
>use text files and delimited data files?
Yes, but. The text files the Series 5 Word application creates are
thoroughly broken (or at least, they were on my Series 5) and needed
extensive massaging to turn into something useful. In part, it was
the silly assumption that ASCII text files use the CR/LF combination
as an end-of-line marker -- this is only true for CP/M-descended OS's,
not for the rest of the universe. It only bothers putting an EOL market
at the end of each paragraph -- and when you import text, it assumes that
each EOL marks the end of a new paragraph. There also seemed to be
trailing crud characters when I exported text files -- don't know what
they were, but they weren't part of the text.
This makes it a pain in the butt for working with UNIX system.
I didn't try delimited data files, but I imagine similar problems would
be encountered in importing/exporting them.
-- Charlie
Chris Brown
Alasdair Manson <ali.m...@symbian.com> wrote:
>On Mon, 26 Apr 1999 22:30:35 +0100, cha...@pc.antipope.org (Charlie
>Stross) wrote:
>
>>I can see *no alternative* to telling my readers
>>to avoid all EPOC/32 machines like the plague, because there is *no way*
>>of converting EPOC/32 documents into something useable on a Linux system.
>
>While I know it's far from ideal, are Linux applications not able to
>use text files and delimited data files?
How do I inline an image in a text file? How do I preserve bullet
points and paragraph styles>
Chris Brown
Apart from the cost of Windowws + VCC + the EPOC SDK + possibly a
machine to run it all on.
Chris Brown
Ajai Khattri <aj...@ibm.net> wrote:
>On Tue, 27 Apr 1999 04:30:23 GMT, se...@plethora.net (Peter Seebach)
>wrote:
>
>>Yes, but the Palm people are open and encouraging of third parties. If
>>they had a machine with a keyboard, Psion would have very little to offer
>>people who aren't registered Microsoft citizens.
>
>Don't you think this is an oversimplification on your part?
>EPOC32 has many unique features that would not apply to the PalmOS.
He wasn't talking about EPOC, he was talking about Psion.
>>As is, the Psion is an interesting toy, but I have to use CF cards for
>>backups, or send files as typeless raw data, because some *MORON* thought
>>it would be a brilliant idea not to have a file format.
>
>We have a stream format instead - which is a good idea. It doesn't fit
>into your cosy traditional file formats world and so you call it
>moronic!
There is clearly a problem. It's fine having some clever file format
which does all kinds of wonderful things, but you have to be able to
talk to the rest of the world too. There appears to have been a design
decision made that it was acceptible to have a mobile computer which
required tethering to a Windows machine running proprietary software
to offer any remotely useful data interchange facilities. I think this
was a bad decision. Requiring connection to another computer before
you can talk to anything else, such as a printer, or a palmtop of a
different kind, in any kind of useful way makes a mockery of the whole
idea of mobile computing. Requiring that machine to be one running
Windows is, IMO, an even greater folly.
A stream format may well be a good idea. A stream format with no
ability to translate into something the rest of the World understands
is a really *bad* idea. The Series 5 only just fits in my pocket as it
is. I cannot carry my desktop around as well (which, incidentally,
runs Solaris), and you don't tend to find many 3 pin outlets in the
middle of nowhere, or on moving trains.
Charlie Stross
>>Look, I write a magazine column about Linux. In my next column I'm going
>>to be talking about PDAs. I can see *no alternative* to telling my readers
>>to avoid all EPOC/32 machines like the plague, because there is *no way*
>>of converting EPOC/32 documents into something useable on a Linux system.
>
>Apart from writing programs that run on the S5 itself...
Correct. Now I look around, and I ask, "where are these programs?" Nobody
seems to have written a native S5-hosted Word-to-RTF filter. I may be
wrong -- I hope I am -- but if I'm correct, it implies, well, Symbian
basically shrugging and saying "feel free to pay us a couple of hundred
quid for the development system then do all the work yourself".
>>But Symbian/Psion's attitude to non-Windows platforms is so bad that
>>they're turning one of their fans -- me -- into a carping critic who will
>>advise people to use a Palm Pilot instead.
>
>I also program on Linux systems a lot but there's no way I would not
>recommend an S5 to someone purely because there is no Linux version of
>PsiWin. You sound too much like a Linux zealot and less like someone
>who is looking at what a person uses a PDA for and what sort of
>platform they want to interface with. You can't assume that everyone
>is using Linux or will even want to connect their computers to their
>PDA.
Correct. I am only making recommendations for people who (a) run Linux
(as opposed to other systems) and (b) are looking for a PDA to use as a
companion machine for their Linux system. (I _am_ recommending the 3MX
as a good buy, by the way.) I _can't_ say, "go buy a Series 5 -- you'll
have to reboot into Windows to get data on or off it, but hey, that's
life!" because that's not what my column is about.
>>Not providing open APIs is damaging to their credibility outside their own
>>captive vertical market. It may have seemed reasonable to ignore the
>>non-Windows world in 1996-97, but it is _not_ reasonable today; if Linux
>>continues its current growth it will be bigger than Windows NT and MacOS
>>combined in less than eighteen months, and you ignore the second-largest
>>computing platform at your peril.
>
>Whilst this may or may not happen (7 million Linux users is not much
>when compared with 90 million Windoze users), Ill believe it when I
>see it.
It's not seven million any more. That figure was touted by Bob Young of
Red Hat about a year to fifteen months ago. Even IDC believe the user base
has grown by > 200% in the past year. Even if we assume that Mr Young was
over-estimating by about 50%, we see a user base of 7-10 million now,
and 15-25 million by the end of 1999. Witness Compaq, Dell, IBM, HP and
sundry other big names jumping on the bandwagon.
>I am not against Linux being successful but you can't run a
>business on "maybe's" - only the big guys (IBM, Compaq, etc) can
>afford to do that.
The business I work for (when I'm not writing a Linux column) runs on
Linux servers. It is not an ISP; these servers are doing mission-critical
financial transaction processing of amounts measured in the millions of
pounds per month (now -- growing rapidly to an expected turnover in the
hundreds of millions range in a year or two). This looks like a fairly
successful commercial application to me ...
-- Charlie
Charlie Stross
as <aj...@ibm.net> declared:
>We have a stream format instead - which is a good idea. It doesn't fit
>into your cosy traditional file formats world and so you call it
>moronic!
Um. Having a stream store isn't bad, in and of itself.
Not providing a way to map the stream store into some more generic format,
and *providing access to it on the machine itself*, is IMO a weakpoint.
(Put it another way; if Psion had built the file format translators that
are bundled in PsiWin into the Series 5 itself, I'd have no hesitation
recommending it as usable with non-Windows OS's. And as I understand it,
those translators rely on being linked to a cut-down version of EPOC/32
that runs on the PC platform anyway.)
-- Charlie
John Forrest
Chris Brown <Chris.omitt...@arm.andthisbit.com> wrote in message
news:7g6mb5$q...@sis.cambridge.arm.com...
> In article <3737b069....@news.compuserve.com>,
> Ajai Khattri <aj...@ibm.net> wrote:
> >On Sat, 24 Apr 1999 00:51:33 +0200, "Alan Morris, G4ENS"
> ><al...@mainline.co.uk> wrote:
> >
> >>There was a time when developers needing to enhance their product's file
> >>structures would issue a conversion .EXE file.
> >>
>
> Apart from the cost of Windowws + VCC + the EPOC SDK + possibly a
> machine to run it all on.
There are two, really separate issues, here:
1. The EPOC development route is tied to Windows.
2. The main conversion route is currently EPOC Connect, which is tied to
Windows.
The reason they are both tied to Windows is probably for similar reasons -
like Psion decided it was a good way forward. However they are not tied at
the hip, as it were. I doubt whether a non-Windows development route is in
the offing - I don't think the benifit would justify the expense, as I don't
think many commercial developers (who are Symbian's main target) are that
bothered.
The conversion route is different. You keep harping on that the problem is
the lack of documentation about the file format. That is not really true.
The problem is the lack of Psion based convertors. If you had convertors on
the Psion you would not be moaning about not being able to convert under
Linux - the latter is but one theorectical solution to the problem, and had
best be viewed as unfeasible.
John
Anthony Hook
> Whilst this may or may not happen (7 million Linux users is not much
> when compared with 90 million Windoze users),
But that's only part of the whole picture. You can't just go on current
figures, you need to look at the trend. Linux is growing in popularity
much faster than Windows and potential is the main key here. Also, a far
higher proportion of those Linux users would be looking for connectivity
to a Psion IMO, as I can't envisage WinCE being UNIX-friendly any time
soon, and Linux users will also have higher demands than the average
Windows user, where the vast majority are mere novices; and so would be
more inclined to take advantage of what a PDA has to offer.
This holds true also for Apples. The average Apple user will be more
computer literate than the average Windows user, and will have higher
demands. So more of them on average are continually looking to improve
productivity (which is where the Psion comes in). And again, WinCE would
be out of the scene here also, so even more would be fixating on the
Psion.
So in short, a high percentage of a small percentage (for Linux users say)
won't be a world away from a small percentage of a large percentage
(Windows users). If you get my meaning :-)
... Anthony
Chris Brown
John Forrest <j.fo...@dial.pipex.com> wrote:
>
>The conversion route is different. You keep harping on that the problem is
>the lack of documentation about the file format.
I think you have your attributions confused.
Niel Markwick
>
> Alasdair Manson <ali.m...@symbian.com> wrote:
> >On Mon, 26 Apr 1999 22:30:35 +0100, cha...@pc.antipope.org (Charlie
> >Stross) wrote:
> >
> >>to avoid all EPOC/32 machines like the plague, because there is *no way*
> >>of converting EPOC/32 documents into something useable on a Linux system.
> >
> >use text files and delimited data files?
>
> How do I inline an image in a text file? How do I preserve bullet
Hence the 'Far from ideal'... (and anyway, the reply was referring to the assertion that there is no way of producing 'something useable', and IMHO, plain text is still 'usable')
From the forcefullness of some peoples replies, anyone would think that this is a really emotive subject that would change the world as we know it, reduce poverty, prevent famine etc etc etc...
I know that we all love our Psions; I know that a lot of us would like some form of file conversion to an externally readable form; I know that some of us would like the Microsoft empire to crumble into dust - and would rather have painful and obscene things done to them than use a <cringe> Windows PC </cringe> to convert a file... BUT I think people should have some perspective here...
Niel.
PS - Don't all linux people write in *roff anyway :-)
Chris Brown
Niel Markwick <mark...@sebb.bel.alcatel.be> wrote:
>I know that we all love our Psions; I know that a lot of us would
>like some form of file conversion to an externally readable form; I
>know that some of us would like the Microsoft empire to crumble into
>dust - and would rather have painful and obscene things done to them
>than use a <cringe> Windows PC </cringe> to convert a file... BUT I
>think people should have some perspective here...
It's not a question of not wanting to use a Windows machine or not,
it's a question of not *having* a windows machine handy (let alone one
running Psiwin) when you bump into someone with A.N.other palmtop and
want to exchange data with them, or, heaven forbid, print something on
the move using a font other than 10 point Courier. The usefulness of
the Series 5 as a *mobile* computing solution is severely limited
because it is really quite dreadfully bad at certain important things
(such as data transfer and printing) unless it's tethered to a great
big, non-pocketable Windows machine.
>PS - Don't all linux people write in *roff anyway :-)
It's not just the Linux crowd. In my main computing capacity, I'm a
Solaris user.
Charlie Stross
> .... The usefulness of
>the Series 5 as a *mobile* computing solution is severely limited
>because it is really quite dreadfully bad at certain important things
>(such as data transfer and printing) unless it's tethered to a great
>big, non-pocketable Windows machine.
'Zackly.
I use my 3MX (and the 3A before it) as a portable computer that just
happens to be very small.
It is _not_ simply a gadget that I can carry a contact book around on
and refresh periodically from my desktop machine.
As a miniature portable computer, the 3MX is fine. As a miniature
portable computer, the Series 5 suffers by comparison.
-- Charlie
Peter Seebach
Steve Waddicor <steve.w...@virgin.net> wrote:
>Let me get this straight. Are you really and truly saying that you
>can't think of a reason other than the one you state above?
Not yet.
>What if I were to state that lack of a file format implies that only
>the engine that created a stream can legally modify the contents?
"legally"?
If you mean "it's too hard for other things to do it", then, yes, a lack
of a file format probably implies this.
>Would it then be fair to say that:
>You don't know of an argument that explains how the consumer
>(developer and end-user) can benefit from stream contents only being
>modifiable by the engine that created it.
Indeed.
Normally, this is called a "proprietary file format". It is a derogatory
term used to refer to something that denies the user the option of using any
other package.
This is seen as "bad", because it limits the user's choices.
>You're not aware of design wins to only allowing access to private
>data from the engine that owns it.
I am not aware of design wins of declaring that the text I have typed, and
the formatting I'd like for it, is "private data of the engine". I thought
*I* owned that text, but according to Psion/Symbian, that text, and its
formatting, is an exclusive property of the EPOC stream thing that encoded
it.
I wouldn't mind proprietary formats if the machine also supported open ones.
Alasdair Manson
Chris.omitt...@arm.andthisbit.com (Chris Brown) wrote:
>How do I inline an image in a text file? How do I preserve bullet
>points and paragraph styles
Hence my use of the phrase "I know it's far from ideal".
regards
Alasdair
A Symbian employee in a personal capacity
Alasdair Manson
Stross) wrote:
>but I imagine similar problems
Indeed. Thanks for your post.
Paul Vigay
<URL:mailto:aj...@ibm.net> wrote:
> I also program on Linux systems a lot but there's no way I would not
> recommend an S5 to someone purely because there is no Linux version of
> PsiWin. You sound too much like a Linux zealot and less like someone who is
> looking at what a person uses a PDA for and what sort of platform they want
> to interface with. You can't assume that everyone is using Linux or will
> even want to connect their computers to their PDA.
Exactly. I'm an Acorn RISC OS user (also ARM based) and instead of slagging
off Psion because they didn't write a Psion 5 <> RISC OS transfer program I
sat down and wrote one myself (http://www.matrix.clara.net/Acorn/psion.html )
I'm sure there is also a Linux link as well.
--
Paul Vigay
__\\|//__ Computer Resources Manager,
Web: http://www.matrix.clara.net (` o-o ') Bohunt Community School
BBS: +44 (0)1705 871531 (ansi,8n1) ---ooO-(_)-Ooo---- Liphook, Hampshire
All views my own and I reserve the right to change them without warning!
Peter Seebach
Paul Vigay <pvi...@bohunt.demon.co.uk> wrote:
>Exactly. I'm an Acorn RISC OS user (also ARM based) and instead of slagging
>off Psion because they didn't write a Psion 5 <> RISC OS transfer program I
>sat down and wrote one myself (http://www.matrix.clara.net/Acorn/psion.html )
>I'm sure there is also a Linux link as well.
You can transfer files with zmodem - in fact, that's how my Psion stays
attached to the world, through my NetBSD laptop. (Which, I'll point out,
can also serve as a PPP server.)
But it'd be really nice if you were *allowed* to have file converters, but
the wise people at Psion have realized we are not ready for that power.
Keld Laursen
>On Tue, 27 Apr 1999 09:36:15 +0200, "Keld Laursen" <k...@mse-dk.com>
>wrote:
[snip]
>>in order to cross-compile these to other
>>platforms?
>
>Since the application engine libraries are also available under WINC,
>you could use the EPOC Connectivity SDK to access S5 documents via the
>same APIs as in the S5 application engines.
>
>The only problem with this scheme is that third-party programmers may
>not be willing to supply you with a WINC version of their application
>engine.
We all know that WINC is there, and the EConnect package can convert. The
problem is that WINC have problems running on a lot of the "esoteric" OS's
targeted in this thread.
It seems like the best way would be to write a, more or less, unified
conversion program with file transfer via FTP or other protocols directly on
the S5.
Best regards,
Keld Laursen
Niel Markwick
>
> The text files the Series 5 Word application creates are broken
Copy/paste from word to a text editor works well.
There are now several freeware/shareware text editors for the S5, some having features to wrap paragraphs neatly.
> I didn't try delimited data files, but I imagine similar problems would
> be encountered in importing/exporting them.
Well, if you did, you would find that creating delimited text works fine from Data - in fact it is one of the well-known ways (at least it is in this newsgroup) of copying Data entries, or resizing fixed-length text fields.
Although there is no Export from sheet, again copy-paste into a text editor produces very nice TSV files (although only the 'displayed' data is copied - all formulae are lost - but I think you might find this the case when converting from Excel to TSV/CSV)
Niel.
PS: You were going to tell your readers that "there is *no way* of converting EPOC/32 documents into something useable on a Linux system" when you "didn't try delimited data files"? Hmmm... Maybe you only meant _word_ documents...
PPS: You do know about the Linux port to the Psion S5? (see http://www.calcaria.net) I would say that is a very good reason for readers of a Lunix publication to choose an S5...
--
Niel Markwick
Kontich, Belgium.
Michael Fellhauer
: -s
: --
: Copyright 1999, All rights reserved. Peter Seebach / se...@plethora.net
: C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
: Will work for interesting hardware. http://www.plethora.net/~seebs/
: Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
Oh gee, I just broke the copyright law. <slap> <slap>
You can't copyright messages in a public domain forum.
Gareth McCaughan
[Peter Seebach's signature says:]
There's no such thing as a "public domain forum", and Peter Seebach
can copyright his messages if he wants to. (I'm not sure he gains
much by it, though.) The mere fact of being widely distributed does
not stop something being copyright.
--
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
gj...@dpmms.cam.ac.uk Cambridge University, England.
Matt Gumbley
>
> In article <373db793....@news.compuserve.com>,
> Ajai Khattri <aj...@ibm.net> wrote:
> >We have a stream format instead - which is a good idea. It doesn't fit
> >into your cosy traditional file formats world and so you call it
> >moronic!
>
> which does all kinds of wonderful things, but you have to be able to
> talk to the rest of the world too. There appears to have been a design
> decision made that it was acceptible to have a mobile computer which
> required tethering to a Windows machine running proprietary software
> to offer any remotely useful data interchange facilities.
Aha! you said "Clever File Formats" - you are JF Mezei, I claim my ten
pounds :-)
Aren't the problems here that:
* Each object serialises its data, but doesn't identify its class in the
stream as being the creator of the data
* The chunk of data serialised by the object doesn't have a length field
at the start
* We don't know the serialisation formats of the objects
So the file looks like a clump of random bytes. If there was a header to
each serialisation, we might stand a chance...
How might we attack the problem?
Write test programs on the emulator (or for the real 5, if you're lucky)
that instantiate objects used by these applications, and write them out
to disk, then analyse the files and determine the file size and
serialisation format.
Once you've done that for all the objects in the application, derive the
overall document structure...
Of course, I bet we can't instantiate an application's objects - we
don't have the source to (say) Word ;-)
We're not so much tied to Windows, as to any platform that Symbian port
the document classes to, so, if they were to release the source (gasp!)
to these, we could see the individual serialisation methods and the
format of their output...
Just some random thoughts.... not that I've investigated the stream
store implementation at all: the eval SDK CD is in the middle of a large
stack of CDs on my desk awaiting investigation!
--
Matt J. Gumbley, Software Engineer | Enigma Data Systems Ltd.
Email: mgum...@enigmadata.co.uk | Chelsea House, 8-14 The Broadway,
Tel: +44 (0)1444 476500 | Direct: | Haywards Heath, West Sussex.
Fax: +44 (0)1444 476501 | 476510 | RH16 3AP England.
Matt Gumbley
>
> In article <373bb558....@news.compuserve.com>, Ajai Khattri
> <URL:mailto:aj...@ibm.net> wrote:
>
> > I also program on Linux systems a lot but there's no way I would not
> > recommend an S5 to someone purely because there is no Linux version of
> > PsiWin. You sound too much like a Linux zealot and less like someone who is
> > looking at what a person uses a PDA for and what sort of platform they want
> > to interface with. You can't assume that everyone is using Linux or will
> > even want to connect their computers to their PDA.
>
> off Psion because they didn't write a Psion 5 <> RISC OS transfer program I
> sat down and wrote one myself (http://www.matrix.clara.net/Acorn/psion.html )
> I'm sure there is also a Linux link as well.
There are two that I know of: Philip Proudman's, and my own efforts.
Philip's is working, mine is, er, well, calling it "research" is
probably the kindest way of describing it.
Peter Seebach
Gareth McCaughan <gj...@dpmms.cam.ac.uk> wrote:
>Michael Fellhauer wrote:
>[Peter Seebach's signature says:]
>>: Copyright 1999, All rights reserved. Peter Seebach / se...@plethora.net
>>: C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
>>: Will work for interesting hardware. http://www.plethora.net/~seebs/
>>: Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
>> Oh gee, I just broke the copyright law. <slap> <slap>
[rofl]
>> You can't copyright messages in a public domain forum.
>There's no such thing as a "public domain forum", and Peter Seebach
>can copyright his messages if he wants to. (I'm not sure he gains
>much by it, though.) The mere fact of being widely distributed does
>not stop something being copyright.
The message actually changes nothing. You automatically have copyright of
anything you write, and "all rights reserved" hasn't had any effect on
anything since Berne was adopted.
And, of course, it's trivially obvious that quoting is "fair use".
Honestly, the only reason that's still in the .signature is that it
acts as a magnet for people who need something they don't understand to
make fun of. ;)
-s
--
Peter Seebach
Matt Gumbley <mgum...@enigmadata.co.uk> wrote:
>Aren't the problems here that:
>* Each object serialises its data, but doesn't identify its class in the
>stream as being the creator of the data
>* The chunk of data serialised by the object doesn't have a length field
>at the start
>* We don't know the serialisation formats of the objects
That seems like the right sort of thing.
>So the file looks like a clump of random bytes. If there was a header to
>each serialisation, we might stand a chance...
And it would make disaster-recovery a much more plausible task, too.
John Forrest
Peter Seebach <se...@plethora.net> wrote in message
news:sr0W2.1849$WA4.3...@ptah.visi.com...
> In article <37287F35...@enigmadata.co.uk>,
> Matt Gumbley <mgum...@enigmadata.co.uk> wrote:
> >Aren't the problems here that:
> >* Each object serialises its data, but doesn't identify its class in the
> >stream as being the creator of the data
> >* The chunk of data serialised by the object doesn't have a length field
> >at the start
> >* We don't know the serialisation formats of the objects
>
> That seems like the right sort of thing.
There is not strictly speaking a correlation between the data format and the
objects - ie there is not a one-one mapping. Given (say) a list of strings I
can think of about 10 ways of Storing the data. I could probably come up
with more if I had to.
>
> >So the file looks like a clump of random bytes. If there was a header to
> >each serialisation, we might stand a chance...
>
> And it would make disaster-recovery a much more plausible task, too.
Psions are space efficient (that is one of its features). You get this
efficiency by leaving out redundant extra stuff. If you want error recovery,
you need redundancy and hey presto theres goes the efficiency. They are not
entirely without headers (you still have streams).
My guess is that 99.9% of users prefer the efficiency.
John
Peter Seebach
John Forrest <j.fo...@dial.pipex.com> wrote:
>Psions are space efficient (that is one of its features). You get this
>efficiency by leaving out redundant extra stuff. If you want error recovery,
>you need redundancy and hey presto theres goes the efficiency. They are not
>entirely without headers (you still have streams).
>
>My guess is that 99.9% of users prefer the efficiency.
I don't think headers would be a particularly space-inefficient thing to have
in a data format. Most real-world data formats use them precisely because
they make it a lot easier to generate a reliable parser, and/or to share the
data. One of the problems you tend to have is that a new version of a program
needs some way to reliably identify that a file is from the old version, so
it can read it correctly. Headers solve that too.
John Forrest
> In article <7ga85v$r0k$2...@lure.pipex.net>,
> I don't think headers would be a particularly space-inefficient thing to
have
> in a data format. Most real-world data formats use them precisely because
> they make it a lot easier to generate a reliable parser, and/or to share
the
> data. One of the problems you tend to have is that a new version of a
program
> needs some way to reliably identify that a file is from the old version,
so
> it can read it correctly. Headers solve that too.
The stream format solves both these problems without headers.
John
Peter Seebach
John Forrest <j.fo...@dial.pipex.com> wrote:
>The stream format solves both these problems without headers.
I'm interested in knowing how; after all, given a stream of data, how *do*
you tell what it is, or what version it is, without something that is really
a header?
John Forrest
> In article <7gahc5$895$1...@lure.pipex.net>,
> John Forrest <j.fo...@dial.pipex.com> wrote:
> >The stream format solves both these problems without headers.
>
> I'm interested in knowing how; after all, given a stream of data, how *do*
> you tell what it is, or what version it is, without something that is
really
> a header?
Well it all depends what you call a header. But (as we keep saying) it all
depends on the stream ids - you just ask if a particular stream is present
by UID. (The alternative approach is to put a byte with the version in a
non-indexed stream, and some EPOC programs use that). If you call that a
header, then EPOC stream stores have headers, but I doubt that is what you
are talking about.
John
Peter Seebach
Steve Waddicor <steve.w...@virgin.net> wrote:
>>If you mean "it's too hard for other things to do it", then, yes, a lack
>>of a file format probably implies this.
>No, I mean as in if you use the Public Interface / Public Data, that's
>legal (in the software engineering sense). If you use private data
>you might break the data/the app won't work with the next version/you
>might as well shoot yourself in the foot.
True. Wouldn't it be nice if there were public data? Or, for that matter,
if the public interface were well enough documented for other people to
cooperate with it?
>So, as far as I can see, you're saying you are *not* aware of the
>software engineering arguments for private data in stream stores, but
>you *are* prepared to call it "bad". And with your limited knowledge
>of the arguments for and against, you're willing to call the designers
>of the technology "morons". Is that a fair summary so far?
I am aware of lots of arguments for having stream stores which *may* contain
private data - but none for deciding that there will be no public data. Not
software engineering arguments, anyway.
The end question of any engineering is, how does this work for the customer?
If one choice means "customer can share data freely", and one means "customer
cannot share data freely", you need a fairly obvious and powerful argument to
pick the first one.
The only widespread exception is Microsoft; they're allowed to pick a
proprietary format and try to make sure no one reads it... And even that
seems to be going out of favor.
So, tell us. Maybe my SE background just isn't as good as yours.
What *DO* we gain from having private-only stream formats? What gain is there
to me, the user of the box, from the committment that nothing other than
Psion's software can ever read my data?
>>I wouldn't mind proprietary formats if the machine also supported open ones.
>I think you're getting a bit closer to the point now. The problem you
>have is not private stream stores, it's the lack of converters for
>Unix Systems.
No. It's the lack of the ability of third parties to make converters if they
wanted to, and it's the lack of converters to *arbitrary* third party systems.
It's gonna come as a complete shock, but you currently actively do not support
Linux, any kind of Unix, the Mac, the Amiga, the Acorn, the BeBox, the
Newton... in fact, *anything at all* other than Windows.
All you would need to do to fix this is document the current file format, and
agree to document future ones if and when they become available. Everyone
would be happy.
>The Series 5 makes it quite clear on the box what the
>connectivity is, and Unix isn't included.
Indeed. Neither is the Mac. In fact, when I got my box, neither was Win '98.
The point is, if I compare Psion and Palm, I see one company which apparently
does not see any merit in making it easy for third parties to work with them,
and one which has put a lot of effort into making it easy for third parties to
do so.
Yes, indeed, I could just go get a Palm. I've thought about it. Right now,
your other features are important enough that I haven't...
But that doesn't mean you aren't alienating customer base, and I see no
advantage to you in doing this.
>As a specific point, let me remind you about when you first arrived on
>this group a few months ago, *before* you bought a series 5. I
>advised you that for your purposes, a Series 5 was not necessarily a
>good upgrade for a series 3. I also told you that connectivity was
>for Win9x/NT only. You claimed that didn't matter for you, as you
>only wanted it as a PDA, and then you went on to buy one regardless.
Yup. And, for a PDA, it's great.
Is it possible for someone to think that a decent thing could be made better?
I do it a lot. I use a Unix system. I'm happy with it - but I'd be even
happier if it were better.
Luckily, the people who make it allow me to do this. They document the things
I need to do to enhance my experience.
You see, "good product" isn't an all-or-nothing proposition. Often, no
product is ideal.
Psion could, with very little effort, make the world's best PDA. All they'd
have to do is realize that your trade secrets are coming at the expense of the
well-being of a significant number of customers.
Right now, your answer is "okay, well, they can get a Palm", and this shows;
they are, in fact, getting Palm systems, and you have no retail presence in
the U.S. that I can find. Anywhere.
It's *amazing* how quickly customers will take you up on the suggestion that
they go elsewhere.
Me, I'm a kook. I stay loyal to products that I think have good potential.
I was still using my Amiga until it finally died. I'm still using a Psion,
even though I think you've killed yourselves by refusing to interact with
the free world.
>Note that connectivity is with Win 9x/NT only.
Except that Psion advertises that there's a Mac package.
Note also: My Series 5 has software on it. That software was loaded, from
scratch, using Unix, because you *DO* actually support file transfer in a
standard protocol.
Note the word "standard" in there.
See, because you decided that Ymodem and Zmodem were good protocols, I can
still exchange data with any of five or ten flavors of Unix.
Imagine - if Series 5 word had RTF (and, since Series 3 did, this seemed like
a plausible guess - unfortunately a wrong one), there would be *NO COMPLAINT*.
For me, "export as RTF" would be good enough. There are lots of other
features I'd like, but just the RTF stuff I loaded on my 3a was *plenty*
to make it usable.
The Series 5 is, in many ways, a much better machine for me. Much nicer
keyboard. Touch screen. Backlight. Better agenda (in most respects; I
miss "show items with priority over N in other views").
I just wish that Psion hadn't decided that open systems and unencumbered
file formats were a bad idea, not to be tolerated.
Peter Seebach
Steve Waddicor <steve.w...@virgin.net> wrote:
>On Thu, 29 Apr 1999 21:41:15 GMT, se...@plethora.net (Peter Seebach)
>wrote:
>>I'm interested in knowing how; after all, given a stream of data, how *do*
>>you tell what it is, or what version it is, without something that is really
>>a header?
>A UID per stream. That identifies it as definitely as an IP number.
So, you have a very small header which only contains enough information to
tell the libraries which of several template-headers to use. ;-)
Makes sense, actually. I'd prefer a more verbose format, but then, I'm a
big fan of as-readable-as-possible file formats, because I read binaries
as a hobby.
John Forrest
Steve Waddicor <steve.w...@virgin.net> wrote in message
news:372be3c1...@news.virgin.net...
> On Thu, 29 Apr 1999 16:48:05 +0100, Matt Gumbley
> <mgum...@enigmadata.co.uk> wrote:
>
> >Of course, I bet we can't instantiate an application's objects - we
> >don't have the source to (say) Word ;-)
>
Before anybody gets too excited, the source IIRC is an early version.
John
Ajai Khattri
wrote:
>But that's only part of the whole picture. You can't just go on current
>figures, you need to look at the trend. Linux is growing in popularity
>much faster than Windows and potential is the main key here.
Yes, but again, if I were running a business that sold software I
would probably approach Linux with much more caution. Band wagons come
and go...
>soon, and Linux users will also have higher demands than the average
>Windows user, where the vast majority are mere novices; and so would be
>more inclined to take advantage of what a PDA has to offer.
But in order for Linux to be popular, there is the implication that it
has to appeal to the novice user. Thus you *will* see more novice
users on Linux as you describe above for Windoze.
>This holds true also for Apples. The average Apple user will be more
>computer literate than the average Windows user, and will have higher
Actually, I have found the opposite to be true. Mac users don't have
to know much about their computers to use them. As someone who has
done desktop support for a few years, I can't tell you how many times
Ive had to explain what a directory is or what a serial port is to a
Mac user. Mac users tend to be harder to support because they know
even less about their machines than Windoze users! (No offence to Mac
users but this has been my personal experience doing technical support
for several companies).
--
Aj. (aj...@ibm.net)
Ajai Khattri
Chris.omitt...@arm.andthisbit.com (Chris Brown) wrote:
>I think this
>was a bad decision. Requiring connection to another computer before
>you can talk to anything else, such as a printer
You don't need a desktop to print - get a printer cable.
>or a palmtop of a
>different kind,
True - but do Palm Pilots talk to WinCE devices?
>in any kind of useful way makes a mockery of the whole
>idea of mobile computing. Requiring that machine to be one running
>Windows is, IMO, an even greater folly.
You don't need Windows to print or do backups - there are alternatives
for this.
>A stream format may well be a good idea. A stream format with no
>ability to translate into something the rest of the World understands
>is a really *bad* idea.
What we need is software that runs on the S5 that does some
conversions. IMHO, this should have been put into a new ROM and
offered to customers. The stream format is a good idea.
--
Aj. (aj...@ibm.net)
Ajai Khattri
Stross) wrote:
>Um. Having a stream store isn't bad, in and of itself.
>
>Not providing a way to map the stream store into some more generic format,
>and *providing access to it on the machine itself*, is IMO a weakpoint.
Can you persuade someone to write a Word OPX for you? That is really
all you need.
>(Put it another way; if Psion had built the file format translators that
>are bundled in PsiWin into the Series 5 itself, I'd have no hesitation
>recommending it as usable with non-Windows OS's.
Assuming a user *wants* to use it with their desktop computer (let
alone a non-Windows OS).
>And as I understand it,
>those translators rely on being linked to a cut-down version of EPOC/32
>that runs on the PC platform anyway.)
Not exactly - but the same libraries that run in ROM are available as
WINC libraries. This includes the App. Engine API which allows you to
access documents from Sheet, Word, etc.
--
Aj. (aj...@ibm.net)
Ajai Khattri
<mgum...@enigmadata.co.uk> wrote:
>Of course, I bet we can't instantiate an application's objects - we
>don't have the source to (say) Word ;-)
Well, as an EPOCWorld member, actually I do...
The early SDKs came with the source for Sketch, but then they switched
to offering Word instead ;-)
--
Aj. (aj...@ibm.net)
Ajai Khattri
wrote:
>>What if I were to state that lack of a file format implies that only
>>the engine that created a stream can legally modify the contents?
>
>"legally"?
>
>If you mean "it's too hard for other things to do it", then, yes, a lack
>of a file format probably implies this.
What Steve meant by "legally" was in the object-oriented sense. An
object cannot inspect or modify the private members of another object.
This is standard OOP programming. The object itself should take care
of its own data when asked to do so.
>Normally, this is called a "proprietary file format". It is a derogatory
>term used to refer to something that denies the user the option of using any
>other package.
In my books, proprietary means anything not using any documented
standard. So yes the stream format is proprietary in that sense -
though this was done for space/efficiency reasons.
>This is seen as "bad", because it limits the user's choices.
Ironically, M$ has built a whole market on this concept ;-)
--
Aj. (aj...@ibm.net)
Ajai Khattri
Stross) wrote:
>It is _not_ simply a gadget that I can carry a contact book around on
>and refresh periodically from my desktop machine.
But for most people it *is* a contact book...
--
Aj. (aj...@ibm.net)
Matt Gumbley
>
> On Thu, 29 Apr 1999 21:41:15 GMT, se...@plethora.net (Peter Seebach)
> wrote:
>
> >In article <7gahc5$895$1...@lure.pipex.net>,
> >John Forrest <j.fo...@dial.pipex.com> wrote:
> >>The stream format solves both these problems without headers.
> >
> >you tell what it is, or what version it is, without something that is really
> >a header?
>
> A UID per stream. That identifies it as definitely as an IP number.
[Pardon my Stream Store ignorance; haven't read that white paper yet!]
What does the UID identify the stream against?
A class?
A particular version of a class? (in case serialisation formats change
between versions)
An object?
An application?
--
Matt J. Gumbley
John Forrest
Matt Gumbley <mgum...@enigmadata.co.uk> wrote in message
news:372975D2...@enigmadata.co.uk...
> [Pardon my Stream Store ignorance; haven't read that white paper yet!]
>
> What does the UID identify the stream against?
> A class?
> A particular version of a class? (in case serialisation formats change
> between versions)
> An object?
> An application?
None of the above really. The main UID in the file or store identifies the
associated application. Most eikon apps used indexed stream stores - that is
what we are talking about (alternatives include using a single stream, or
some sort of list based arrangement where the stream indexes are used like
pointers). In an indexed store, the streams are looked up by UID. The app
will know the UIDs to lookup, but what it then does with the data in the
streams is up to it. One implication of this is that you can change the
internal data organisation without having to change the data. There is no
one-one mapping between external and internal data organisation. It is
completely up to the program code - although typically objects are dumped
using a single ExternalizeL call, and thus you do tend to get related fields
adjacent in the streams.
John
Peter Seebach
Ajai Khattri <aj...@ibm.net> wrote:
>You don't need Windows to print or do backups - there are alternatives
>for this.
True - although I don't know of a good way to get output out of Word; at least
with the printer I've tried, there's no fonts, and it doesn't support
Postscript anymore. (S3a did, as I recall.)
>What we need is software that runs on the S5 that does some
>conversions. IMHO, this should have been put into a new ROM and
>offered to customers. The stream format is a good idea.
I mostly agree; certainly, if Word could print as PS and export as RTF, and
the other programs similarly supported at least one *external standard* for
representing their data, I'd be very happy.
Peter Seebach
Ajai Khattri <aj...@ibm.net> wrote:
>Assuming a user *wants* to use it with their desktop computer (let
>alone a non-Windows OS).
I think it's important here to note that providing extra functionality does
not obligate people to use it, in general. The mere fact that "only a
minority of users want feature X" should not blind us to the fact that that
minority may be significantly affected by the availability of feature X - and
if there's enough values of X, you can alienate enough of a market that a
younger competitor can get ahead of you in market share in a couple of years.
Peter Seebach
Ajai Khattri <aj...@ibm.net> wrote:
>On Wed, 28 Apr 1999 13:46:13 +0100, Anthony Hook <a...@cs.bham.ac.uk>
>wrote:
>
>>But that's only part of the whole picture. You can't just go on current
>>figures, you need to look at the trend. Linux is growing in popularity
>>much faster than Windows and potential is the main key here.
>Yes, but again, if I were running a business that sold software I
>would probably approach Linux with much more caution. Band wagons come
>and go...
True. How convenient that Linux users can normally invent their own support
given only a little documentation.
Peter Seebach
Ajai Khattri <aj...@ibm.net> wrote:
>What Steve meant by "legally" was in the object-oriented sense. An
>object cannot inspect or modify the private members of another object.
Ahh.
>This is standard OOP programming. The object itself should take care
>of its own data when asked to do so.
Yes. It would be very nice if they did that.
>>Normally, this is called a "proprietary file format". It is a derogatory
>>term used to refer to something that denies the user the option of using any
>>other package.
>In my books, proprietary means anything not using any documented
>standard. So yes the stream format is proprietary in that sense -
>though this was done for space/efficiency reasons.
Ahh, but *documenting* it wouldn't have taken extra space or time on the
machine.
>>This is seen as "bad", because it limits the user's choices.
>Ironically, M$ has built a whole market on this concept ;-)
Indeed. It's very disappointing to see Psion using one of Microsoft's
most-reviled tactics.
R.O.J. Brunsting
<< I use my 3MX (and the 3A before it) as a portable computer that just
happens to be very small. >>
That's the way I use my Psion. Others carry IBM Thinkpads or Toshiba
Tecras but while I carry a Series 5.
<< As a miniature portable computer, the 3MX is fine. As a miniature
portable computer, the Series 5 suffers by comparison >>
With due respect, that's a judgment based on your personal usage. In
which file exchange with Linux applications is one of the activities. File
exchange with other applications will be of no importance to others. Being
able to write reports with embedded spreadsheet graphs being a more
important item to them. Psions have the capability to be used in various
ways and for different purposes.
I therefore think that you'd be doing the readers of your column a
disservice by telling them to avoid EPOC machine like the plague. As you'll
be pointing people away from a Series 5 (or Geofox One) that's far better
suited to their requirements than a Series 3mx. Describe the differences
between the two and let your readers make their own decision.
<< Not providing open APIs is damaging to their credibility outside their
own captive vertical market >>
A Series 5 Word file is a stream store accessible via an API. Word
uses this API to load the file. Strange thing is that nobody has yet built
an application that uses the same API to read a Word file and translate it
into an exchange format like RTF.
<< It may have seemed reasonable to ignore the non-Windows world in
1996-97, but it is _not_ reasonable today >>
You're making the mistake of confusing "absence of proof" with "proof
of absence". That Psion/Symbian hasn't created a Linux equivalent to PsiWin
doesn't mean that they're ignoring Linux altogether.
<< if Linux continues its current growth it will be bigger than Windows NT
and MacOS combined in less than eighteen months >>
It's not a question of how many Linux PCs there are versus Windows NT
PCs or Apple Macintoshes. The question is which computer a prospective
Psion customer uses. Linux has it's strengths in the server market but has
a long way to go before it's a viable consumer product. You can say about
Windows what you like. It can't be denied that Microsoft has spent enormous
effort in making Windows usable by Joe Public.
<< if I'm correct, it implies, well, Symbian basically shrugging and saying
"feel free to pay us a couple of hundred quid for the development system
then do all the work yourself" >>
I find this a very humorous remark, coming from a Linux person. Linux
evolves because there are people who actually *do* the work themselves.
That Linux supports certain hardware is thanks to people *purchasing* the
hardware and making things work. You don't have to compensate them
financially for their work as it's supplied for free. Linux is an excellent
operating system for the company of Scrooge & Marley. Pay for
development?!? Humbug!!!
<< The business I work for (when I'm not writing a Linux column) runs on
Linux servers. It is not an ISP; these servers are doing mission-critical
financial transaction processing of amounts measured in the millions of
pounds per month ... >>
Now, what would it actually cost you for turning your column into an
encouragement to developers for creating a Series 5 Word to RTF converter?
What would it cost your company to sponsor a keen developer by supplying
him/her with the development tools to do that job? How about giving
something back to those who've supplied your company with the means to do
business?
Kind Regards,
Rolf Brunsting - Delft - Netherlands
R.O.J. Brunsting
<< it's a question of not *having* a windows machine handy (let alone one
running Psiwin) when you bump into someone with A.N.other palmtop and want
to exchange data with them ... >>
That's something the whole palmtop and PDA industry should start to
think about. I may have a contact in my Series 5 database a PalmV user is
interested in. I can't transfer the contact details directly (via infrared)
as there's no common exchange mechanism. Nor can I transfer the dates of an
event, like an exhibition, that's in my diary to somebody with a different
machine and the interest to attend. You can't single out one manufacturer
in this respect.
<< ... or, heaven forbid, print something on the move using a font other
than 10 point Courier >>
You don't need a PsiWin PC to print as you can print directly to a
range of printers and use fonts other than 10 point Courier.
<< The usefulness of the Series 5 as a *mobile* computing solution is
severely limited because it is really quite dreadfully bad at certain
important things (such as data transfer and printing) unless it's tethered
to a great big, non-pocketable Windows machine >>
This is "from the armchair" type nonsense. I don't even have to write
that I "think" it's nonsense. Having used Psion palmtops as my *only*
mobile computer for over three years (also while traveling in various
countries) I *know* that it's nonsense. Take a computer on the road (any
computer) and you'll automatically encounter life's little
incompatibilities.
Peter Seebach
R.O.J. Brunsting <rbrun...@compuserve.com> wrote:
> A Series 5 Word file is a stream store accessible via an API. Word
>uses this API to load the file. Strange thing is that nobody has yet built
>an application that uses the same API to read a Word file and translate it
>into an exchange format like RTF.
It is rather strange; stranger still is that people who apparently able to
do development on Psion systems are having trouble getting it to happen.
Is there some reason for which it's not as easy as it sounds?
> You're making the mistake of confusing "absence of proof" with "proof
>of absence". That Psion/Symbian hasn't created a Linux equivalent to PsiWin
>doesn't mean that they're ignoring Linux altogether.
Considering how much news coverage Linux is worth these days, it's pretty
weird that the word doesn't seem to occur in any of their literature at all.
> It's not a question of how many Linux PCs there are versus Windows NT
>PCs or Apple Macintoshes. The question is which computer a prospective
>Psion customer uses.
True. PDA customers are more likely to be technically savvy, or even a bit
geeky, than regular customers. :)
>Linux has it's strengths in the server market but has
>a long way to go before it's a viable consumer product.
Define "viable". "Ordinary users could get one and use it", it's there now;
modern Linux systems are about as approchable as Windows, if not quite so
friendly as the iMac.
>You can say about
>Windows what you like. It can't be denied that Microsoft has spent enormous
>effort in making Windows usable by Joe Public.
True. It can be denied that they've succeeded. I hear an awful lot of Joe
Publics complaining about how hard it is to perform simple tasks on Windows.
> I find this a very humorous remark, coming from a Linux person. Linux
>evolves because there are people who actually *do* the work themselves.
Yup!
>That Linux supports certain hardware is thanks to people *purchasing* the
>hardware and making things work. You don't have to compensate them
>financially for their work as it's supplied for free. Linux is an excellent
>operating system for the company of Scrooge & Marley. Pay for
>development?!? Humbug!!!
Actually, this is untrue and unfair. A lot of the development work *is*
paid for. Some companies have funded development of drivers for their
hardware; many have donated samples to people who wanted to develop
support for it. A lot of the "free" software out there was funded
development.
This is pure capitalism in action; software doesn't cost anything to copy,
but it costs a lot to make, so you pay people to make it, not to copy it.
> Now, what would it actually cost you for turning your column into an
>encouragement to developers for creating a Series 5 Word to RTF converter?
It's a disservice to end-users to say "gee, all you have to do is a little
programming work and this will work nearly as well as the competition".
That's a poor review.
>What would it cost your company to sponsor a keen developer by supplying
>him/her with the development tools to do that job? How about giving
>something back to those who've supplied your company with the means to do
>business?
Historically, the free software community has been very good about this...
IF AND ONLY IF a given company has shown support or interest. When a company
limits its responses to the free software community to apathy and/or
hostility, it is unlikely to make friends.
So, for instance, there's more interest in developing Linux for the series 5,
than there is in making the Series 5 applications talk to Linux... Perhaps
because Psion decided to tell anyone who wanted to develop under anything
but windows that their work wasn't wanted.
Anthony Hook
> No. A public API is far superior in *so* many ways.
[big snip]
An interesting read Steve.
You're obviously right about encapsulation, but..
I still think a couple of DLLs for Linux/Apple capable of handling
EPOC stream-based files (just the lower level EPOC components) would be
useful. <ducks>
Including the API specs for the built-in apps made public to none
EPOCWorld members. If both aren't free then you won't entice those UNIX
hacks.
... Anthony
Peter Seebach
Steve Waddicor <steve.w...@virgin.net> wrote:
>On Fri, 30 Apr 1999 03:26:44 GMT, se...@plethora.net (Peter Seebach)
>wrote:
>>>No, I mean as in if you use the Public Interface / Public Data, that's
>>>legal (in the software engineering sense). If you use private data
>>>you might break the data/the app won't work with the next version/you
>>>might as well shoot yourself in the foot.
>>True. Wouldn't it be nice if there were public data?
>No. A public API is far superior in *so* many ways.
Call me a kook if you like, but I think a choice of approaches is often
better than no choice.
So, can someone with an SDK clarify: If there's a public API, why hasn't
anyone implemented a way to translate Word files into some other format?
Why was someone who apparently had an SDK talking about reading data formats
instead of using this API?
>>Or, for that matter,
>>if the public interface were well enough documented for other people to
>>cooperate with it?
>The public API is not as well documented as is could be, but there are
>people working on the next SDK release, which I hope will be an
>improvement. Meanwhile developers can, and do, ask questions on
>EpocWorld to fill in the gaps.
That's a good thing. I certainly hope the next SDK is an improvement; it
would improve the chances of someone implementing a few very handy features.
>>I am aware of lots of arguments for having stream stores which *may* contain
>>private data
>I think we might be getting somewhere now. What are these arguments?
In general, it is useful to be able to encode data which is not part of the
document, but which is meaningful only to a single application.
>> - but none for deciding that there will be no public data. Not
>>software engineering arguments, anyway.
>I am aware of lots of arguments for having stream stores which *only*
>contain private data.
Please advise.
>>The end question of any engineering is, how does this work for the customer?
>Some benefits of EPOC to the customer:
>* Easy to use.
>* Robust
>* Small
>* Fast
>* Good internationalisation support
>The Private-stream-store-with-public-API architecture contributes
>significantly to each of these benefits. Documenting the private data
>would compromise most of them.
I don't see how.
Imagine, for a moment, that you documented, byte for byte, the current format.
This documentation does not exist on the Series 5, nor would it.
The software on the Series 5 would retain its current ease of use. It would
not grow. It would not become slower. It would retain its current
durability. It would retain its current i18n support.
Now, *new software* might, potentially, be of lower quality.
I believe it is "fascist" (as in the jargon term used for things like Pascal,
not as in the governmental type) to declare that the consumer must not be
allowed to consume software that is less than ideal.
>>If one choice means "customer can share data freely", and one means "customer
>>cannot share data freely", you need a fairly obvious and powerful argument to
>>pick the first one.
>Take two applications. One accesses a file format directly. One
>manipulates information via a public API. On current machines they
>both work fine.
>Then along comes Bluetooth.
>The user enters data into the application using her PDA with a
>keyboard that she normally keeps in her briefcase. She want's to
>retrieve that data using her smartphone.
>Which application lets her do this? Which approach allows the user to
>share data freely? The one using the public API.
Indeed.
So, obviously, if she is given a choice, and she cares about future products,
she will prefer the API.
Should we declare that, given that in a hypothetical situation which may not
apply to her, she will prefer the API, she *must not have that choice under
any circumstances*?
My objection is not that Psion recommends a good solution; it is that it
rejects out of hand the possibility that other solutions might be good enough
to serve.
I would benefit, significantly, now, from an application which, through *ANY*
means, were able to decode Psion Word files. Even if it couldn't handle
embedded objects.
If I had the file format, I might be able to write one which was *good enough
for me*.
As is, I can't; the only way I can ever access the data is through an API
which is accessible only on one kind of machine, and which cannot be driven
by code anywhere else.
Let's try another hypothetical: Imagine that there are two programs which
can interact with a given piece of data. At the present moment, one runs
only on one of two pieces of proprietary hardware. The other can be run on
any computer which provides an ISO standard C compiler, and on many machines
for which a nearly-compliant implementation is. Our hypothetical executive
doesn't have bluetooth yet, but she's sharing an office with a variety of
people using a variety of platforms, and wishes to share data with them.
Which program will work better for her? The one which can run on multiple
platforms, *even though it may break on a future release*.
The ideal program is portable in both time and space. I would prefer one,
right now, portable in space - although I'd rather have one portable in both
if it were possible.
Peter Seebach
Steve Waddicor <steve.w...@virgin.net> wrote:
>They do. Absolutely and definately. Fill in your examples of when an
>object within EPOC does not take care of it's own data
>here........................................................
Hmm. Okay, how does the Word object export its data in an industry standard
format?
Oh, it doesn't?
I guess it's not taking very complete care of its data.
;)
>Whoops, you've missed it. Aj just hit you on the head with a big
>cluestick with one of the advantages of private data, and you've
>carried on quite oblivious to it. If the private stream store were
>documented it wold have a hit on space/efficency because ............
>[fill in the blank].
Because nothing. It might in the future *if and only if you committed to
preserving that functionality*. (And, in fact, you have to anyway; otherwise,
the Series 5mx can't read my old Series 5 Word documents.)
I'm still not seeing any way in which the availability of information outside
your software changes the performance or size of your software.
>I assume you mean "Symbian" unless there is a line of hardware that
>Microsoft make that I am unaware of. As to tactics, in what way do
>you believe it's in Symbian's commercial interest to deliberately
>restrict connectivity to other platforms? Maybe there's a argument
>I'm missing here?
I don't. But I don't think it's in MS's interest - I think they're guessing
wrong.
>For what it's worth, we positively encourage developers to produce
>connectivity solutions using the public APIs. We have developers who
>have done just that. In general they do it for the Windows platform,
>because it's easier, and there's more commercial incentive, but I am
>aware of a Linux connectivity app in development using the public
>APIs.
Hmm. Any more information on it? I would be fairly interested in such
an application. (Despite the fact that, as it happens, Linux is at best
a tertiary platform for me. No problem; I can run Linux apps on my NetBSD
machines, because Linux has a very well-document set of assumptions.)
Peter Seebach
Steve Waddicor <steve.w...@virgin.net> wrote:
>I note that you have chosen to silently snip the main body of my
>posting.
Mea culpa; I saw the line of "---"'s before it, and thought it was
the end of the post, and deleted "the rest of the post", which I assumed
was a .signature.
>Under these circumstances I'm not sure we can have a
>constructive discussion. You need to understand and accept the big
>picture, before the detail makes sense.
I'm not convinced this is always the case; I believe a counterexample is
stronger than any theory, no matter how big and well-argued the theory.
Anyway, I'll try to get back to your other points, but I'd appreciate it
if you could talk to me about the small subset of them I did talk about.
Peter Seebach
Steve Waddicor <steve.w...@virgin.net> wrote:
>>Because nothing. It might in the future *if and only if you committed to
>>preserving that functionality*. (And, in fact, you have to anyway; otherwise,
>>the Series 5mx can't read my old Series 5 Word documents.)
>Is that a fact? You seem very sure? How does Unicode fit in to your
>argument?
I am unable to find any way in which external documentation causes code to
grow. Preserving compatability with an existing format requires the same
amount of code no matter how many people know about the existing format.
I'm not seeing the relevance of Unicode.
>Just because you don't see it, does not make it untrue. I'm unwilling
>to write an essay to fill you in on missing knowledge.
I dunno. I've bounced this off a fair number of developers, many of them
much more into OO than I am.
None of them see the connection.
>Let me instead
>give you a pointer: Object Oriented Analysis and Design by Grady
>Booch. In particular see Chapter 1: Complexity, and the Encapsulation
>section of Chapter 2. Once you've had a good read (it *is* a good
>book.)
Read it.
>Think about how encapsulation meshes together with robustness,
>validation, efficiency, and compatibility between versions.
Beautifully.
So, it is very important, when writing code that needs robustness, needs
validation, wants to be efficient, and wants to maintain compatability,
to respect that encapsulation.
However: That doesn't mean that the documentation makes anything worse.
It allows other people to write code which is, perhaps, lest robust, and
which is certainly not likely to maintain compatability.
The existance of that program has *NO EFFECT* on the speed or size of
your existing program.
>If you're not willing to put the time into learning about the subject,
>you could just take the word of someone who deals with this stuff
>everyday.
I could - but I deal with a lot of this stuff every day. I have come to
different conclusions than you. In particular, I believe that it is desirable
to allow people to write lower quality code, if they wish to, as long as I
don't have to maintain their code. :)
The Word program in the ROM of my Series 5 will not gain or lose a single
byte of size from the ability of a third party to decipher its stream stores.
It might suffer if, for instance, I expected all future versions of Word to
read the pseudo-correct stream stores generated by third party applications.
I do not.
If you gave me that data format, and I were able to read the output of the
Word document writer in the ROM of my existing computer, I would be better
off than I am now.
It seems to me that the argument you're making is, essentially, dependant
on the assumption that people will expect you to forever work with any program
that works with any given Psion.
Come to think of it, I see where you'd get that.
Okay, I'll grant this point: With the consumer market you work with, you
might face significant and unacceptable penalties from documenting your stream
formats.
I do not believe this is a result of the documentation, I believe it's a
result of unrealistic expectations from the user community - but I have to
admit, I have observed those expectations, and I expect they'll be around
forever.
R.O.J. Brunsting
<< Considering how much news coverage Linux is worth these days, it's
pretty weird that the word doesn't seem to occur in any of their literature
at all >>
I do wonder how many of the journalists writing about Linux are
actually using a Linux machine themselves. One who does, and who's column I
regularly read, is David Evnull. He has quite strong reservations about
what the media have brought out these past months.
<< PDA customers are more likely to be technically savvy, or even a bit
geeky, than regular customers. >>
You're confusing an interest in gadgets with technological knowledge.
There are oh so many Palm and Psion owners who use their machines daily
without having any idea what makes it tick.
<< Define "viable" >>
That I can give a Linux CD to Bert, a colleague of mine, and him
installing it on his home PC without any assistance. I've had Linux on my
home PC for a few months and recently assisted a friend by getting his PC
to run Linux. Giving me sufficient information to see that Linux is still
too much technologist cum developer orientated. Charlie's advice to
somebody having problems with p3nfs under Linux illustrating this. What he
wrote is Swahili to the majority of people.
<< It can be denied that they've succeeded >>
We're a few steps removed from the computer as household appliance.
Microsoft isn't there yet with Windows but closer than Linux is at the
moment.
<< A lot of the "free" software out there was funded development >>
Almost every time there's a discussion that touches "development"
there are grumbles from the Linux camp about the cost of Symbian's SDKs.
Fact is that there are freeware applications for the Series 5. With the
cost of tools and time being funded by companies or individual developers.
<< This is pure capitalism in action; software doesn't cost anything to
copy, but it costs a lot to make, so you pay people to make it, not to copy
it >>
Tell that to the Linux people next time when they grumble about SDK
costs. Pay Symbian for what they created.
<< It's a disservice to end-users to say "gee, all you have to do is a
little programming work and this will work nearly as well as the
competition" >>
I didn't mention anything about the development being easy or that
each individual user should do his/her own development work. So, don't put
words in my mouth. And you're evading the point I made. You don't get
positive results by constantly being negative about Psion, Symbian or the
Series 5. You seem to have almost endless time for trying to prove why
Psion/Symbian are doing things the wrong way. Without getting anywhere. Why
don't you spend that time in tackling the Word API with fellow programmers.
So that you come up with a description and blueprint a developer can
translate into the required Word<-->RTF application.
<< ... there's more interest in developing Linux for the series 5, than
there is in making the Series 5 applications talk to Linux... >>
The development of a Linux variant for the Series 5 is supported by
Psion by supplying the required information. While Psion/Symbian also
supplies information on the EPOC APIs through their development kits. Your
mention of the words "apathy" and "hostility" is therefore inappropriate.
With due respect for your knowledge, yours is a case of rather
selective indignation.
Kind Regards,
Peter Seebach
R.O.J. Brunsting <rbrun...@compuserve.com> wrote:
> I do wonder how many of the journalists writing about Linux are
>actually using a Linux machine themselves.
A few. My mom certainly wrote about NetBSD based on personal experience.
><< PDA customers are more likely to be technically savvy, or even a bit
>geeky, than regular customers. >>
> You're confusing an interest in gadgets with technological knowledge.
I am suggesting that they are statistically correlated, and in particular,
that you will find more savvy users among gadget freaks than among the
general population.
>There are oh so many Palm and Psion owners who use their machines daily
>without having any idea what makes it tick.
Indeed.
> That I can give a Linux CD to Bert, a colleague of mine, and him
>installing it on his home PC without any assistance. I've had Linux on my
>home PC for a few months and recently assisted a friend by getting his PC
>to run Linux. Giving me sufficient information to see that Linux is still
>too much technologist cum developer orientated. Charlie's advice to
>somebody having problems with p3nfs under Linux illustrating this. What he
>wrote is Swahili to the majority of people.
It seems to depend a lot on the people. Admittedly, there are a lot of
people who couldn't plausibly install Linux without help - but on the other
hand, I've made a fair amount of money selling consulting work to people
who can't install MacOS or Windows without help, so they're out there.
> Almost every time there's a discussion that touches "development"
>there are grumbles from the Linux camp about the cost of Symbian's SDKs.
>Fact is that there are freeware applications for the Series 5. With the
>cost of tools and time being funded by companies or individual developers.
My main complaint isn't cost; frankly, I think the pricing is reasonable.
It's that the SDK is only usable on one, specific, exceptionally undesirable,
development platform.
><< This is pure capitalism in action; software doesn't cost anything to
>copy, but it costs a lot to make, so you pay people to make it, not to copy
>it >>
> Tell that to the Linux people next time when they grumble about SDK
>costs. Pay Symbian for what they created.
I think you missed the distinction. The free software model is that you pay,
not for software, but for specific items of work. For instance, instead of
paying me some predetermined price for a piece of code I necessarily wrote
on spec, customers pay me an hourly rate to do whatever they need done to
any code that comes to hand.
The "free software" model would be that the SDK is free, but if you want a
new feature in the SDK, you pay Symbian to add it. This might actually be
viable for some markets; consider the people who are thinking about deploying
>1M units of some industrial hardware; they might be willing to fund the
development of a feature they want.
Or might not. It's a more complicated industry.
That said, my complaint isn't cost. If Psion had an SDK that I could use
with a gcc/Unix environment, I'd probably have bought one, if it were under
perhaps $300, because it would be useful to me.
I have no problem with that. However, I'm somewhat unhappy with the fact
that the SDK only exists on a platform I don't consider acceptable for
development work. I decided quite a while ago that development under Windows
simply doesn't pay enough to be worth the hassle.
Also, note that quality of products is mostly understood, not in absolute
terms, but in competitive terms. The EPOC SDK will be judged, in part, by
how it compares to the Palm SDK.
> I didn't mention anything about the development being easy or that
>each individual user should do his/her own development work. So, don't put
>words in my mouth. And you're evading the point I made. You don't get
>positive results by constantly being negative about Psion, Symbian or the
>Series 5. You seem to have almost endless time for trying to prove why
>Psion/Symbian are doing things the wrong way. Without getting anywhere. Why
>don't you spend that time in tackling the Word API with fellow programmers.
>So that you come up with a description and blueprint a developer can
>translate into the required Word<-->RTF application.
Honestly, because the API isn't available to me in any way, currently. If
that changes, I might well write myself an RTF converter. Probably one-way,
but you never know. :)
I don't think you get positive results by consistently ignoring a problem.
Psion has lost, so far as I can tell, *ALL* retail presence in the U.S.. This
isn't an insurmountable problem, but it's a real one, and, according to the
people running Palm, one of the reasons they're doing so well is that they've
cooperated with everyone in sight.
><< ... there's more interest in developing Linux for the series 5, than
>there is in making the Series 5 applications talk to Linux... >>
> The development of a Linux variant for the Series 5 is supported by
>Psion by supplying the required information.
Is it? My understanding (which could be wrong) had been that it was supported
the same way most new Linux work is - people with spare time and the ability
to identify chips and find chip-vendor docs for them.
>While Psion/Symbian also
>supplies information on the EPOC APIs through their development kits. Your
>mention of the words "apathy" and "hostility" is therefore inappropriate.
I have been told, even by Symbian/Psion folks, that the API's are not as
completely documented as they might be in an ideal world; this, and the fact
that you can only write code for the Psion using one tool, is a good example
of "hostility" to external developers.
Generally, one of the things you look for in a "friendly" vendor is an effort
on their part to make it as easy as possible for arbitrary third parties to
work with them - this begins, for instance, by allowing the use of a variety
of tools.
> With due respect for your knowledge, yours is a case of rather
>selective indignation.
Quite possibly. :)