phpwebsite-developers

[Phpwebsite-developers] Update

[Matthew M. <mcn...@tu...>]

Brian Brown is close to finishing the roadmap. I can't say when it will be 
done because often something comes up that needs discussion before putting 
it on paper. We don't want to rush the roadmap for the same reasons you 
wouldn't want a literal roadmap to be hurried... it causes people to get 
lost.

In the meantime we are certain about two things 1)their will be a rewrite 
and 2) we need to secure the currrent version. I know bug smashing isn't as 
interesting as writing new code but we would appreciate any developers to 
hit sourceforge then CVS to fix what is broken.

As to why it has been quiet, we are all discussing the rewrite, I am coding 
the calendar upgrade/plugin, Brian is researching almost everything you are 
suggesting, Jeremy is maintaining the servers, Adam is researching and 
working on template formats and Brian L. is completing a help system. Don't 
mistake our occasional silence as a lack of interest. We are listening and 
are excited about the future =)

Thanks again to everyone for their time and devotion. Have a great holiday. 
Matthew McNaney

Systems Administrator
Career Development Center
Ph: 828-262-2180
Fax:828-262-2834

[Phpwebsite-developers] Session Management

[Todd O. <to...@da...>]

What opinions do you have about placing the sessions in the database instead
of files in /tmp?  ezPublish uses the database approach.  We already use the
database for referral data instead of Apache.

--Todd

Re: [Phpwebsite-developers] Session Management

[clayton c. <cc...@ca...>]

I vote for the database. i hate the proliferation of all those files.
BTW - Todd, did you see my questions r.e. mmbase permissions ? i wasnt able
to find a reference ...

Re: [Phpwebsite-developers] Session Management

[Karsten D. <k.d...@tu...>]

On Wed, Apr 11, 2001 at 05:33:49PM -0400, Todd Owen wrote:

> What opinions do you have about placing the sessions in the database inst=
ead
> of files in /tmp?  ezPublish uses the database approach.  We already use =
the
> database for referral data instead of Apache.

What about PHP4 natvive sessions? If we use these (and they are very
efficient, as to what I have heard - I still have to try them myself during
the next days) - and give a lot of flexibility to the coder when it comes to
"how and where do I store session data".

Just my 2c,
Karsten
--=20
Why do we have to hide from the police, daddy?
Because we use emacs, son. They use vi.
-----------------------------
mailto:k.d...@tu... w=B3: http://www.k-fish.de/
gpg: http://www.k-fish.de/mykeys.gpg

Re: [Phpwebsite-developers] phpWebSite Road Map

[Todd O. <to...@da...>]

See http://www.datadx.com/phpwebsite/ for the eZsession class file and sql
files.  Brian's roadmap has us using native sessions, so consider the above
an educational experience.  Database sessions are a must IF we consider
webserver clusters where server_A will handle client request 1, but server_B
will handle the link to request 2.  I don't forsee a NEED for database
sessions at this precise moment, but I would like to abstract the session
management so they could be added in the future without a rewrite.  On this
same topic, the authentication management should also be similarly
abstracted to allow LDAP at some point in the future too.

The mmbase permissions aren't that easy to explain because they're not in
one place like most of the other projects I listed.  I vote for the ACS
style permissions as translated by Clayton.

I agree with Alain that the object functionality Brian mentioned was the way
I expected.  Does anyone have a link to a PHP discussion of the proposed
change?

I haven't seen any discussion about inter-module communication in the
Roadmap or otherwise.  Did anyone like my xml-rpc proposal?  I think the
"alert" model (Clayton's term) or trigger model (sql term) should be handled
by xml-rpc.  The receiving module would then handle it's own activities,
such as queing email for nightly transfer.  The sending module would get
confirmation that the receiver model got the message and would proceed
accordingly.  This keeps the responsibility of sending emails (let's say) in
the email module.

--Todd

Re: [Phpwebsite-developers] phpWebSite Road Map

[clayton c. <cc...@ca...>]

Todd,
> I haven't seen any discussion about inter-module communication in the
> Roadmap or otherwise.  Did anyone like my xml-rpc proposal?  I think the
> "alert" model (Clayton's term) or trigger model (sql term) should be
handled
> by xml-rpc.  The receiving module would then handle it's own activities,
> such as queing email for nightly transfer.  The sending module would get
> confirmation that the receiver model got the message and would proceed
> accordingly.  This keeps the responsibility of sending emails (let's say)
in
> the email module.
>
i think the thing im having a mental block with (not having looked at PHP
XML-RPC implementations), is how the "triggering" works. is there a daemon
running that handles the incoming requests, or are they handled pretty much
like standard page requests ?

-- clayton

[Phpwebsite-developers] xml-rpc

[Todd O. <to...@da...>]

Clayton,

http://www.xmlrpc.org is a great resource.  This site links to many xml-rpc
sites that act as tutorials.

--Todd

Re: [Phpwebsite-developers] xml-rpc

[Todd O. <to...@da...>]

http://www.phpbuilder.com/columns/luis20010329.php3

--Todd

Re: [Phpwebsite-developers] Update

[Jason C. <cam...@xp...>]

I'm going to start bug testing features and even have a bug testing site up 
for everyone to mess with once Jeremy gets the daily snapshots of the CVS 
code in tarballs then I can throw up a site with the CVS version.

Do you know if anyone has started on changeing the poll system and other 
features of the system as plugins or modules yet??  Brain mentioned it and 
didn't say if anyone was working on that now.  I would be willing to take 
any of the internal parts of the system and making them plugins.  I just 
want to make sure no one else is already doing it before I'd start work on 
it.

Jason Campbell
Xplozive Media Technologies

> Brian Brown is close to finishing the roadmap. I can't say when it will
> be  done because often something comes up that needs discussion before
> putting  it on paper. We don't want to rush the roadmap for the same
> reasons you  wouldn't want a literal roadmap to be hurried... it causes
> people to get  lost.
> 
> In the meantime we are certain about two things 1)their will be a
> rewrite  and 2) we need to secure the currrent version. I know bug
> smashing isn't as  interesting as writing new code but we would
> appreciate any developers to  hit sourceforge then CVS to fix what is
> broken.
> 
> As to why it has been quiet, we are all discussing the rewrite, I am
> coding  the calendar upgrade/plugin, Brian is researching almost
> everything you are  suggesting, Jeremy is maintaining the servers, Adam
> is researching and  working on template formats and Brian L. is
> completing a help system. Don't  mistake our occasional silence as a
> lack of interest. We are listening and  are excited about the future =)
> 
> Thanks again to everyone for their time and devotion. Have a great
> holiday.  Matthew McNaney
> 
> Systems Administrator
> Career Development Center
> Ph: 828-262-2180
> Fax:828-262-2834
> 
> 
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers