[DGD] The battle of the protocols (was: A small toy)

[Raymond Jennings]

Just a small note, in case I was misunderstood.  My main gripe is with
browser implementors needlessly restricting apis available to scripts.  As
long as everything is properly vetted it's my opinion that intelligent
users who want to open ports, and who presumably have the appropriate
authority (possibly via Active Directory or what have you), should be able
to consent, and a well coded client side script should be able to cope with
denied permissions just as easily as network errors.

On Fri, Feb 10, 2017 at 6:41 PM, Raymond Jennings <shentino at gmail.com>
wrote:

> Browsers, however, are cross platform and there's a lot of apps that are
> being done as javascript.
>
> Supporting TCP and UDP is a critical API.  And yes, I'm talking general
> case. Your specific example is plenty good on its own, yes.
>
> Some of the messier parts of SkotOS (which I can't give exact details
> about) are designed specifically to work around the fact that browsers
> still do not provide an API for plain TCP/UDP.
>
> On Fri, Feb 10, 2017 at 6:06 PM, <bart at wotf.org> wrote:
>
>> On Fri, 10 Feb 2017 17:12:13 -0800, Raymond Jennings wrote
>> > On Fri, Feb 10, 2017 at 4:19 PM, <bart at wotf.org> wrote:
>> <snip>
>>
>> > > fairness, with one simple addition at the server side (for which I
>> used
>> > > node.js, but it is not the only solution)
>> >
>> > That, right there, is why I'm complaining.  The client side should be
>> > flexible enough to be able to do stuff WITHOUT requiring the server
>> > to make special accomodations or stuff.
>>
>> That would be nice, but the world is not ideal.
>>
>> >
>> > With a server just running code you control yourself?  Yes, fair.
>> > on the internet in general?  Not so much, and quite frankly it's a
>> > hassle anyway even on servers you control.
>>
>> I disagree.
>>
>> I went from 'ah yes.. javascript.. I last touched that 15 years ago'
>> through
>> installing node.js, going through a few examples, to writing the small
>> bit of
>> serverside and clientside javascript for that fortune.wotf.org site in
>> about 8
>> hours. I already had the lpc json stuff, so only needed a listener and
>> small
>> request handling object on the lpc side.
>>
>> You may want something on aws or whatever running a stack with node.js if
>> running it on your own server is problematic (I can't see why if it does
>> let
>> you run dgd). Its rather lightweight so for many things you'll be able to
>> use
>> one of the free solutions. Using that all you have to do is indeed take
>> some
>> of the example code from the node.js tutorials and morph it a bit to your
>> own
>> needs.
>>
>> A big hassle? not really. Not needed for your intended use cases? I can
>> see
>> that, and I can also see why its annoying, but its really not such a
>> difficult
>> problem to solve.
>>
>> As an aside, you may find the event driven nature of serverside javascript
>> oddly familiar as LPC coder.
>>
>> In my case it runs on a tiny dedicated VM on my vmware server, and makes
>> that
>> its lpcdb instance (running on a different physical machine with lots of
>> memory and fast storage) doesn't need any internet access at all, it only
>> needs to be able to talk to that specific VM.
>>
>> That setup has some obvious security advantages, which I'd otherwise have
>> to
>> get from for example a second DGD instance acting as frontend server.
>>
>> >
>> > You should be able to do stuff *without* having to go through a silly
>> > server-side process to HTTPify everything.
>>
>> Don't use a browser as it is expected to work in a fully httpified
>> environment ;-)
>>
>> Bart.
>> --
>> http://www.flickr.com/photos/mrobjective/
>> http://www.om-d.org/
>>
>> ____________________________________________
>> https://mail.dworkin.nl/mailman/listinfo/dgd
>>
>
>