Communication Selection and Application Types

[formula1]

Its important to note that we are at very early stages so implementing all of this may not be beneficial in the long run. If we stick to play as we go, we may be better off. This may be a red herring

Concept

to be able to have events/requests/streams with a selector definition to choose where the event will go.

• https://github.com/aheckmann/mpath
• https://github.com/dfilatov/jspath
• http://jsonselect.org/#tryit
• https://github.com/joequery/JSON-Selector-Generator

This may make it easier to code or may just be a lost cause.

Pub Sub NameSpaces and priority.

Currently we have a pub/sub system up. Where applications listen to events and do the processing from there. This is excellent for the simple fact that some events are only for some applications.
However, in some cases multiple applications will both listen to the same event (like file opening). We can leave this up to the application to decide whether or not it can handle it or we can open it in all or only the first. As a result, there also needs to be a priority mechanism to allow certian application to override others

Applications

For Example: If all applications fall under a few catagories, we already can limit our search.

• File creator - Can create new files
• File Reader - Reads and renders files specified
• File Update - Can update an existing file
• File Creator/Deleter - Can Create Empty files or remove files
• File Indexer - Can scan directories
• File Encoder - Takes a file and changes them. These processes may have no gui, its possible to automate one by seeing a file and seeing all the avenues it can go down such as html->text, json->html, json->html->text. Greek->spanish, Spanish->chinese, Greek->spanish->chinese. etc.
• Process to Process Communication - Allows the serverside to start up a process and read and write to its stdout. This can also result to allowing the process to deliver the results to the user.
• Process to Remote Communication - Opens up a direct port to a remote location, able to deliver results to the user.
• User to User Communication - Can Give or Recieve a WebRTC stream to the user or to a process
• App Store - Retrieves lists of apps, displays them, calls the server installation
• App Manager - Displays apps available. Can close and Open. Also can make them headless (server only), minimize (not shown but still active) or active mode. Also displays notifications for permission requests as well as ability to delete installed apps.
• Auxillary - May or May not run a process and always delivers an output

Files

Files can be anything however they generally have some sort of metadata that we can gather allowing us to know what to do with them.

• MimeType
• Character Set
• Encoding
• Human Language - If applicable
• Size Limits
• Delivery Mechanism - A Gigantic File sent in one message is rediculous, however it may be the only way possible

As such, an application can also define what it can accept similar to the W3C Standard.

External Communications

When it comes to communication, they may want to recieve objects from multiple locations and etc. However, those locations either should have compatible applications or have arbitrary files that we can gather data about. This can result in chat systems, games or pretty much anything.

[zodern]

I never knew those libraries existed. They will be useful.

Pub Sub NameSpaces and priority

Do you mean that multiple apps could have the same method names? When I started Silk, I had expected each app would have it's own server and handle their own methods. Now that Silk handles methods for apps, it will be a problem. Right now if an app defines a method that already exists, the previous method is overwritten. It would be nice if a namespace is added automatically for each app, though that might be too much trouble.

Concept

I like the concept. The difficulty will be in priority or remembering defaults when there is multiple apps.

Applications

Those categories cover most apps related to files. Many apps will fall under multiple categories.

File creator - Can create new files
File Reader - Reads and renders files specified
File Update - Can update an existing file

Generally those are in the same app.

Some apps, like brackets, opens up a folder to work with. Maybe there could be an option to open a folder in an app.

File Creator/Deleter - Can Create Empty files or remove file

When would that be used except in a file explorer?

File Encoder is interesting. How will an app discover them and use them? Will they be dependencies apps need and installed if they aren't already?

Is File Indexer the file explorer or is it for indexing to search?

The app manager will probably get more responsibilities over time, but that is the basics.

an application can also define what it can accept similar to the W3C Standard.

That standard is much better than what the app defaults currently allows. The data could be stored in the window.json.

[formula1]

PubSub Namespaces

Ok, I can make it so that each application has direct Access to its own serverside scripts. However, I'm going to do this on my dev because it will probably easier there

Priority and Defaults

So I moved your app-defaults to its own application, however It makes sense for it to be core. In my opinion though, this should be under /core/user. There may be other things associated the user that would be application and manager independent.

Single application, Multiple Categories

I know the catagories fall under multiple things and we can compensate for that by allowing an application to have an array of categories or only one. These categories exsist for usability and possibly in the future security. Where Applications will only have access to what it specifies

File Create/Delete

This can be used in antivirus/malware applications, backup applications, zip applications, state saving applications

File Encoder Finding

With a method encode similar to fileopen, they can set an Accepts and Offers parameter in the window.json

File Indexer

This would not have read or write, only to traverse the directory and be aware that files exist

App manager most responsibilities

I would agree to an extent. An app manager may or may not be able to access certian folders that one of the other applications setup. Their purpose is to organize the windows and take orders from the user. This making them commonly only front end oriented and may not have any backend at all. Silk in my dev branch is an example of not having any backend

W3C Standard

Yeah thats the hope

Bigger Picture

This is a giant plan which may or may not be carried out immedietly and/or maybe never. Building a gui manager is not an easy task and may take alot of time. And there are other projects of mine I'd like to work on at some point in the future. As a result, this is just an idea for the time being for me

[zodern]

Another option for what an application can accept is using the api for Navigator.registerContentHandler.

There is a few ways we could implement this:

1. Have it on the client. The user would have to open the app and then choose if they want the app handling the file type.
2. Have the api on the server and integrate it with how app-defaults works. This seems unnatural since the api is normally in browser.

[zodern]

There also is https://developers.google.com/web/updates/2011/06/Registering-a-custom-protocol-handler.

[formula1]

Sry about not getting back to you
Yeah this looks good. At the very least applicable to what we are looking towards