Yes I second that - async file and network I/O. And full REST support -
PATCH I think is not supported - or is that documented?
On 7 April 2015 at 23:44, Andrew Kluthe <and...@ctech.me> wrote:
> I'm not using LC server side much so I can't say for sure there in
> reference to this thread and the things we've been discussing. I think the
> direction livecode is going and the state that it is/was (I still use 5.5
> for a lot of things) in to be great.
>
> If we can get as many of the blocking bits down to a minimum as possible
> (specifically the url libraries), I think it would be perfect. The thing
> that peeved me most is that most of my DB work is not done by directly
> connecting to the database but some sort of api layer. Usually my LC apps
> are just clients for these apis (often built in Node or python if they were
> made in-house). I like the flexibility this gives me. They post some JSON
> and get a JSON payload back. If the payload is large, I've had to do things
> like use curl and some other things to make up for the built-in super
> convenient internet library just sitting locking the application while it
> waits to return. I've converted entire applications out of LC into other
> technology stacks just because of the kludge needed for this one thing. I'd
> love to be able to stream this stuff in a little bit at a time as well. I
> can get some desired results with regular GET request using load url with a
> callback but it doesn't help when I have to post a more complex query. This
> happens in my .NET apps as well, but I use the parallel task libraries .NET
> has to get around the UI lockups. I've been spoiled on some of visual
> studio's tooling features in the meantime too :P (intellisense, jump to
> definitions, some other things that i think will come to LC in time).
>
> I also have a node-webkit (now nw.js) application that I think would be
> perfectly suited to be done in livecode once things stabilize a bit (this
> has already started to happen) with the newer builds using Chrome Embedded
> Framework. I needed something with all the fine tuned styling I could get
> from web app we already have but running as a standalone against SQLite DB.
> We did this to reuse the same visual cues and javascript libraries that we
> use on the web version. We wanted a copy of the web application that could
> run completely without the internet. I think with just a bit of time, I
> could have used LC to do this comfortably.
>
> The short answer? An url library that can read a file off disk
> asynchronously (I think this can be done now using some of the other ways
> of doing disk access in LC, but it would be nice if the url("binfile:") bit
> did the same thing) and an url library that can return the response of a
> POST asynchronously (preferably returning chunks as they come in).
>
> The widgets architecture sets itself up to solve all of my other potential
> wants/needs, maybe even this one.
>
> On Tue, Apr 7, 2015 at 4:19 PM Richard Gaskin <ambassa...@fourthworld.com>
> wrote:
>
> > Andrew Kluthe wrote:
> >
> > >>>1. Livecode messaging is fully asynchronous. Not semi-async.
> > >
> > > Right, when I said semi-async I was referring to the single
> threadedness
> > of
> > > livecode (which node shares) along with all the baked into livecode
> stuff
> > > that blocks up messages currently: accessing a large file on disk,
> > posting
> > > some information to a web service with a large json payload being
> > returned.
> > > It's async, with some pretty hard to work around exceptions (url
> library
> > > specifically has been the primary source of past frustration in this
> > way).
> > >
> > >>>3. Livecode does not have closures = passing anonymous callbacks as
> > > params to functions so they can be executed later
> > >
> > > As for anonymous callbacks, I totally agree. Most early Node
> development
> > > had to overcome the callback hell that these patterns introduce.
> However,
> > > almost all of the nodejs projects and libraries I've worked with
> > leveraged
> > > them heavily or exclusively. Promsies seem to have become the standard
> > way
> > > of dealing with the callback hell that node was so famous for for a
> long
> > > time. Why does node use anonymous functions over the method you linked
> to
> > > in the article? Anonymous functions are marked for garbage collection
> > > immediately after being returned. All other functions at the global
> scope
> > > run the risk of needlessly using memory after they run. I've gotten
> into
> > > some hairy situations with memory management with these kinds of named
> > > callbacks (specifically for database access and return of lots of
> results
> > > when not scoped correctly).
> > >
> > > Passing a function (not just a name of a function to be used with a
> send
> > or
> > > a dispatch later on) as a parameter even in your article still
> > demonstrates
> > > something LC just can't do currently. In the article he's still using
> > > closures, it's just got a name instead of being anonymous. It's still a
> > > closure. LC has ways to accomplish similar things by passing names of
> > > functions and using dispatch, but I think it's not exactly the same.
> > > Closures are part of the reason node.js works the way it does and
> > closures
> > > are one of the pirmary reasons javascript was chosen for node. It's
> > > certainly possible to do async without them, but closures are what
> makes
> > it
> > > easy and kind of a fundamental principle to working in node.js.
> > >
> > >>>4. But we can easily call / dispatch calls to functions by passing
> names
> > > around and we can limit scope by using private handlers or libraries.
> > >
> > > Sure, there is nothing STOPPING us from implementing named callbacks in
> > the
> > > current fashion or passing the named callback references dynamically as
> > you
> > > and I mentioned, but from experience trying it this way I feel like it
> > > makes maintaining large projects built this way a lot more difficult.
> To
> > > the point where I ended up completely redoing most of the livecode
> stuff
> > > I've written in this way early on because it was getting to be a
> > nightmare
> > > to maintain a completely separate callback functions rather than the
> sort
> > > of nested structure you get in node with callbacks. It takes a lot of
> > > discipline in placement and grouping of the code that is related in
> this
> > > way to come back later and make sense of it. In summary: it can be
> done,
> > > but that doesn't mean that it SHOULD be done.
> > >
> > > Kind of a weird long post there. Sorry for the length and probable
> > > repetition of my points.
> >
> > Not at all - good stuff.
> >
> > What would you say would be the minimum we'd need to add to the LC
> > engine to make it suitable for the sort of work you do?
> >
> > --
> > Richard Gaskin
> > Fourth World Systems
> > Software Design and Development for the Desktop, Mobile, and the Web
> > ____________________________________________________________________
> > ambassa...@fourthworld.com http://www.FourthWorld.com
> >
> > _______________________________________________
> > use-livecode mailing list
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> _______________________________________________
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
