"Amir Yantimirov" <am**@sl.iae.nsk.su> wrote in message
news:97*************************@posting.google.co m...
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message
news:<Pi***********************************@unix43 .andrew.cmu.edu>...
Okay, consider yourself pointed. To comp.lang.misc, where discussion
of new programming languages is considered not only topical but welcome.
Followups set.
Thanks greatly!
Some years ago I found it completely unpopulated.
Now seems what though residents are few but they are more of my kind.
Amir Yantimirov
http://www174.pair.com/yamir/programming/
I looked at the site.
some of your ideas I have found interesting.
I personally had before had the idea of being able to expand/collapse source
code, or maybe being able to perform queries on it (eg: telling the viewer
to only display headers and text descriptions), or to be able to generate
various manners of documentation from the source (eg: a tree representing
the call graph), maybe the source could be totally reorganized based on how
it is being interacted with, ...
this is not easy to do really, so I had never really gotten to it.
the main thing that was pointed out, I think, was the idea of using a
non-source (or maybe heavily marked-up) source representation for the tool,
then as needed generating usable source (needed for non-source at least,
less for marked up source...).
this one is newer to me (actually, my previous plans were to leave the
source in some sort of "in core" form, and making use of a "living system"
for editing). having the data in a serialized format could be much more
directly usable...
I also liked the idea of packages.
I was considering a textual archive format for some of my own projects (the
one I was imagining, however, would still be "binary safe"). the format
(unlike more traditional archive formats) could retain type/file specific
metadata.
it is also possible to store files as multiple chunks.
I could make provisions for things like updates, multiple forks, ... as
well.
the basic format is much more trivial, the header encoding is vaguly similar
to http. I designed it primarily to be used as a protocol, but designed it
so that it can be used as both a protocol and a file format.
ok, some fragments that demonstrate the basic encoding.
this is an example of how a simple http wrapper would look (note: the "C: "
and "S: " 's are not included in the data, but were included to specify
client and server, the '*' for content length was to save having to count
bytes, or make up a number...).
C: Namespace:
http://bgb-sys.sourceforge.net/mux0/http
C: Resource: /index.html
C: Method: GET
C: Message-ID: httpreq1
C:
S: Namespace:
http://bgb-sys.sourceforge.net/mux0/http/response
S: Resource: /index.html
S: Message-ID: httpreq1
S: Content-Length: *
S: Content-Type: text/html
S:
S: <html>
S: <head>...</head>
S: <body>...</body>
S: </html>
S:
S:
the exact properties are defined as "namespace specific", thus namespace is
the only required field.
parsers, however, need to take special note of any tags beginning with
'Content', as they have the capability of changing how things are structured
(no 'Content' fields, no content, presence of fields indicate presence of
content...). otherwise, no fields are allowed to effect the physical
structure of the file.
a possible limitation is that the file is limited to a flat structure (at
least in a general sense), but this probably makes things more general...
my heavy use of URL's is to make it so that 2 unrelated resources are quite
unlikely to conflict, and even if the reader has no understanding of the
used namespaces they can still parse the file (in which case it will just
look like a collection of records with possible attached data).
an archive format would necissarily have different namespaces, and probably
a record to give general info about the file, eg, something like:
Namespace:
http://bgb-sys.sourceforge.net/mux0/header
Media-Type:
http://bgb-sys.sourceforge.net/mux0/archive
ok, I am probably just sounding stupid.
