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
PHPGroupWare here on Source Forge. They have a "main API" and a "plug-ins
API" that are both served from two independent places within Source Forge.
Otherwise I fear that all will cause it allot of confusion "here" for
newbies. DynAPI2+ is a start-point and should live alone. Next level
extensions require both a higher skill-set and a firm understanding of the
base API.
Secondly, as you move away from the "base API" viewpoints on implementations
will begin to diverge as you are beginning to embrace multiple development
languages (hence differing opinions).
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".
Anything you can do in PHP you can do in Java with a combination of servlets
and applets; you can just do it in a more "robust and scalable" way.
Multi-threading, n-tier, servlet pooling, threads, thread pooling, the list
goes on and on. Also, FileI/O is Java based so I don't understand the need
for a "montage of languages" to complete a simple I/O daemon.
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).
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".
Enough for now.
Later
Raymond
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Michael
Pemberton
Sent: Sunday, April 29, 2001 3:46 PM
To: [EMAIL PROTECTED]
Subject: Re: [Dynapi-Dev] New File Sturcture
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 textarea and access that way.
As I said, this is still a WIP but should be a starting point for all those
PHP coders out there. if anyone wants to create an equiv in another
language, this is where the altered file structure
comes into effect.
Robert Rainwater wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I have no problem with the file structure. But it just seems like a
> waste of time right now seeing as how we do not having anything but
> javascript files. Until I actually see some actual server-side
> components, there is really no need even thinking about it.
>
> - --
> Robert Rainwater
>
> On 4/28/2001, 12:53:40 PM EST, Henrik wrote about "[Dynapi-Dev] New File
Sturcture":
>
> > I'll stand on the cheering crowd for this proposal. My condition
however - overworked, ill, lack of creativity (possible connection) - kind
of gets in the way of being more constructive. But I
> > think the poll we had some weeks back is one thing that speaks in its
favor.
>
> > Henrik Vċglin [[EMAIL PROTECTED]]
>
> > ----- Original Message -----
> > From: "Michael Pemberton" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Friday, April 27, 2001 4:55 PM
> > Subject: Re: [Dynapi-Dev] New File Sturcture
>
> >> There are already some needs for code other than JS. I believe that we
should work on
> >> an official server side set of code such as the remote server security
work around.
> >>
> >> i also think that we should be making room for users to but their own
code in their
> >> setup without the need for confusing the file layout. I see no point
in mixing the
> >> official images in with the JS code.
> >>
> >> Robert Rainwater wrote:
> >>
> >> > -----BEGIN PGP SIGNED MESSAGE-----
> >> > Hash: SHA1
> >> >
> >> > Since there aren't other components in the official distro other than
> >> > js, I'm not sure what use this would be. I understand how it could
be
> >> > beneficial, but I just don't see why we need it for the DynAPI.
> >> >
> >> > - --
> >> > Robert Rainwater
> >> >
> >> > On 4/26/2001, 5:21:11 PM EST, Michael wrote about "[Dynapi-Dev] New
File Sturcture":
> >> >
> >> > > I did something similar in my work-version and i think it's
definitely a
> >> > > good idea to structure things like this.
> >> > > and as long as the structure inside the dynapi-folder doesn't
change there
> >> > > aren't many things to change.
> >> > -----BEGIN PGP SIGNATURE-----
> >> > Version: GnuPG v1.0.4-1 (MingW32)
> >> > Comment: For info see http://www.gnupg.org
> >> >
> >> > iEYEARECAAYFAjrolGwACgkQTn30a43L7D8+UQCghF5M8qqOD5/efDrKZbENoJ9d
> >> > 2HsAoLHi6O+wN5B4wUu7sGR8IQ12bAq5
> >> > =yssi
> >> > -----END PGP SIGNATURE-----
> >> >
> >> > _______________________________________________
> >> > Dynapi-Dev mailing list
> >> > [EMAIL PROTECTED]
> >> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> >>
> >> --
> >> Michael Pemberton
> >> [EMAIL PROTECTED]
> >> ICQ: 12107010
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Dynapi-Dev mailing list
> >> [EMAIL PROTECTED]
> >> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>
> > _________________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
>
> > _______________________________________________
> > Dynapi-Dev mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.4-1 (MingW32)
> Comment: For info see http://www.gnupg.org
>
> iEYEARECAAYFAjrq96IACgkQTn30a43L7D/UJgCgiPCJ7G/vUTVITd68Ctj1kMlt
> 1KcAoNApQfAY7/qsL1iHBJGP2Obq0xsM
> =H+NE
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Dynapi-Dev mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
--
Michael Pemberton
[EMAIL PROTECTED]
ICQ: 12107010
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.250 / Virus Database: 123 - Release Date: 4/18/2001
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.250 / Virus Database: 123 - Release Date: 4/18/2001
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
