Am 03.04.2013 15:37, schrieb Mayayana:
>(I had a bright idea that I could create a program
> combining a simple WYSIWYG webpage editor with the
> ZIP functionality.
> People could make a multi-page greeting, restaurant menu,
> sale flier, etc., send it via email as an EXE, and at the other
> end opening the file would cause it to unload into TEMP and
> open page 1 of the enclosed mini-website in the default
> browser. ...That was just before it was decided that security
> needed to be tightened in email and that EXE files shouldn't
> be accepted as attachments. :)
Just because it fits so well here for yor case...
The RichClient-lib in Version 5 (which is out now BTW -
abailable under:
www.vbRichClient.com/Downloads/vbRC5BaseDlls.zip (about 2.2MB)
It includes (based on it's bultin ZLib and 'gz'
compression-support) also a small Class: cWebArchive
This class can be used as a small Archiver against a
single "RootFolder" (and all its nested content - e.g.
as seen in a typical "WebRoot-Folder").
Compression can be done either into Memory (a ByteArray)
or against a normal (proprietary) Archive-File.
Decompression can be done either against the File-System -
(then writing back the nested Folder-Structure it contains) -
but normally it is used "InMemory" as a kind of "WebCache".
The latter mode can be used in conjunction with e.g.
the built-in cWebServer-Class (with this Class you can
write your own Webserver with only a few lines of
surrounding code).
Those surrounding "few WebServer-Codelines" could then
ensure, that a Browsers WebRequests (which could come
in e.g. over
http://127.0.0.1:8888/MyWebarchive.wac
or something) - that you serve an entire "Site" - as if
it was sitting behind a "real WebRoot-Folder" - but it
is then served directly from the equally hierarchical
behaving "WebCache-Archive-Class".
That's done over the Method: cWebArchive.GetContent
which offers a "Key"-Parameter, which interprets the
relative String-Part of an URL - (e.g. "/img/Some.gif"
or "/js/SomeJavaScript.js") directly - and hands out
the cached content then directly as a ByteArray,
ready to be served by the internal WebServer (who only
needs to place proper Mime-Headers in a final step,
before sending the Response back to the Browser.
It can hand out such a concretely specified Resources
also directly in 'gz' compressed format (which all
Browsers understand nowadays) - useful when the small
WebServer runs in the LAN or on the internet, to
minimize the transfer-volume over the wire.
So your idea could be "brought back to life" pretty easily,
when you send such a compressed "WebArchive-attachment"
instead - and offer an accompanying "Server- or Service-
App" over a Download-Link (to be installed only once on
a given system, then registering the FileName-Extension
"*.wac" (or whatever), to start-up automatically with such
a compressed Archive-File instead of a real "WebRoot-Folder".
Just my 2 cents to the topic... :-)
In case you are interested, I could provide a small Demo
for that (a small WebServer, which accepts such archives
as its "virtual WebRoot-Folder" - it's only 10-20 lines of
code or so.
This technique (when used on "localhost" - meaning the IP
"127.0.0.1" - on a free choosable port) is usually not
triggering FireWall-Warnings, because this IP is "hidden"
(not reachable) from outside the machine.
And it could be used also, to e.g. serve Application-
internal "Help-Pages", which could be build and developed
against a normal local WebRoot-Folder - but for shipment
of the App one could include such a compressed "WebArchive",
contained as a ByteArray-Resource directly in the Executable.
Olaf