Natural Event Syntax Discussion

NaturalEventSyntax continued

Here's a draft generic event and remote service protocol that is not intended to favor or lock one into any particular language, paradigm, or mark-up; yet be sufficiently flexible. (Being designed around "remote" services does not preclude local services. Also, title is a misnomer as this is not about a syntax. I'll call it "Eventop" for now if we need a working name for reference.) 

   srvc_status.error_count = "3"
   srvc_status.error_msgs.1 = "Tires are missing"
   srvc_status.error_msgs.2 = "Driver is drunk"
   srvc_status.error_msgs.3 = "No license plates"
   srvc_status.warning_count = "1"
   srvc_status.warning_msgs.1 = "Left tail-light cracked"
A prototypical event handler sample function: 

  function sample_event(inputs: treemap): treemap
    var outputs: treemap
    ...
    if inputs.fooBranch.barLeaf = "cat" then
      outputs.branchX.branchY.leafX = "foo"
    end if
    ...
    if noProblems then
      outputs.srvc_status.error_count = "0"
    end if
    return outputs
  end function
This is not to imply the results must be processed with functions or function-like blocks. They could be queued or sent from tables in a database, for example, with diff apps in diff languages reading from the reception table(s) and writing to the output tables(s).

A tree-map is chosen because it's relatively simple yet relatively flexible. EssExpressions were considered, but are too confusing to many people, and don't have native or sufficiently-close counterparts in many tools.

--top

[How does this standardise anything? Your proposed protocol is essentially "input and output that are isomorphic to JSON"; this doesn't enforce any of the consistency benefits you were extolling in NaturalEventSyntax, because it doesn't really enforce anything at all. Services may still use arbitrary keys in the dictionaries they're passing around, so there's no assurance that two services will be even slightly compatible. What benefit does this system afford over actually using JSON, which is in fact already available on all widely-used languages and paradigms? -DavidMcLean?]

Please clarify what you mean by "keys".

[In your above example, fooBranch.barLeaf is a key. The key in general is that which references a specific value in the dictionary. -DavidMcLean?]

It's local and unique to the event "call". It's like a local array. I didn't define any global (session-wide) data structures at this point (but may consider it if a common need found.)

How about you(s) rework SAYT as found in NaturalEventSyntax as JSON then, and show how it would work in a non-JS client. (I agree the name-spacing needs clarification, but it's only a rough draft right now).

[Hmm. Reworking it as JSON. The input to http://gigahard.mine.nu/~david/instant/docs/blended_instant.html is already a JavaScript object; I could change the request to the server and the response to be JSON objects as well, but it wouldn't be particularly useful to do so since only a single value (a simple string) must be transferred each way. What kind of non-JS client do you have in mind? -DavidMcLean?]

I see a lot of embedded function calls such that it's hard to tell where the interface itself starts and ends versus the example's implementation. How about FORTRAN. Primitive languages are generally a better test of cross-system communication. You can emulate such by only using explicit functions (no objects and no HOF's) in some other common language.

[The implementation part of that example is everything above the Sample Usage heading; there's quite in-depth documentation associated with pretty much every line of source, so it should be extremely clear what's going on. What do you mean by "embedded function calls", exactly? -DavidMcLean?]

[Why would FORTRAN be a better choice than JavaScript for demonstrating an interface to what are primarily Web services? FORTRAN is not actually usable for any Web app's client-side implementation, nor would it be of much use if it were. In addition, it doesn't have a built-in DictionaryDataStructure; this makes representing a JSON interface quite impractical, but, critically, it also makes representing your proposed protocol equally impractical. Shouldn't we be focusing on languages that are likely to be used along with this possible protocol? Those languages that make what you're proposing easy (Python, Ruby, and indeed JavaScript are the major ones) also make JSON equally easy. -DavidMcLean?]

It would be better because it doesn't assume much in terms of language features. A side benefit is that non-programming and semi-programming tools can more easily hook into it. Incidentally, one can emulate nested maps in Fortran and wrap it in function API's. It's not fun to implement, but is doable. You can assume one is passing in string paths.

[Your protocol assumes exactly the same language feature that JSON does, namely a DictionaryDataStructure. How is it different? -DavidMcLean?]

For one, JSON doesn't define an "event" or "service calls" protocol. Second, some may want to use XML instead of JSON. Sure, one can define XML equivalent to any JSON structure, but why choose JSON as the root reference structure? JS may die out.

It's more likely that JSON won't die out (at least, not in any relevant period of time, i.e., the lifetime of a project) than your "generic event and remote service protocol" will succeed. No disparagement meant by that -- it's an obvious truth. Unless you're prepared to implement it -- such that people can actually use it -- it's not even worth discussing. No one is going to implement it for you, and if it's not going to be implemented, why waste time considering VaporWare?

For the sake of argument, let's study the approach assuming it uses a JSON tree-map data structure, or at least not worry about how the tree-map is encoded for now.

[Alright. Let's see your proposal in action. How do you implement, say, search-as-you-type? (We're dwelling on that example a bit, but we do already have directly comparable implementations of it so it seems a good choice.) -DavidMcLean?]

Keep in mind that this is not a GUI protocol, at least not out of the box. Something else would have to take care of GUI issues and the interaction details would depend on the specific GUI system or interface used.

As far as the server interaction of SAYT, it could provide the search results. Assuming we use the asynchronous events, an On-Change GUI event (in the GUI system/app) could call our asynchronous "send" event above with the contents of the search box. The display-match-results portion of the GUI side could look in the asynchronous "receive" event queue to get the results data, format and display it.

[So far, sounds like a slightly lower-level version of NodeJs; this is reasonable, because Node's event model is a good one to be mimicking. Let's actually see it in action, though. Demonstrate something, perhaps with code samples. (Also, why should the "receive" event queue need to be accessed directly? Doesn't this proposal have event listeners?) -DavidMcLean?]

That's a language- or app-specific feature. This draft protocol doesn't specify how or when the incoming events are processed, only that the client has some queuing potential if it's not able to digest them quickly.

[Why delegate the concept of "run this when an event arrives" to specific implementations? Isn't the ability to register a listener on particular events important enough to include in the standard? Actually, I'd go so far as to suggest that having some sort of event mainloop, along with listeners registered to deal with specific events, is essential to the very concept of event-driven programming. So why aren't listeners and the mainloop included as part of your event protocol's standard? -DavidMcLean?]

I disagree. That's language or tool-specific. I gave an example of where the event queues could be RDBMS tables and it's up to apps to decide what they want to do with the data. (It's also possible to put On-Change DB triggers on the tables, if the RDBMS supports them.) We can suggest by convention that in-coming events run a language-specific event handler or some sort, but OOP-ish libraries may choose to use objects and FP languages choose to use HOF's, etc. Why dictate a paradigm up-front? Language-specific crap is what fucked up GUI World for an entire generation. SplitOperatingSystemIntoServices

[Is your rudeness necessary? Having an event loop and listeners isn't language or tool-specific. It is paradigm-specific---specific to the EventDrivenProgramming paradigm---but what you're designing is an event protocol. Why not build it using event-driven programming design? -DavidMcLean?]

Insulting technologies (non-people) is fair game. There are too many ways to implement event handling. Why hard-wire one particular way, especially if it goes against the flavor of a language/tool/favorite-programming-style?

[What common ways to implement event handling don't involve a mainloop and event listeners? -DavidMcLean?]

I don't know, I rarely dissected their underlying implementations. That's the more the business of compiler writers and such.

[You claim that there are "too many ways to implement event handling" but don't actually know what ways exist?]

Are we talking about at the machine-code level, or the language level?

[Either. You claimed there were "too many ways to implement event handling". What are some of the ways you were referring to? -DavidMcLean?]

At the language level one can use at least OOP, HOF's, or polling loops.

[How are those different ways to implement event handling? Are they not all equivalent to "a mainloop with event listeners"?]

TuringEquivalancy?? Perhaps, but why does it matter? Why should the standard dictate the event-handling "flavor" on app programming side? Again, that kind of over-specification is what got the world stuck with language-specific GUI's. To serve as a communication platform for a wide range of languages, tools, and devices; that's over-specific. We leave and pick up the packages on the front porch, but who and how you check and/or place the packages there is up to YOUR household: you can sit Gramps there to whistle whenever a delivery comes, or you can open the door and check every half hour, or you can only check when you get home from work, and hope your porch is big enough to hold a day's worth.

[No, not TuringEquivalency. These-things-are-the-same-thing-as-each-other equivalency. Event-driven programming through OOP is implemented using a mainloop and event listeners stored in objects' methods. Event-driven programming with higher-order functions is implemented using a mainloop and event listeners registered by being passed into a higher-order function. Polling loops quite obviously involve a mainloop, and unless there's only one event in existence you need to dispatch to different handlers from the polling loop. The details of how event listeners are registered and how the mainloop is spun differ between these things, certainly, but the actual premise of a mainloop that spins through the events and dispatches them to event listeners is unchanged. So, what ways are there to implement event handling that aren't equivalent to "a mainloop with event listeners"? If there aren't any, how can there be too many ways to implement event handling? -DavidMcLean?]

Three is already too many. The fact that they may be implemented similarly on the machine-code level is irrelevant. I'm not sure mainloop is the only way to implement such, but it doesn't matter. It's a lower-level detail that the std. has to care about.

Incidentally, how is dumping the incoming events to an event table(s) which are then shared and processed by multiple apps an implementation of "mainloop"?

[How do the apps process events? In order to handle each event in their respective queues (which could be some view of the event table), they've got to loop over them, no? -DavidMcLean?]

It's up to the app. They may only look at the queue once or a million times.

[If an app looks once, what happens if it doesn't find the event that it's looking for? Wouldn't it need to look again until that event shows up? -DavidMcLean?]

Again, that's up to the app. It may send an email to the user saying, "Nothing new found. Go back to whatever you were doing." Maybe the user is the "mainloop" because they press the "See if anything in queue" button :-)

[Why would you want that? If you have an evented system, why base it on a manual-refreshing button when it could just as easily check for new stuff automatically? -DavidMcLean?]

That's the app designer's question. One possible scenario is that too many people leave a monitoring app open on their desktop even when not using it such it floods a given server with queries. The app developer may decided to solve that by adding an explicit "refresh" button to make sure an actual human wants the info, and thus cuts down on queries being processed.

[And it would be better to add a forced manual refresh button instead of disabling the refresh after a given interval without focus/activity/whatever and automatically restarting it when the app is focused again… why? -DavidMcLean?]

An eyeball detector? Newer smartphones have it, but we shouldn't assume such would be available.

[No. Focus. The normal kind that we've had on computers ever since they started having more than one window. -DavidMcLean?]

Window focus and eyeball focus are not necessarily the same thing. I have dual monitors. Sometimes I drag my Outlook window to the other monitor so that I can see if new emails come in WHILE working on some other app. Technically, Outlook won't have "window" focus while I am work on the other app.

[Well yes, obviously window and eyeball focus are different. (I wasn't claiming otherwise, however.) That workflow is indeed disrupted by having a focus timeout stopping the automatic refresh, but that workflow is also broken by there being no automatic refresh and a manual button being required to initiate refreshing. If the app does indeed need to stop refreshing to reduce load on the server, the automatic method with either focus or activity shutoff is obviously preferable---users who're active in the app get refreshing as wanted, users who are inactive don't put load on the server, and no users have to be concerned with an extra button. -DavidMcLean?]

I think what you are suggesting is that that the app runs a refresh cycle for a fixed period of time (multiple looping) and then expires. Suppose the queue is typically updated only once every half hour anyhow, but the "status" query is resource intensive. The half-hour is beyond a typical refresh period such that it's not worth implementing and thus skipped. But anyhow, why are you micromanaging app design here? Let the app designers decide that. Yes, sometimes they do stupid designs, but that's their problem; I'm not trying to reboot all of humanity here.

[No, the app refreshes automatically infinity times, provided the user is interacting with it. When the user stops interacting for a given interval, the refreshing is disabled; when the user continues to interact with the app, the refreshing restarts. There's a fixed time period given, but it "resets" every time the user does something in the app; since we're trying to prevent inactive instances of the app from loading the server, the optimal method is to detect inactive app instances using such an activity timeout (possibly combined with a window-focus one) and disable those instances' accessing of the server. As for that which you've deemed "micromanaging"? Because you're suggesting that your protocol should allow certain functionality to support particular use cases, and I believe that the use case you chose as an example is a bad design. Why design your protocol specifically to support stupid app designs? Why not encourage better ones? -DavidMcLean?]

The scenario I gave was a monitoring application, such as monitoring servers, news events, suspicious product orders, etc. One does not necessarily "interact" with such in order to use (read) it.

[Certainly, but if you aren't able just to have it refresh automatically all the time always, since for example that overloads the server (as was your original premise here), it makes far more sense to disable and re-enable the refresh automatically based on activity than to eliminate automatic refresh entirely. Ideally, you'd start with only disabling refresh (or even just reducing the refresh rate) when the window is unfocused (or, better, if you have something like the HTML5 Page Visibility API, when the app specifically isn't visible). If that doesn't reduce load enough, disabling refresh after an inactivity timeout too may become necessary. Disposing of automatic refresh entirely isn't likely to be the right choice. -DavidMcLean?]

I covered those situations already. The window focus/visibility issue was covered in the "Outlook" scenario. The only known technology that would work would be eyeball detection. We are wondering into irrelevant trivia fights anyhow. I am not going to dictate app implementation decisions. If you do, then we just disagree and should cut it here.

In general, the "looper" (checker, try-er, poller, etc.) may be a couple or more servers or layers "down the road" such that the Eventop kit has no control over it.

[Why? What use cases mandate that Eventop not include its own mainloop, other than the scenario we've already discussed that is handled much better in another way? Remember, we don't want to encourage bad app designs. -DavidMcLean?]

The refreshing/recheck control mechanism may be on a different server or system. The client may be making such decisions, for example, but Eventop is being used on the server side.

And I've decided not to try to shape app design with the draft standard. If you want to make another standard that does try to shape app design, be my guest. I'll ignore it, though. I'm out to make a tool, not spank app designers.

From experience, shops are often a hodge-podge of different technologies and tools, and the organizational dynamics prevent a given developer from having control to design or change a good portion of it. Sometimes you have to use "push" when "pull" would be better, and vice verse. I'm not going to AssumeCanOpener, and will try to practice SeparationOfConcerns with regard to tool-sets.

[A specification that seeks to formalise events in the event-driven programming sense should be expected to formalise the meanings of basic eventing concepts like the "event", the "mainloop", and the "listener". It's not mixing unrelated concerns and therefore not violating SeparationOfConcerns to specify these primitives all together, because frankly they are all essentially meaningless in isolation; an event as defined by Eventop without some sort of handler is no different from any other DictionaryDataStructure, for example. -DavidMcLean?]

Then you are dictating architecture of the tool that uses the event protocol, which is both unrealistic and overreach.

[No, you aren't. You're defining the architecture of your event protocol. -DavidMcLean?]

More Specs

JuneThirteen

EditText of this page (last edited September 5, 2013) or FindPage with title or text search