FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Progress

 
Post new topic   Reply to topic     Forum Index -> DSP
View previous topic :: View next topic  
Author Message
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Mon Feb 07, 2005 9:45 pm    Post subject: Progress Reply with quote

Thought I'd post here with some of my progress notes.

I took a break from DSP to investigate other possibilities for parsing and code generation. I wound up writing a CMS which is presently in a closed beta, serving up my homepage:

http://www.djsolaries.com/pragma

I'm rolling out a sandboxed templating language loosely based on DSP called CML. In order to get this moving efficently on PHP, i meshed an XML parser and a PHP-based Javascript compiler. The result is an engine that generates, caches, and executes PHP scripts.

The only downside to such a thing (aside from not using D for the 'scripted' parts) is that there's no way to implement "cut-across" scripts in DSP. This is because the page *must* validate as proper XML or it just won't parse. The upshot is that the developer is forced to create XHTML compliant pages, so its great for design pedants. Razz

Of course that also means that there's no way in CML to arbitrarily *not* emit an XHTML tag attribute which (might) cause problems with checkboxes that rely on 'checked' in that way. For now, the designer simply has to eat those limitations.

Anyway, I've learned that DSP's current parser implementation (in all its hackish glory) is probably the best blend of flexible code and targeted parsing. As has been mentioned before, it does not care about correct markup, just as long as the DSP-specific tags close up correctly.

I'm also leaning back toward the ColdFusion-style code inlining (using '#') due to its ease of parsing; using { and } causes trouble since they're so frequently used in D.

Dll's have gotten a great deal of attention in the DNG lately, due mostly to Kris and myself. Walter made quite a buzz when he released a means to hook the GC; a feature I anticipated from the word 'go'. However, it does little to solve DSP's requirements for 'reloadable' dll's.

With a hooked GC, the only bits that completely transcend the dll boundary are primitives and arrays of primitives (most of the time, this means 'ints and strings'). However, code still stays put which causes objects to be even more bothersome than before. Hooking allows for states like objects without valid v-tables, and function-pointers going weak (invalid).

Where does this leave DSP? After some exhaustive testing, I've concluded: the same place as always. As I tried to tighten down the paradigm that would lead to 'reloadable dlls' I stared long at my UML diagram. The solution suddenly leaped out at me:

RELOADABLE == REMOTE

The pattern for a reloadable dll maps perfectly to a remote object server. The core similarity is along the 'connection' that binds the dll/remote to the process: the connection is assumed to be unreliable. Also, both entities retain their own code and memory spaces... including garbage collectors.

Therefore, one must establish object-like behavior via proxy and copy all data that travels between the two connected parties. The ultimate tradeoff is communication overhead (copying and de-referencing) for flexibillity.

The good news for DSP is that most interaction with servlets in a dll will be at the beginning and the very end of a service request. Also, the boundary can be soft (pass object references w/o proxy) as long as we can guarantee that no copies and references will be kept on either side (excepting proxies of course). This goes especially for references to other 'reloadable' objects.

I now feel more comfortable with the design than ever. I'm off to further investigate how well this concept meshes with Mango. Much coding soon to follow.

Also I've been brainstorming about the following future features:

    - XML-driven configuration engine for stand-alone Mango servers, with pluggable server modules (almost working)
    - release builds: compile an application's servlets together into a single library.
    - DMC-built apache plugin lib for the apache version of DSP.
    - Sandboxed runtime library for D, which is desperately needed for obvious reasons ("Ares-lite" perhaps?).
    - Anti XSS, arbitrary-code and URL-obfuscation filters for added security in scripts. (No web platform to date has all this out-of-the-box)

_________________
-- !Eric.t.Anderton at gmail
Back to top
View user's profile Send private message Yahoo Messenger
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Mon Feb 07, 2005 10:09 pm    Post subject: Reply with quote

Hey there Eric; Glad to see you're back on the job Smile

Two comments:

Quote:
Therefore, one must establish object-like behavior via proxy and copy all data that travels between the two connected parties. The ultimate tradeoff is communication overhead (copying and de-referencing) for flexibillity.

That's sounds cool, but surely you can do the same with a "lightweight" proxy, such as an Interface? I guess I just don't understand why the latter wouldn't work. Can you help me out with that, cos' we're both trying to achieve a similar thing?

Quote:
Sandboxed runtime library for D, which is desperately needed for obvious reasons

Aye; I need that too. I've also been thinking about using DScript as a servlet language, but have some concerns regarding the debugging procedures, and so on. Thoughts?
Back to top
View user's profile Send private message
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Tue Feb 08, 2005 7:43 am    Post subject: Reply with quote

kris wrote:

That's sounds cool, but surely you can do the same with a "lightweight" proxy, such as an Interface? I guess I just don't understand why the latter wouldn't work. Can you help me out with that, cos' we're both trying to achieve a similar thing?


Welll the idea is to have a proxy that contains a weak reference to the actual object. That way the real object can be pickled, its host dll reloaded, then unpickled and reassigned to the appropriate proxy. Sadly, this means that the servlet server has to halt... but reloading a servlet lib should be mostly a development cycle thing anyway. Smile

kris wrote:

Quote:
Sandboxed runtime library for D, which is desperately needed for obvious reasons

Aye; I need that too. I've also been thinking about using DScript as a servlet language, but have some concerns regarding the debugging procedures, and so on. Thoughts?

[/quote]

I looked into that too, but I find the license on dmdscript to be a tad restrictive. Plus I feel that its way past time for 'bare metal' web application programming for the masses. IMO, bringing another interpreted language to the web arena won't achieve the kind of extra value I'm looking for.
_________________
-- !Eric.t.Anderton at gmail
Back to top
View user's profile Send private message Yahoo Messenger
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> DSP All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group