February 08, 2012
On 2012-02-08 02:33, James Miller wrote:
> As somebody that frequently laments the lack of documentation in
> general (I use Silverstripe at work, in which the documentation is
> patchy at best) I work hard on my documentation.
>
> Adam's stuff is very good, I plan to take a look at it and "borrow"
> some code for a web framework I'm working on. But I am also
> open-sourcing modules that I am using as I go along. It would be cool
> if we ended up with a set of independent modules that worked well
> together but had few dependencies.
>
> I guess the point is whether Adam is ok with the community extending
> his work separately, since
> "misc-stuff-including-D-programming-language-web-stuff" isn't exactly
> a catchy name :P.
>
> It would be unfortunate if Adam's work wasn't built upon, and that
> work was needlessly replicated, then tightly integrated into some
> other project, rather than being something that everybody could use.

Maybe Adam's code can be used as a base of implementing a library like Rack in D.

http://rack.rubyforge.org/

-- 
/Jacob Carlborg
February 08, 2012
On 2012-02-08 02:44, Jonathan M Davis wrote:
> On Tuesday, February 07, 2012 00:56:40 Adam D. Ruppe wrote:
>> On Monday, 6 February 2012 at 23:47:08 UTC, Jonathan M Davis
>>
>> wrote:
>>> Also, two of the major requirements for an improved std.xml are
>>> that it needs to have a range-based API, and it needs to be
>>> fast.
>>
>> What does range based API mean in this context? I do offer
>> a couple ranges over the tree, but it really isn't the main
>> thing there.
>>
>> Check out Element.tree() for the main one.
>>
>>
>> But, if you mean taking a range for input, no, doesn't
>> do that. I've been thinking about rewriting the parse
>> function (if you look at it, you'll probably hate it
>> too!). But, what I have works and is tested on a variety
>> of input, including garbage that was a pain to get working
>> right, so I'm in no rush to change it.
>>
>>> Tango's XML parser has pretty much set the bar on speed
>>
>> Yeah, I'm pretty sure Tango whips me hard on speed. I spent
>> some time in the profiler a month or two ago and got a
>> significant speedup over the datasets I use (html files),
>> but I'm sure there's a whole lot more that could be done.
>>
>>
>>
>> The biggest thing is I don't think you could use my parse
>> function as a stream.
>
> Ideally, std.xml would operate of ranges of dchar (but obviously be optimized
> for strings, since there are lots of optimizations that can be done with
> string processing - at least as far as unicode goes) and it would return a
> range of some kind. The result would probably be a document type of some kind
> which provided a range of its top level nodes (or maybe just the root node)
> which each then provided ranges over their sub-nodes, etc. At least, that's
> the kind of thing that I would expect. Other calls on the document and nodes
> may not be range-based at all (e.g. xpaths should probably be supported, and
> that doesn't necessarily involve ranges). The best way to handle it all would
> probably depend on the implementation. I haven't implemented a full-blown XML
> parser, so I don't know what the best way to go about it would be, but
> ideally, you'd be able to process the nodes as a range.
>
> - Jonathan M Davis

I think there should be a pull or sax parser at the lowest level and then a XML document module on top of that parser.

-- 
/Jacob Carlborg
February 08, 2012
On 2012-02-08 03:29, Adam D. Ruppe wrote:
> Here's more ddocs.
>
> http://arsdnet.net/web.d/web.html
> http://arsdnet.net/web.d/dom.html
>
>
> Not terribly useful, I'll admit. The Javascript
> discussion at the bottom of the first link might be
> good to read though.
>
> The dom.html there is mostly just (incomplete) method
> listing. I didn't write most of it up at all.
>
> When I started doing dom.d, I was going to be strictly
> a clone of the browser implementation, so some of the
> comments still say things like "extension", but I went
> my own direction a long time ago.

I think a much better API, than the one browsers provide, can be created for operating on the DOM, especially in D.

-- 
/Jacob Carlborg
February 08, 2012
Am Tue, 07 Feb 2012 20:44:08 -0500
schrieb "Jonathan M Davis" <jmdavisProg@gmx.com>:

> On Tuesday, February 07, 2012 00:56:40 Adam D. Ruppe wrote:
> > On Monday, 6 February 2012 at 23:47:08 UTC, Jonathan M Davis
> > 
> > wrote:
> > > Also, two of the major requirements for an improved std.xml are that it needs to have a range-based API, and it needs to be fast.
> > 
> > What does range based API mean in this context? I do offer a couple ranges over the tree, but it really isn't the main thing there.
> > 
> > Check out Element.tree() for the main one.
> > 
> > 
> > But, if you mean taking a range for input, no, doesn't
> > do that. I've been thinking about rewriting the parse
> > function (if you look at it, you'll probably hate it
> > too!). But, what I have works and is tested on a variety
> > of input, including garbage that was a pain to get working
> > right, so I'm in no rush to change it.
> > 
> > > Tango's XML parser has pretty much set the bar on speed
> > 
> > Yeah, I'm pretty sure Tango whips me hard on speed. I spent some time in the profiler a month or two ago and got a significant speedup over the datasets I use (html files), but I'm sure there's a whole lot more that could be done.
> > 
> > 
> > 
> > The biggest thing is I don't think you could use my parse function as a stream.
> 
> Ideally, std.xml would operate of ranges of dchar (but obviously be optimized for strings, since there are lots of optimizations that can be done with string processing - at least as far as unicode goes) and it would return a range of some kind. The result would probably be a document type of some kind which provided a range of its top level nodes (or maybe just the root node) which each then provided ranges over their sub-nodes, etc. At least, that's the kind of thing that I would expect. Other calls on the document and nodes may not be range-based at all (e.g. xpaths should probably be supported, and that doesn't necessarily involve ranges). The best way to handle it all would probably depend on the implementation. I haven't implemented a full-blown XML parser, so I don't know what the best way to go about it would be, but ideally, you'd be able to process the nodes as a range.
> 
> - Jonathan M Davis

Using ranges of dchar directly can be horribly inefficient in some
cases, you'll need at least some kind off buffered dchar range. Some
std.json replacement code tried to use only dchar ranges and had to
reassemble strings character by character using Appender. That sucks
especially if you're only interested in a small part of the data and
don't care about the rest.
So for pull/sax parsers: Use buffering, return strings(better:
w/d/char[]) as slices to that buffer. If the user needs to keep a
string, he can still copy it. (String decoding should also be done
on-demand only).
February 08, 2012
On Wednesday, February 08, 2012 09:12:57 Johannes Pfau wrote:
> Using ranges of dchar directly can be horribly inefficient in some
> cases, you'll need at least some kind off buffered dchar range. Some
> std.json replacement code tried to use only dchar ranges and had to
> reassemble strings character by character using Appender. That sucks
> especially if you're only interested in a small part of the data and
> don't care about the rest.
> So for pull/sax parsers: Use buffering, return strings(better:
> w/d/char[]) as slices to that buffer. If the user needs to keep a
> string, he can still copy it. (String decoding should also be done
> on-demand only).

That's why you accept ranges of dchar but specialize the code for strings. Then you can use any dchar range with it that you want but can get the extra efficiency of using strings if you want to do that.

- Jonathan M Davis
February 08, 2012
On Wed, Feb 8, 2012 at 5:41 AM, Jacob Carlborg <doob@me.com> wrote:
> On 2012-02-08 03:29, Adam D. Ruppe wrote:
>>
>> Here's more ddocs.
>>
>> http://arsdnet.net/web.d/web.html http://arsdnet.net/web.d/dom.html
>>
>>
>> Not terribly useful, I'll admit. The Javascript
>> discussion at the bottom of the first link might be
>> good to read though.
>>
>> The dom.html there is mostly just (incomplete) method
>> listing. I didn't write most of it up at all.
>>
>> When I started doing dom.d, I was going to be strictly
>> a clone of the browser implementation, so some of the
>> comments still say things like "extension", but I went
>> my own direction a long time ago.
>
>
> I think a much better API, than the one browsers provide, can be created for operating on the DOM, especially in D.
>

I know very little about html programming but dart did just that. It is my understanding that they abandon JS's DOM and created their own API: http://api.dartlang.org/html.html
> --
> /Jacob Carlborg
February 08, 2012
On 2012-02-08 13:11, Jose Armando Garcia wrote:
> On Wed, Feb 8, 2012 at 5:41 AM, Jacob Carlborg<doob@me.com>  wrote:
>> On 2012-02-08 03:29, Adam D. Ruppe wrote:
>>>
>>> Here's more ddocs.
>>>
>>> http://arsdnet.net/web.d/web.html
>>> http://arsdnet.net/web.d/dom.html
>>>
>>>
>>> Not terribly useful, I'll admit. The Javascript
>>> discussion at the bottom of the first link might be
>>> good to read though.
>>>
>>> The dom.html there is mostly just (incomplete) method
>>> listing. I didn't write most of it up at all.
>>>
>>> When I started doing dom.d, I was going to be strictly
>>> a clone of the browser implementation, so some of the
>>> comments still say things like "extension", but I went
>>> my own direction a long time ago.
>>
>>
>> I think a much better API, than the one browsers provide, can be created for
>> operating on the DOM, especially in D.
>>
>
> I know very little about html programming but dart did just that. It
> is my understanding that they abandon JS's DOM and created their own
> API: http://api.dartlang.org/html.html

It seems so. I haven't looked over the docs but it's good that someone is at least trying.

-- 
/Jacob Carlborg
February 08, 2012
On Wednesday, 8 February 2012 at 07:37:23 UTC, Jacob Carlborg wrote:
> Maybe Adam's code can be used as a base of implementing a library like Rack in D.
>
> http://rack.rubyforge.org/

That looks like it does the same job as cgi.d.

cgi.d actually offers a uniform interface across various
web servers and integration methods.

If you always talk through the Cgi class, and use the GenericMain
mixin, you can run the same program with:

1) cgi, tested on Apache and IIS (including implementations for methods
that don't work on one or the other natively)

2) fast cgi (using the C library)

3) HTTP itself (something I expanded this last weekend and still want
to make better)




Sometimes I think I should rename it, to reflect this, but meh,
misc-stuff-including blah blah shows how good I am at names!
February 08, 2012
On Wednesday, 8 February 2012 at 07:41:54 UTC, Jacob Carlborg wrote:
> I think a much better API, than the one browsers provide, can be created for operating on the DOM, especially in D.

I'd say I've proven that! dom.d is very, very nice IMO.
February 08, 2012
On Wednesday, 8 February 2012 at 12:11:40 UTC, Jose Armando Garcia wrote:
> is my understanding that they abandon JS's DOM and created their own API: http://api.dartlang.org/html.html

That actually looks very similar to what the browsers
do now, which is a good thing to me - you don't have
to learn new stuff to sit down and get started.

But, looking through the Element interface:
http://api.dartlang.org/html/Element.html

you can see it is very familiar to the regular browser
API. It offers some of the IE extensions (which rock btw;
I implemented them too. outerHTML, innerText, etc.)


It doesn't actually go as far as I do in expanding the
api though.