hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> What I was actually thinking was that POV-Ray could use an image format as the
> actual file format for storing the SDL text, and the editor could extract it
> from that, display it, allow for editing, and re-save into the image file
> wrapper.
>
> Why do this:
> I guess the idea was that since POV-Ray already has the ability to
> parse/interpret image file formats already, it might be possible to somehow
> embed a series of text files into the image header - like includes, etc and use
> it kind of like a zip file.
>
> Also, then we could have the image and the code that generated it all in one
> place, so they aren't separated and lost/confused.

- keeping "image and the code" in one place, along with the includes, bg
image(s) etc, would be ideal.  a project oriented approach.  and zip would be a
good format.

- hate the idea/concept of "allow for editing, and re-save into the image file
wrapper".  if anything the other way round, keep everything plain human-readable
text and include image(s) and other binary content 'base64' encoded.

anyway, thanks, have a clearer picture now of the "silly idea".


> It might also be possible to implement security by obscurity, to protect certain
> parts of code that an author might not want users casually messing with.  If you
> really wanted to edit that code, you'd have to work for it, rather than just
> "Ooops!  I broke it!"

also not keen on this.  if an author feels .. so strongly, well, then don't
publish.  simples.


> But binary copy, hexdump, Tcp, and other tools might provide a sort of
> functional work-around / proof of concept to see how a suite of files could
> potentially be used ....

why binary anyway?  what's wrong with a plain text (or utf8) encoding?


regards, jr.

Post a reply to this message