!Info file proposal.
Martin Dann
Martin Dann <Mar...@f451.freeserve.co.uk> wrote:
I mentioned recently on csa.programmer about an idea for an application
description file, called !info in the root directory of an application.
This file would consist of a text messages file, only using predefined
tokens.
This somewhat copies data allready in other files e.g. messages, !runimage,
Res, resources.klingon.res etc, but to have the data in a standard format
would be nice.
I have uploaded a more detailed RFC to my website at
http://www.f451.freeserve.co.uk/InfoRFC.txt
Please note this is not linked from my website.
The tokens in !info messages file.
Info: * "MRD001" Reserved word and the version of the file data
Name: * The name of the application
Purpose: * The purpose of the application
Author: * The author
Version: * version of application of the form XXX.XX
Xversion: + extra text version information. e.g. a unix type version.
Date: * Date in the format dd-mm-yyyy
License: + License
Serial: + serial number.
WWW: + web address of the application.
Email: + email address for contacting author/ company.
Extra: + Extra text\url field.
Late: + url of a file of this format containing the latest information
Type: + possible numerical purpose
Flag0: * flag word.
Flag1: + second flag word if needed.
Type: + What the application does, or is for, in a numeric format,
for disk loggers, website lists etc.
Other possible tokens could be e.g.
P-Klingon: alfhllkjg
for a Klingon purpose
OR
nonuk: <info$dir>.resource.*.messages:purpose
where the * referes to the current spoken language, and the purpose
to the token in the message file.
* required for application info
+ optional
--
Enough stupidity can accomplish anything.
Chris Williams
On Mon, 14 Jan 2002, Martin Dann wrote:
> In message <691073f64a%Mar...@f451.freeserve.co.uk>
> Martin Dann <Mar...@f451.freeserve.co.uk> wrote:
>
> I mentioned recently on csa.programmer about an idea for an application
> description file, called !info in the root directory of an application.
> This file would consist of a text messages file, only using predefined
> tokens.
[snip file format]
I'm all for this actually and been wondering if anyone else wanted a
system like this put in place. It would open up advanced searches for
software (from the filer) and also enable people to produce better
software databases on websites. Plus it's something else for us
info-junkies :)
--
Chris Williams, electronic engineering student, Warwick Uni
EasyGCC Developer, http://www.melotech.co.uk/downloads/
Antony Sidwell
Chris Williams <es...@warwick.ac.uk> wrote:
> Hi,
>
> On Mon, 14 Jan 2002, Martin Dann wrote:
>
> > In message <691073f64a%Mar...@f451.freeserve.co.uk>
> > Martin Dann <Mar...@f451.freeserve.co.uk> wrote:
> >
> > I mentioned recently on csa.programmer about an idea for an application
> > description file, called !info in the root directory of an application.
> > This file would consist of a text messages file, only using predefined
> > tokens.
>
> [snip file format]
>
> I'm all for this actually and been wondering if anyone else wanted a
> system like this put in place. It would open up advanced searches for
> software (from the filer) and also enable people to produce better
> software databases on websites. Plus it's something else for us
> info-junkies :)
I think the idea is sound, but I'd prefer it in XML myself, like the one
in ROX. On the other hand, we do have easy ways to read Messages files,
and rather les easy ways to read XML...
--
Richard Blythe
>
> I think the idea is sound, but I'd prefer it in XML myself, like the one
> in ROX. On the other hand, we do have easy ways to read Messages files,
> and rather les easy ways to read XML...
Since there's been some bandying around of an XML-based Choices file
format (if I understood correctly) there might be some scope for some
unification. I'm not entirely sure what I mean by this, so could someone
please explain?
Monday morning,
--
rab
email: use...@rab.org.uk
web: www.rab.org.uk
Matthias Seifert
> In message <691073f64a%Mar...@f451.freeserve.co.uk>
> Martin Dann <Mar...@f451.freeserve.co.uk> wrote:
[...]
> The tokens in !info messages file.
[...]
> Date: * Date in the format dd-mm-yyyy
Why not use the ISO standard instead, which is "yyyy-mm-dd"?
--
_ _ | Acorn RiscPC, StrongARM @ 287 MHz,
| | | _, _|__|_ |) ' _, , | 258 MB RAM, >75 GB HD, RISC OS 4.02
| | | / | | | |/\ | / | / \ | -----------------------------------
| | |_/\/|_/|_/|_/| |/|/\/|_/ \/ | http://www.deutschlandwetter.de
Simpson
"Martin Dann" <Mar...@f451.freeserve.co.uk> wrote in message
news:I...@f451.freeserve.co.uk...
> In message <691073f64a%Mar...@f451.freeserve.co.uk>
> Martin Dann <Mar...@f451.freeserve.co.uk> wrote:
>
> I mentioned recently on csa.programmer about an idea for an application
> description file, called !info in the root directory of an application.
> This file would consist of a text messages file, only using predefined
> tokens.
This is a good idea. I wrote a program a while back to do just that,
but I never released it - didn't have access to the internet at that time,
so I couldn't popularise the idea of ask for advice and suggestions.
Besides, my file format was a bit simplistic.
>
> This somewhat copies data allready in other files e.g. messages,
!runimage,
> Res, resources.klingon.res etc, but to have the data in a standard format
> would be nice.
Yes, it would. When I was writing a program to catalogue my harddisc
contents, it was rather frustrating that only a tiny amount of information
could be gleaned from applications.
W.Simpson
Theo Markettos
> Version: * version of application of the form XXX.XX
What about GCC 2.95.4, OpenSSH 3.0.2p1 etc? Maybe a string, but one on
which compares will work (ie 3.0.1 < 3.0.2p1)
> License: + License
How about also a link to a licence file (there are so many around that just
a textual string may not be very helpful)?
Just random thoughts...
Theo
nico ter haar
Matthias Seifert <M.Se...@t-online.de> wrote:
> On 14 Jan, Martin Dann <Mar...@f451.freeserve.co.uk> wrote:
> > In message <691073f64a%Mar...@f451.freeserve.co.uk>
> > Martin Dann <Mar...@f451.freeserve.co.uk> wrote:
>
> [...]
>
> > The tokens in !info messages file.
>
> [...]
> > Date: * Date in the format dd-mm-yyyy
>
> Why not use the ISO standard instead, which is "yyyy-mm-dd"?
>
Agreed.
I use to think writing it yyyy-mm-dd is completely and utterly wrong,
but now that I'm using dates all the time for my job I find I'm
noting it like this. Just because the Filer (ros/win) will list them
in the desired order and it does make more sense to work this way.
--
Matthias Seifert
That was exactly the thought behind that standard. And furthermore it
prevents mix-ups between dd-mm-yyyy and mm-dd-yyyy. :-)
Stephen Courtney
<Pine.SOL.4.30.02011...@primrose.csv.warwick.ac.uk>,
> On Mon, 14 Jan 2002, Martin Dann wrote:
> > In message <691073f64a%Mar...@f451.freeserve.co.uk>
> > Martin Dann <Mar...@f451.freeserve.co.uk> wrote:
> >
> > I mentioned recently on csa.programmer about an idea for an application
> > description file, called !info in the root directory of an application.
> > This file would consist of a text messages file, only using predefined
> > tokens.
> [snip file format]
> I'm all for this actually and been wondering if anyone else wanted a
> system like this put in place. It would open up advanced searches for
> software (from the filer) and also enable people to produce better
> software databases on websites. Plus it's something else for us
> info-junkies :)
Indeed, - there is also the opportunity for the following to take place:
1) A user attempts to run a file for which they do not have an application
2) In place of the standard 'Application that loads a file... not found...'
error, a small program can catch the message, and look up in a database
for that filetype.
3) It then displays a list of various software that can handle that filetype,
with appropriate web/email links (even a direct download link).
4) The user can then cancel this dialogue (if they want), or can choose to
follow up one (or more) of the options presented.
The database for the listening application could be held either locally, or
remotely say, on the RISC OS Filebase :p
Cheers,
Stephen
--
Stephen Courtney - Barti on #acorn #altb5uk
Home | http://www.steve-c.co.uk
Acorn News Service | http://www.acornusers.org/ans
RISC OS Filebase | http://filebase.acornusers.org
The IconBar | http://www.iconbar.com
Martin Dann
Matthias Seifert <M.Se...@t-online.de> wrote:
> On 14 Jan, nico ter haar <ni...@neptune.demon.nl> wrote:
> > In message <4af8acfc6...@t-online.de>
> > Matthias Seifert <M.Se...@t-online.de> wrote:
>
> > > On 14 Jan, Martin Dann <Mar...@f451.freeserve.co.uk> wrote:
> > > > In message <691073f64a%Mar...@f451.freeserve.co.uk>
> > > > Martin Dann <Mar...@f451.freeserve.co.uk> wrote:
> > >
> > > [...]
> > >
> > > > The tokens in !info messages file.
> > >
> > > [...]
> > > > Date: * Date in the format dd-mm-yyyy
> > >
> > > Why not use the ISO standard instead, which is "yyyy-mm-dd"?
> > >
> > Agreed.
>
> > I use to think writing it yyyy-mm-dd is completely and utterly wrong,
> > but now that I'm using dates all the time for my job I find I'm
> > noting it like this. Just because the Filer (ros/win) will list them
> > in the desired order and it does make more sense to work this way.
>
> That was exactly the thought behind that standard. And furthermore it
> prevents mix-ups between dd-mm-yyyy and mm-dd-yyyy. :-)
Well some people might use yyyy-dd-mm, I think you can do this in windoze.
As yyyy-mm-dd is the ISO standard we might as well use this. It does appear
more logical as well, each digit less significant than the previous.
dd-mm-yyyy has the most significant digit in the middle.
Martin.
--
You forget somthing old every day.
Martin Dann
Antony Sidwell <antony...@isparp.co.uk> wrote:
> I think the idea is sound, but I'd prefer it in XML myself, like the one
> in ROX. On the other hand, we do have easy ways to read Messages files,
> and rather les easy ways to read XML...
I can see the point of choices being in XML, but for a file that is
designed to be simple, I hardly see the point. Anyone can read and edit
a messages file, but XML is an order of magnitude harder.
XML would also need a decent editor, and the extra code to get the data
from the file.
I think that the chances of this being supported are higher if we keep
the format as a simple messages file.
Martin.
--
If at first you don't succeed; use a bigger hammer.
Terry Blunt
Matthias Seifert <M.Se...@t-online.de> wrote:
> On 14 Jan, nico ter haar <ni...@neptune.demon.nl> wrote:
> > In message <4af8acfc6...@t-online.de>
> > Matthias Seifert <M.Se...@t-online.de> wrote:
>
> > > On 14 Jan, Martin Dann <Mar...@f451.freeserve.co.uk> wrote:
> > > > In message <691073f64a%Mar...@f451.freeserve.co.uk>
> > > > Martin Dann <Mar...@f451.freeserve.co.uk> wrote:
> > >
> > > [...]
> > >
> > > > The tokens in !info messages file.
> > >
> > > [...]
> > > > Date: * Date in the format dd-mm-yyyy
> > >
> > > Why not use the ISO standard instead, which is "yyyy-mm-dd"?
> > >
> > Agreed.
>
> > I use to think writing it yyyy-mm-dd is completely and utterly wrong,
> > but now that I'm using dates all the time for my job I find I'm
> > noting it like this. Just because the Filer (ros/win) will list them
> > in the desired order and it does make more sense to work this way.
>
> That was exactly the thought behind that standard. And furthermore it
> prevents mix-ups between dd-mm-yyyy and mm-dd-yyyy. :-)
Funny how so many people end up doing the same isn't it :-)
BTW I have this new idea I might patent. I'm going to call it:
Weight
Handling
Ergonomic
Equipment
Locator
Okok it's late and I'm tired!
--
Terry Blunt <te...@langri.demon.co.uk>
Age gives you the experience to screw up properly.
Martin Dann
Theo Markettos <ne...@markettos.org.uk> wrote:
> Martin Dann <Mar...@f451.freeserve.co.uk> wrote:
> > Version: * version of application of the form XXX.XX
>
> What about GCC 2.95.4, OpenSSH 3.0.2p1 etc? Maybe a string, but one on
> which compares will work (ie 3.0.1 < 3.0.2p1)
What are the rules on string comparison, surely they vary according to the
language you use. A number is far easier to compare.
In RO you could do somthing like
*setevalmessage app$ver <app$dir>.!info version*100
(if such a command existed)
And then do a direct comparison in an obey file.
Can you compare strings using the CLI?
> > License: + License
>
> How about also a link to a licence file (there are so many around that just
> a textual string may not be very helpful)?
Well I was thinking about just a serial number or somthing, but this would
make updating harder, as you would have to edit the !info file, not just
copy a new one over.
Perhaps a link to a licence file would be better. The problem is we don't
want the idiots^H^H^H^H^H^H users to think that editing is file will
solve their problems :-)
Martin Dann
Stephen Courtney <ste...@steve-c.co.uk> wrote:
> In article
> <Pine.SOL.4.30.02011...@primrose.csv.warwick.ac.uk>,
> Chris Williams <es...@warwick.ac.uk> wrote:
>
> > I'm all for this actually and been wondering if anyone else wanted a
> > system like this put in place. It would open up advanced searches for
> > software (from the filer) and also enable people to produce better
> > software databases on websites. Plus it's something else for us
> > info-junkies :)
> 3) It then displays a list of various software that can handle that
> filetype, with appropriate web/email links (even a direct download link).
Sounds like we need a message that lists the file types needed as
Mr Olsson suggested. He also suggested application and module dependencies.
(File types could be those that would load the application, those loaded
when the application is already running, and those which can be dragged
to the application.)
--
Martin's first law: dd/dd=1 Dee Dee; Dee Dee equals one.
Antony Sidwell
Martin Dann <Mar...@f451.freeserve.co.uk> wrote:
> In message <4a668df84a%antony...@isparp.co.uk>
> Antony Sidwell <antony...@isparp.co.uk> wrote:
>
> > I think the idea is sound, but I'd prefer it in XML myself, like the one
> > in ROX. On the other hand, we do have easy ways to read Messages files,
> > and rather les easy ways to read XML...
>
> I can see the point of choices being in XML, but for a file that is
> designed to be simple, I hardly see the point. Anyone can read and edit
> a messages file, but XML is an order of magnitude harder.
> XML would also need a decent editor, and the extra code to get the data
> from the file.
I see the extra code needed to read the file as being a possible
problem, though less and less so as people port very high quality XML
libraries to this platform and XML itself becomes widespread. Editing
XML itself is trivial, requiring nothing more than !Edit (as long as you
don't over-complicate the format). I've written a set of *very* simple
XML reading routines to try and implement in an Angband varient, so I
don't see it adding very large code overheads if we keep the format to
the point.
> I think that the chances of this being supported are higher if we keep
> the format as a simple messages file.
Almost certainly so! I would perhaps question how simple the proposed
format was, though :) Sticking to the *required* fields gives a nice
format, but adding in much more can make things less clear (eg. the
Extra Type, or flag fields) where XML might make them easier to
understand when read by humans.
The ROX AppInfo.xml file format is very simple (perhaps too simple), for
instance:
<?xml version="1.0"?>
<AppInfo>
<Summary>Cross-platform word processor</Summary>
<About>
<Purpose>Word processor</Purpose>
<Homepage>http://www.abisource.com/</Homepage>
</About>
</AppInfo>
We could extend this by adding <Version>, <Date> tags and so on. Maybe
even a <Name> for the application!
One of the nice things about the ROX implementation is that the summary
text is used to implement a "tooltip" thing in the filer window (drawing
on another thread from here recently about interactive help).
I suppose I favour it because it is essentially extensible, so that to
add a Klingon purpose you could have <Purpose language="Klingon">. Or
for that matter:
<Version type="RISC OS">1.00</Version> and
<Version type="Source">3.1.2</Version>, displayed as such in the "Info"
window on the filer menu (assuming that as one of the eventual aims).
I would find that easier to alter, edit or generate than the alternative
- I think that's probably a matter of personal preference - I'm sure
other people see it differently.
I also think there would be advantages when maintaining online
filebases, it being trivial to convert the relevant XML bits and bobs to
HTML. I think that's every "pro" reason I can think of at the moment!
Anyway, just some thoughts, rather too early in the morning.
Antony.
--
Martin Dann
Terry Blunt <te...@langri.demon.co.uk> wrote:
> BTW I have this new idea I might patent. I'm going to call it:
>
> Weight
> Handling
> Ergonomic
> Equipment
> Locator
>
> Ok it's late and I'm tired!
Going totally OT, but
somone managed to patent somthing simplistic like, the wheel, and maybe
even the wheel last year.
Martin
--
I'm not rich enough to be eccentric :-(
Nemo
> I see the extra code needed to read the file as being a possible problem,
> though less and less so as people port very high quality XML libraries to
> this platform and XML itself becomes widespread.
Ooh, ooh, yes! Lets make all messages files in all programs XML. And no more
sprite files either. Lets make everything XML. Perhaps that will convince us
that the platform is really hip, with-it and current! ;-)
> Editing XML itself is trivial,
Then you are going to have to invent a new word for describing the editing
of a messages file which is, I suggest, even easier, especially for mere
humans.
> XML might make them easier to understand when read by humans.
OK, well lets take your ROX example, and combine with the additions you
suggest, and see which one looks simpler (and feel free to ask your
Significant Other/Mother/Postman/Cat for their opinion too):
<?xml version="1.0"?>
<AppInfo>
<Summary>Cross-platform word processor</Summary>
<About>
<Purpose>Word processor</Purpose>
<Version>1.00</Version>
<Date>2002-01-15</Date>
<Homepage>http://www.abisource.com/</Homepage>
</About>
</AppInfo>
or...
Summary:Cross-platform word processor
Purpose:Word processor
Version:1.00
Date:2002-01-15
Homepage:http://www.abisource.com/
Hmmm... Daddy or chips... Daddy... Chips...
Nope, the Messages format is simpler.
> the summary text is used to implement a "tooltip" thing in the filer
> window
That's nothing to do with XML.
> to add a Klingon purpose you could have <Purpose language="Klingon">. Or
> for that matter: <Version type="RISC OS">1.00</Version> and <Version
> type="Source">3.1.2</Version>,
Or indeed:
Klingon-Purpose:
Source-Version:
XML has its uses, and using up disc space is one of them. :-)
--
Nemo ne...@20000.org
Thomas Leonard
> On 15 Jan, Antony Sidwell wrote:
>> XML might make them easier to understand when read by humans.
>
> OK, well lets take your ROX example, and combine with the additions you
> suggest, and see which one looks simpler (and feel free to ask your
> Significant Other/Mother/Postman/Cat for their opinion too):
>
> <?xml version="1.0"?>
> <AppInfo>
> <Summary>Cross-platform word processor</Summary>
> <About>
> <Purpose>Word processor</Purpose>
> <Version>1.00</Version>
> <Date>2002-01-15</Date>
> <Homepage>http://www.abisource.com/</Homepage>
> </About>
> </AppInfo>
>
> or...
>
> Summary:Cross-platform word processor
> Purpose:Word processor
> Version:1.00
> Date:2002-01-15
> Homepage:http://www.abisource.com/
>
> Hmmm... Daddy or chips... Daddy... Chips...
> Nope, the Messages format is simpler.
Sorry, is that example in the iso-8859-1 encoding? UTF-8? KOI8-R? Makes
a difference when you're trying to display a file written in another
country. Guess you're going to need an encoding tag somewhere...
Now, you've got a bit of a problem with quoting. What if the summary
contains a new line? Will that be a '\n', or some kind of continuation
character? How do you escape the continuation character, then?
Of course, you'll want to allow extensions besides stuff for the info
box, so you'd better add some groups (we got burned by this with our
original (non-XML) format).
In fact, to be safe, you'll need a file format version number in
there... let's see now...
[header]
Encoding:UTF-8
Version:1.0
License:GPL
[summary]
Cross-platform word processor\n(RISC OS version)
[about]
Purpose:Word processor
Version:1.00
Date:2002-01-15
Homepage:http://www.abisource.com/
We did change to XML for a reason, you know ;-)
BTW, the example document is short on details because it's a wrapper for
a non-ROX program. If you look at the file for ROX-Filer itself you'll
see several other features. In particular, any field names are allowed
in the 'about' section and are all displayed in the info window.
--
Thomas Leonard http://rox.sourceforge.net
tal...@ecs.soton.ac.uk tal...@users.sourceforge.net
druck
[Snip XML and messages example]
> Hmmm... Daddy or chips... Daddy... Chips...
hehe
> Nope, the Messages format is simpler.
I agree, if the data you are seeking to represent is strongly hierarchical
then use XML, if it is simple key:value pairs then message format.
---druck
--
The ARM Club * http://www.armclub.org.uk/
Daniel Ellis
What's da problem? There are different messages files in the territory
subdirectory, encoded by the appropriate alphabet.
> Now, you've got a bit of a problem with quoting. What if the summary
> contains a new line? Will that be a '\n', or some kind of continuation
> character? How do you escape the continuation character, then?
Erm, |m always worked for me.
> Of course, you'll want to allow extensions besides stuff for the info box,
> so you'd better add some groups (we got burned by this with our original
> (non-XML) format).
Message files are implicitly extensible, one of the neat things about them.
I think this is really a case of the pros outweighing the cons.
--
Dan Ellis
mailto:d...@pod51.demon.co.uk
Harriet Bazley
Antony Sidwell wrote:
> Editing XML itself is trivial, requiring nothing more than !Edit (as
> long as you don't over-complicate the format). I've written a set of
> *very* simple XML reading routines to try and implement in an Angband
> variant, so I don't see it adding very large code overheads if we keep
> the format to the point.
>
Oh? Which variant? :-)
--
Harriet Bazley == Loyaulte me lie ==
Those who can't write, write manuals.
Antony Sidwell
Harriet Bazley <har...@bazley.freeuk.com> wrote:
> On 15 Jan 2002 as I do recall,
> Antony Sidwell wrote:
>
> > Editing XML itself is trivial, requiring nothing more than !Edit (as
> > long as you don't over-complicate the format). I've written a set of
> > *very* simple XML reading routines to try and implement in an Angband
> > variant, so I don't see it adding very large code overheads if we keep
> > the format to the point.
> >
> Oh? Which variant? :-)
Elasticband - my brother is actually developing it, I'm just chipping in
with a few odds and ends to help him out.
Antony.
--
Thomas Leonard
> In article <slrna48h0a...@everest.ecs.soton.ac.uk>, Thomas Leonard
><URL:mailto:tal...@everest.ecs.soton.ac.uk> wrote:
>> Sorry, is that example in the iso-8859-1 encoding? UTF-8? KOI8-R? Makes
>> a difference when you're trying to display a file written in another
>> country. Guess you're going to need an encoding tag somewhere...
>
> What's da problem? There are different messages files in the territory
> subdirectory, encoded by the appropriate alphabet.
I mean, what happens if the author's name, for example, contains a
non-ascii character? Eg, if I've downloaded a Russian program then I'd
expect it to be in a Russian encoding.
If you're assuming that all programmers are English, and the !Info file
will have a translation into other languages then that's a bit
limiting...
>> Of course, you'll want to allow extensions besides stuff for the info box,
>> so you'd better add some groups (we got burned by this with our original
>> (non-XML) format).
>
> Message files are implicitly extensible, one of the neat things about them.
So how do you know which tags are for the info box and which aren't?
> I think this is really a case of the pros outweighing the cons.
Doesn't RISC OS have an XML module yet? Parsing XML is normally just a
case of doing
doc = xmlParseFile(path);
If every program has to have its own parser, then obviously XML is a bad
idea, though ;-)
Nemo
> I mean, what happens if the author's name, for example, contains a
> non-ascii character? Eg, if I've downloaded a Russian program then I'd
> expect it to be in a Russian encoding.
How this is represented in the file is irrelevent (though UTF8 would be
favourite) - the REAL problem is what the hell you do with it once you have
read it in - stick it in an icon and hope for the best?
> So how do you know which tags are for the info box and which aren't?
MessageTrans_EnumerateTokens,,"Info*"
> Doesn't RISC OS have an XML module yet?
There is one. Having seen it in action I am unimpressed by its lethagy and
greed.
--
Nemo ne...@20000.org
John Tytgat
>How this is represented in the file is irrelevent (though UTF8 would be
>favourite) - the REAL problem is what the hell you do with it once you have
>read it in - stick it in an icon and hope for the best?
>
...like "best" = "a UTF8 capable fontmanager" ? :^)
Jo.
--
John Tytgat f u cn rd ths,
John....@barco.com u cn gt a gd jb n cmptr prgrmmng !
Nemo
> "best" = "a UTF8 capable fontmanager" ? :^)
Yeah, if said fontmanager supported glyph borrowing and composite fonts,
otherwise you STILL have the same problem with Cyrillic, Hebrew, Greek, and
the Big5. Unfortunately, Pace's "Unicode fontmanager" has neither.
--
Nemo ne...@20000.org
Andrew Hill
What's wrong with storing all this info inside Messages? Half of it's there
already, and it's merely extending a current standard rather than
implementing a new one! If you use the Message format, that's the way to go;
if you're using XML then obviously you need a !Info file.
Best wishes,
Drew
Roger W Wylde
Martin Dann <Mar...@f451.freeserve.co.uk> wrote:
> In message <bb8ef3f8...@langri.demon.co.uk>
> Terry Blunt <te...@langri.demon.co.uk> wrote:
>
> > BTW I have this new idea I might patent. I'm going to call it:
> >
> > Weight
> > Handling
> > Ergonomic
> > Equipment
> > Locator
> >
> > Ok it's late and I'm tired!
>
> Going totally OT, but
> somone managed to patent somthing simplistic like, the wheel, and maybe
> even the wheel last year.
Indeed.
http://www.theage.com.au/news/state/2001/07/02/FFX0ADFPLOC.html
Roger.
--
Roger Wylde - I.T. Technician, Droitwich Spa High School, Worcestershire
(Acorn Risc PC, 200Mhz StrongARM, RISC OS 4.24, 50Mb/1.2/6.4/20.4Gbp and
_____ _ ___ _____ _ _ mailto: ro...@niftysoftware.co.uk A4 Laptop
| _ | | _|_ _| |_| | Visit the Nifty Web Site 4Mb/3Gb)
| | | | | |_ | | \ / url: http://www.niftysoftware.co.uk
| | | | | _| | | | | Home of Nifty Software - lots of free software
|_| |_|_|_| |_| |_| & Witley Court - Worcestershire's premier ruin
-BBCs and Masters as well as other stuff, all for sale on the Nifty Site-
- NetGuard - Protect and add style to your Acorn/RISC OS network -
Martin Dann
"Andrew Hill" <drew...@tesco.net> wrote:
> Hiya,
>
> What's wrong with storing all this info inside Messages?
There are several problems.
1) Not all applications have a messages file.
2) Some applications hide a messages file in a sub directory, e.g.
resources.uk or res.klingon. e.g. !ftpc has all its messages in
subdirectories.
3) For this to work, the tokens would have to be standardised between
applications. As it stands an application can call its message tokens
what it wants.
4) message files are somtimes created by e.g. !resedit. They would have
to have the information manually added, or possibly a pseudo class added
that has this data.
Martin.
--
Typed by monkey #27662472869676 on typewriter #7552416572242
David Mullard
<Mar...@f451.freeserve.co.uk> wrote:
> In message <691073f64a%Mar...@f451.freeserve.co.uk> Martin Dann
> <Mar...@f451.freeserve.co.uk> wrote:
> skipped
A few thoughts,
A very good idea so please pursue it.
Tokens vs XML. The main thing is that any standard is better than no
standard. Initially I aggreed that the token format was best because it is
so easy to understand and maintain. However, instinct and a bit of
reflection makes me think that XML is the right choice. For a start, it is
probably going to be produced by programmers who should be able to learn
and write correct XML and, to be most useful, read by an application and
not directly. Some applications are not simple and can consist of multiple
components which may each need separate info. XML I am sure is a better
may of describing these. Think about one for RISC OS itself? Off course,
you could have both. If the filetype is TEXT then Token format, if XML
then...
Whichever format is used, the first thing should be the version of the
info file format itself. With the best efforts, it is inevitable that the
specification will be revised and a new one produced after some time. If
it is going to be supported by software then this is essential.
If it isn't obvious, the !Boot should contain a
*SET Info$MyApp <MyApp$Dir>.!Info
as part of the standard to make it easy to find and retrieve info for all
seen applications.
Date: Of course it should be yyyy-mm-dd so that two dates can be compared
and this principle should apply to all such entries.
--
Dave Mullard <Da...@mullard.net>
Andrew Hill
Martin Dann <Mar...@f451.freeserve.co.uk> wrote:
> In message <a2c7g8$f3o$1...@helle.btinternet.com>
> "Andrew Hill" <drew...@tesco.net> wrote:
>
> > Hiya,
> >
> > What's wrong with storing all this info inside Messages?
>
> There are several problems.
> 1) Not all applications have a messages file.
OK, we make !App.Messages files compulsory. No real issue as a !Info file
would have to become compulsory.
> 2) Some applications hide a messages file in a sub directory, e.g.
> resources.uk or res.klingon. e.g. !ftpc has all its messages in
> subdirectories.
See 1)
> 3) For this to work, the tokens would have to be standardised between
> applications. As it stands an application can call its message tokens
> what it wants.
Solved that too. The Configure plug-in specification contains a set of
default tokens. It's a reasonable set which could be extended.
I appreciate this standard isn't yet in the public domain; hopefully that
could be corrected in the near future.
> 4) message files are somtimes created by e.g. !resedit. They would have
> to have the information manually added, or possibly a pseudo class added
> that has this data.
I disagree. ALL toolbox applications have to have the following tags:
_TaskName:
_Purpose:
_Author:
_Version:
It seems pointless to me to duplicate this information. Other applicatons
could have these tokens added /easily/ and the protocol extended to contain
the extra info. It also ensures that the information remains consistent
with that displayed in the application. These tokens are international, thus
a program should have two Message loading loops - one for national and one
for international messages. Would that appeal?
Best wishes,
Drew
--
Andrew Hill
4th Year Medical Student, Liverpool University
Martin Dann
Andrew Hill <drew...@tesco.net> wrote:
> In message <5f83afc4a%Mar...@f451.freeserve.co.uk>
> Martin Dann <Mar...@f451.freeserve.co.uk> wrote:
> > 3) For this to work, the tokens would have to be standardised between
> > applications. As it stands an application can call its message tokens
> > what it wants.
>
> Solved that too. The Configure plug-in specification contains a set of
> default tokens. It's a reasonable set which could be extended.
Looking at !open i see a set of tokens including:
_ConfigText:
_ConfigHelp:
_ConfigSprite:
Which is IMHO wrong, they should be _Config.Text: etc.
Are all tokens starting with an underscore reserved?
If so can I get some tokens or a prefix allocated?
> > 4) message files are somtimes created by e.g. !resedit. They would have
> > to have the information manually added, or possibly a pseudo class added
> > that has this data.
>
> I disagree. ALL toolbox applications have to have the following tags:
>
> _TaskName:
> _Purpose:
> _Author:
> _Version:
But they don't include _Date, _Email, _WWW. These would have to be
added somehow.
Toolbox apps need _TaskName: but do not need to include the other three.
> It seems pointless to me to duplicate this information. Other applicatons
> could have these tokens added /easily/ and the protocol extended to contain
> the extra info. It also ensures that the information remains consistent
> with that displayed in the application. These tokens are international, thus
> a program should have two Message loading loops - one for national and one
> for international messages. Would that appeal?
I agree that it is stupid duplicating this info, and getting !resed to
edit it, plus a freeware editor would be good. But a function would have
to be added to !resed somewhere to edit the extra tags.
Martin.
--
According to the human genome project, humans are 50-60% bananas.
Dominic Beesley
"David Mullard" <Da...@mullard.net> wrote in message
news:4afb495...@mullard.net...
> In article <I...@f451.freeserve.co.uk>, Martin Dann
> <Mar...@f451.freeserve.co.uk> wrote:
> > In message <691073f64a%Mar...@f451.freeserve.co.uk> Martin Dann
> > <Mar...@f451.freeserve.co.uk> wrote:
>
> Tokens vs XML. The main thing is that any standard is better than no
> standard. Initially I aggreed that the token format was best because it is
> so easy to understand and maintain. However, instinct and a bit of
> reflection makes me think that XML is the right choice. For a start, it is
> probably going to be produced by programmers who should be able to learn
> and write correct XML and, to be most useful, read by an application and
> not directly. Some applications are not simple and can consist of multiple
> components which may each need separate info. XML I am sure is a better
> may of describing these. Think about one for RISC OS itself? Off course,
> you could have both. If the filetype is TEXT then Token format, if XML
> then...
Too right, at work I've started using xml all the time, its a doddle though
I'm not
sure what the RiscOS support is like at present. Once some kind of document
object model generating parser is available then its so easy! I've been
working
in an environment where we have lots of text files - legal publishing, since
we
started using xml I can no do things in minutes that would have taken hours.
Of course its not all beer and skittles, there are very few editors out
there and
the only half way decent ones cost a fortune! However any reasonable human
IQ>70 can edit files in !edit with no trouble - we employ school leavers and
it
takes about an hour of training to show them how it works
>
> Whichever format is used, the first thing should be the version of the
> info file format itself. With the best efforts, it is inevitable that the
> specification will be revised and a new one produced after some time. If
> it is going to be supported by software then this is essential.
Also dont forget that XML is nicely extendible, as long as there is a decent
basic set of tags that are agreed between everybody then others can be
added in without causing (well-written) readers to panic.
Dom
Stewart Brodie
> Andrew Hill <drew...@tesco.net> wrote:
>
> > I disagree. ALL toolbox applications have to have the following tags:
> >
> > _TaskName:
> > _Purpose:
> > _Author:
> > _Version:
No, they do not. Do you mean "should have to have"? Any notion that
ProgInfo will update its template with this information is fanciful, I'm
afraid - you need to have separate Res files for each territory, although
there is an API to set some of the fields - just not all of them - only
Licence and Version?
--
Stewart Brodie, Senior Software Engineer (Views expressed are my own and
Pace Micro Technology PLC not those of my employer)
645 Newmarket Road
Cambridge, CB5 8PB, United Kingdom WWW: http://www.pacemicro.com/
Ben Avison
<URL:mailto:stewart...@pace.co.uk> wrote:
> > In message <015da1fe...@tesco.net>
> > Andrew Hill <drew...@tesco.net> wrote:
> >
> > > I disagree. ALL toolbox applications have to have the following tags:
> > >
> > > _TaskName:
> > > _Purpose:
> > > _Author:
> > > _Version:
>
> No, they do not. Do you mean "should have to have"? Any notion that
> ProgInfo will update its template with this information is fanciful, I'm
> afraid - you need to have separate Res files for each territory, although
> there is an API to set some of the fields - just not all of them - only
> Licence and Version?
Well, to be more accurate, _TaskName is a requirement. _Purpose, _Author
and _Version are explicitly read by !Configure in order to build its
plug-in info menu (it uses its own windows for that, not ProgInfo), and so
they're a requirement only for !Configure plug-ins.
Ben
--
Ben Avison, Senior Software Engineer
Pace Micro Technology plc Tel: +44 (0) 1223 518562 (ext 8562)
645 Newmarket Road Fax: +44 (0) 1223 518526
Cambridge, CB5 8PB, United Kingdom WWW: http://www.pace.co.uk/
Iain Williamson
"Dominic Beesley" <dominc...@hotmail.com> wrote:
> Too right, at work I've started using xml all the time, its a doddle
> though I'm not sure what the RiscOS support is like at present.
By and large, it's like this:
http://homepage.ntlworld.com/justin.fletcher/XML/
or this:
http://anjackson.org/poot/riscos/xmlutils
> Once some kind of document object model generating parser is available
> then its so easy!
I notice gerph has parsexml on his page, which should be able to do the
same as a DOM - not sure if it has the same API.
Of course, I'd imagine working with the parser API directly could result
in a more efficient program which could be significant on RISC OS. I've
seem some DOM implementations take surprisingly large amounts of memory
on other platforms.
--
To avoid being sent to a communal spam bin, remove the XXX to
e-mail me. You'll get a quicker response -- Iain Williamson
Nemo
> I've seem some DOM implementations take surprisingly large amounts of
> memory on other platforms.
If the SVG plug-in is anything to go by, I think you'll find that ParseXML
takes surprisingly large amounts of memory!
--
Nemo ne...@20000.org
Dominic Beesley
swing
of things. Would this be a good programming exercise to get me started. Its
many years ago but in a previous job I had a good lightweight DOM (for SGML)
going that generally (excluding code) used a less memory than the original
document.
would this be something that people would be interested in?
whats the best way of implementing an api like this on RiscOS as theres no
equivalent to COM or such like. A C/C++ wrapper? A relocatable module?
Dom
John Tytgat
>whats the best way of implementing an api like this on RiscOS as theres no
>equivalent to COM or such like. A C/C++ wrapper? A relocatable module?
>
Start with a good designed library. Then it is still easy to write a
relocatable module around this library. Note that for making a module,
you need Acorn C compiler and that this (nearly) excludes the use of C++
as language.
Andrew Hill
"Ben Avison" <ben.a...@pace.co.uk> wrote in message
news:ant28114...@bavison.cam.pace.co.uk...
> In article <ca13ddff4...@sbrodie.cam.pace.co.uk>, Stewart Brodie
> <URL:mailto:stewart...@pace.co.uk> wrote:
> > > In message <015da1fe...@tesco.net>
> > > Andrew Hill <drew...@tesco.net> wrote:
> > >
> > > > I disagree. ALL toolbox applications have to have the following
tags:
> > > >
> > > > _TaskName:
> > > > _Purpose:
> > > > _Author:
> > > > _Version:
> >
> > No, they do not. Do you mean "should have to have"? Any notion that
> > ProgInfo will update its template with this information is fanciful, I'm
> > afraid - you need to have separate Res files for each territory,
although
> > there is an API to set some of the fields - just not all of them - only
> > Licence and Version?
>
> Well, to be more accurate, _TaskName is a requirement. _Purpose, _Author
> and _Version are explicitly read by !Configure in order to build its
> plug-in info menu (it uses its own windows for that, not ProgInfo), and so
> they're a requirement only for !Configure plug-ins.
Sorry - I did mean Configure, re-edited the message and goodness knows what
happened next! Gremlins controlling the e-mail system again!
Anyway - the point was that there is already an accepted standard for
Configure, which is partially implemented for Toolbox applications; why
re-invent the wheel here when that could simply be adopted and extended?
Best wishes,
Drew