I fully agree with the splitting of the project, I see no problem with having
the extensions built separately, I do however believe that the API should be
built with extensions in mind.
In my current structure, the type of language matches the file extension and
directory. this would mean that w
> (2) Lets face it, IE is rapidly approaching ubiquitous levels. In
addition
> to baseline DOM support MicroGreed also adds a series of "proprietary
> extensions". The API's extension would be a great place to explore
> expanding the "base" API into IE-centric add-ons (most of these can
actuall
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/29/2001, 9:38:04 PM EST, Digital wrote about "[Dynapi-Dev] New File Structure":
> In my opinion PHP is not the path of choice for server-side deployment.
> PHP4 has some fundamental flaws in how it references objects in general.
> Rumor has it
Ok, time for the "rockman" to put a little input here. I've put a
"disgusting" amount of time in server-side strategies. Before I get to that
I agree with the overall strategy to expand the scope and depth of the API.
That said I think the best path is one similar to that deployed by
PHPGroupWa
attached is the latest versions of my server side scripts. be worned that they
require the AfroAPI FileIO code to work. this is the most reliable method of
downloading content. The
download_wrap.php file should be able to be used to wrap the output of a url to allow
it to be downloaded in a
Hi...
Resizing the window in the dynapi.gui.list.html example makes the list
vanish and if you then click on e.g. 350 you get the file index of the
current web directory...
S.
--
Any sufficiently advanced bug is indistinguishable from a feature.
___
