-----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 that PHP4.1 will shift to the more "appropriate and broadly
> used syntax". Secondly PHP doesn't scale well at all. It's great for
> "small scale 2-tier implementations".
There are many studies that would say otherwise, but there's no need
to start an argument over this.
> Additionally, I think the base API should focus on "staying lean and mean"
> and solving some fundamental problems. That being:
>
> 1) Memory Issues (API and Widget) - This needs a focused effort as it is
> probably the greatest handicap this API has right now.
> 2) Documentation and Instruction - Linked to (1), we may have improved the
> base API for memory but widgets need a structured approach so they can be
> built "memory safe" as possible.
> 3) At a minimum get the current API at least to the point of the prior with
> at least "ONE" workable solution for the Macintosh. Netscape 4 was hosed by
> the last release.
> 4) Begin to develop a strategy for development of DynDOM development and
> outline when "cross-over" should happen. My projections put the ability to
> abandon IE4/NS4 out at "least" 18 months, but API's don't happen over night
> and our widget base should migrate seamlessly (in a perfect world).
DynAPI 3 (a DOM implemention) will not be compatible with DynAPI 2.
Mainly because implementing a DOM API can be done in a much simplier
manner. Thus, many of the conventions used currently, are too complex
and not needed when implementing a DOM based API.
> API EXTENSION DIRECTIONS
> (1) A server-side strategy. This may become a series of options if elements
> faction into different deployment camps.
> (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 actually
> be built into CSS formats to shield them from unsupported browser. I'm
> prepared for Spam on this issue, but my opinion is that this API should
> "seek" to represent both a stable-core and the ability to deliver the
> "state-of-the-art".
The distro should never, ever, contain IE specific extensions. The
whole point of the DynAPI is cross-browser. If you want IE
extensions, then you can provide them separately.
Rob
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4-1 (MingW32)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjrsyoMACgkQTn30a43L7D8yIwCgobU5ICFn7jejgyE//JVlDgxZ
IFEAoLvqwOR1EriORZ5REY0nArvbGXHh
=V589
-----END PGP SIGNATURE-----
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
