shadowsrising-devtalk

[Shadowsrising-devtalk] Multiple Cores?

[ProgrammerMatt <pro...@gm...>]

Hey, I think this concept was wrapped up as a minor one I had in an email o=
r=20
forum post a while ago (hard to seperate them these days), but anyway...

Have you considered allowing that one backend qSite could host multiple=20
cores? While I haven't worked out the technical details, I only see the nee=
d=20
to (as fit into my plans for qSite already) write an interface to determine=
=20
what core a certain gameID is and then run interference for the core and=20
qsite. This has a most immediate benifit of being able to host SR and QS at=
=20
the same time if one desires. I don't think it would be too hard to set up=
=20
and since I am already seperating the core from qsite in the most extensive=
=20
way possible by providing interfaces that will allow communication between=
=20
the core and qsite but no direct communication takes place other than=20
inheritance of 'common.inc.php'. Cores would still be in the 'core' folder=
=20
but inside folders (example /core/qs and /core/sr).=20

Not deserving of a additional email...

I know that you have expressed disinterest in using AJAX as people may not=
=20
have javascript enabled and you were planning on eliminating all javascript=
,=20
including the login authentication and I was wondering why this highly=20
secure feature was being earsed, as I will soon be rewriting the=20
authentication class for optimizations and that interface to the core I=20
mentioned earlier). The greater concern with AJAX is also with wether IE=20
users have the ActiveX control needed (I still haven't figured out if it=20
comes with IE). Anyway, I have been working out a way of client-side=20
detection of javascript and output based on that or such. Anyway, assuming=
=20
that it doesn't pan out and you have no other ideas of how to do that and w=
e=20
decide to either go with AJAX or not I was wondering of the case of no if w=
e=20
would still do the admin interface in AJAX even if the standard user doesn'=
t=20
have AJAX support.

Thanx,
PM

--=20
<a href=3D"http://www.spreadfirefox.com/?q=3Daffiliates&amp;id=3D67508&amp;=
t=3D72"><img=20
border=3D"0" alt=3D"Get Firefox!" title=3D"Get Firefox!" src=3D"
http://sfx-images.mozilla.org/affiliates/Buttons/88x31/rediscover.gif"/></a=
>

RE: [Shadowsrising-devtalk] Multiple Cores?

[Pádraic B. <mau...@ho...>]

Hi Matt,

First up, if you think multiple cores are workable then fire ahead. On a 
slightly context basis, I'm wondering whether we should shift references to 
'game' to 'app', e.g. gameID to appID. Basically the backend will be general 
enough not to be completely game specific (hopefully anyway). That last is a 
niggling little point anyways...

On the last - after actually going and trying out some AJAX integration, I'm 
back to requiring Javascript. Maybe I'll go through a JS optional phase 
again soon...;) My earlier point wasn't to move away from javascript but to 
enable the game to run without it as an absolute requirement (in that case 
those with JS would get more UI benefits, those without would get a lite 
version). Sorry if I gave the impression I was going to remove all 
javascript.

Currently in QS, I have two areas using AJAX (spec. xajax since you seem to 
be using that library). I'm still experimenting to an extent to set 
conditions in the source code so AJAX is only loaded when required 
(otherwise we'll take a processing hit even when not required - it's too 
heavy to be a basic include). I'll be testing JSpan soon for comparison.

I'm also experimenting with overLib and AJAX to allow dynamic popups - could 
be a useful element, e.g. to see a fleet's info, simply pass mouse over 
Fleet Name and a popup with the info would appear after an AJAX transaction. 
OverLib would be pre-loaded through Smarty.

As for IE and AJAX - IE from v6 should include ActiveX for the 
xmlhttprequest feature. Oddly, it was Microsoft who released its specs, so 
they certainly support it. It's one MS technology that you can't help but 
like...;). I doubt there's much trouble in that respect. Older v5 browsers 
would be a problem - but as I may have mentioned on my Blog some time ago, I 
have no intention on supporting older browsers - too much trouble and effort 
for little gain. The only concern in this respect is to ensure the AJAX in 
use is actually using xmlhttprequest since technically it's not the only 
option for enabling AJAX. I seriously doubt that's an issue, xmlhttprequest 
is the obvious choice for AJAX since it's supported by all the main 
browsers.

Later,

Padraic

-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
Pádraic Brady

aka Maugrim The Reaper
http://www.quantum-star.com/
http://www.shadowsrising.net/
-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-

>From: ProgrammerMatt <pro...@gm...>
>Reply-To: ProgrammerMatt <pro...@gm...>
>To: sha...@li...
>Subject: [Shadowsrising-devtalk] Multiple Cores?
>Date: Fri, 22 Jul 2005 11:15:58 -0500
>
>Hey, I think this concept was wrapped up as a minor one I had in an email 
>or
>forum post a while ago (hard to seperate them these days), but anyway...
>
>Have you considered allowing that one backend qSite could host multiple
>cores? While I haven't worked out the technical details, I only see the 
>need
>to (as fit into my plans for qSite already) write an interface to determine
>what core a certain gameID is and then run interference for the core and
>qsite. This has a most immediate benifit of being able to host SR and QS at
>the same time if one desires. I don't think it would be too hard to set up
>and since I am already seperating the core from qsite in the most extensive
>way possible by providing interfaces that will allow communication between
>the core and qsite but no direct communication takes place other than
>inheritance of 'common.inc.php'. Cores would still be in the 'core' folder
>but inside folders (example /core/qs and /core/sr).
>
>Not deserving of a additional email...
>
>I know that you have expressed disinterest in using AJAX as people may not
>have javascript enabled and you were planning on eliminating all 
>javascript,
>including the login authentication and I was wondering why this highly
>secure feature was being earsed, as I will soon be rewriting the
>authentication class for optimizations and that interface to the core I
>mentioned earlier). The greater concern with AJAX is also with wether IE
>users have the ActiveX control needed (I still haven't figured out if it
>comes with IE). Anyway, I have been working out a way of client-side
>detection of javascript and output based on that or such. Anyway, assuming
>that it doesn't pan out and you have no other ideas of how to do that and 
>we
>decide to either go with AJAX or not I was wondering of the case of no if 
>we
>would still do the admin interface in AJAX even if the standard user 
>doesn't
>have AJAX support.
>
>Thanx,
>PM
>
>--
><a 
>href="http://www.spreadfirefox.com/?q=affiliates&amp;id=67508&amp;t=72"><img
>border="0" alt="Get Firefox!" title="Get Firefox!" src="
>http://sfx-images.mozilla.org/affiliates/Buttons/88x31/rediscover.gif"/></a>