Loading components and sub-components

[dmichiels]

There are several problems in the actual way to load components and sub-components :

• The component are load from bytes-code (thanks Stewart!)
• Each components call the library component.oz. It's the library that must call each component.
• The path is used, while we assume the type is sufficient to load a component/sub-component.

Actual situation :

% Component
[Display] = {Module.link ["./components/display.ozf"]}
D = {Display.new theName}
% Sub-component
[Subcomponent] = {Module.link ["./lib/subcomponents.ozf"]}
Calculator = {Subcomponent.new theName theType "./components/calculator/calculator.fbp"}

The future version :

[Component] = {Module.link ["./lib/component.ozf"]}
[Subcomponent] = {Module.link ["./lib/subcomponent.ozf"]}
Display = {Component.new displayName display}
Calculator = {Subcomponent.new calc1 'calculator/calculator'}

Calling the correct library with a name and a type will generate the component or subcomponent. The path argument is remove for the {Subcomponent.new} function.

The declaration of a component will stay a functor, but it will not generate running component, it will declare the component record.

functor
export
    Component
define
    Component = component(
        description:"display the IP"
        output(output res)
        procedure(proc{$ Ins Out Comp} ... end)
        ...
    )
end

The description will be mandatory (#60). The name and type features will disappear. They will be set when the library component.oz create the component.

To be easily share and open-source, the component library will only load .oz file, in plain text. That will allow people to inspect the code they will run, and force the license open-source.

[dmichiels]

Going a little deeper in this idea, I think there still weird things in the proposition above. The component and sub-component doesn't have to create components from files, but from records. Actual graph.oz must manage this part, and component.oz and sub-component.oz must only receive the record they need.

So, for the end user, it will be :

[Graph] = {Module.link ["./lib/graph.ozf"]}
Display = {Graph.load displayName display}
Calculator = {Graph.load calculatorName 'calculator/calculator'}

It will load component and sub-component on the same way. The user doesn't care about the extension of the component, he just precises the type!

The create function of the library component.oz :

[Comp] = {Module.link ["./lib/component.ozf"]}
R = component(name:aName procedure:proc{$}...end ...)
{Comp.new R}

and for the subcomponent.oz

[Sub] = {Module.link ["./lib/subcomponent.ozf"]}
R = graph(nodes(display(comp:C) ...) inLinks:[a#b#c] ...)
{Sub.new R}

[sjmackenzie]

Agreed.

Our initial proposition was that NDN functionality would be in graph.oz

This works well. On that note... shouldn't we also provide connection information to graph.oz? This way it can load it and immediately connect it up?

[dmichiels]

Yes, I realize that graph.oz is in fact Fractalide. This library decide how we manage with the different components, how we load them, how we save them (format), ... component.oz and subcomponent.oz must not be aware of all that, they are just one component.

What do you mean by "connection"? It's about the link for the output port? Or it's related to the network?

[sjmackenzie]

I mean how the components are linked together.

Indeed, Fractalide is but a graph!

If we can keep it as simple as possible and pusd as much infrastructure into components rutnning on the graph, then we might be going in the right direction.

[dmichiels]

graph.oz is use only for the graph creation, all the topology is saved in the components.

For the link information at creation time, I don't think it's fully possible. The component must be created to be linked together.

[Graph] = {Module.link ["./lib/graph.ozf"]}
Gen = {Graph.load iipGen genopt}
Disp = {Graph.load displayer display}
{Gen bind(output Disp input)}

You can see that impossible to give the Disp entry point to Gen when this last one is created! It will make the things more complex for a not complete feature (because here it's simple to swap the two line, but loop will exists!)

[sjmackenzie]

vertex == component == node edge == link

'Graph' essentially means vertices and edges. Essentially this level of abstraction should contain link information and vertex information (name and type). Recall that a card can be data, gui or logic -- indeed all three at once if one is mad enough.

Right now we have independent nodes intelligent enough to setup and tear down edges. Great. But who should tell them to setup and teardown an edge? Who should hold information about topology? Hard to say! Imagine if each node follows the agent based model (https://en.wikipedia.org/wiki/Agent-based_model) ie they follow simple rules and can setup and teardown connections to other nodes according to those rules. Then the emergent behaviour needs to be queried! Who issues the query? Would it be graph.oz?

Graph.oz also opens some other interesting functionality say I choose to create a graph database using components!? similar to neo4j (https://en.wikipedia.org/wiki/Neo4j) recall we should also be able to handle data! The original Hypercard has a database, maybe we could create a graph database to swap out HyperCard's database? I could issue a query to graph.oz and it would be intelligent enough to query the nodes as it has enough knowledge of topology. What if we wanted our data components to be intelligent enough to autonomously connect to nodes nearby? What if we had a graph spanning over two computers, and nodes (components) wanted to make the decision that they wanted to migrate themselves autonomously to the other machine as they have more edges to nodes on that machine? Thus we have nodes reshuffling themselves according to how many connections they have.

If we want to be able to create a graph database then each edge needs to have an associated oz record to store information about itself (ie distance=32km)

What if we introduced NDN style communication between nodes, and the way they communicate with one another is via flooding and selective receive?

This application is opening up some major new possibilities: video: http://player.vimeo.com/video/56040747#t=0m14s

I suggest you add the graph db idea to your thesis. (ie swap out HyperCards database for a graph database)

This isn't as simple as it looks, the decisions we make now could open up a whole new dimension to Fractalide.

Lets just focus on the thesis and put everything on the backburner. We have some serious Hammock Driven Development to do (http://data-sorcery.org/2010/12/29/hammock-driven-dev/) (https://www.youtube.com/watch?v=f84n5oFoZBc)

[sjmackenzie]

Seems quite interesting http://hypergraphdb.org/learn?page=DataFlow&project=hypergraphdb

[sjmackenzie]

page 3 http://novamente.net/file/AAAI06.pdf

[sjmackenzie]

Neat little tutorial using HyperGraphDB http://code.google.com/p/hypergraphdb/wiki/RealWorldExample

Fractalide's output ports could equal the java beans "getAuthor" (which maps to this bit of code: hg.eq("author", "me"))

graph.oz could have a query output port that connects to each component "query" input port. when you issue the hg.eq(...) statement then an IP is sent to the Book component telling it to output whatever is on the author output port. As graph.oz has a 'query' input port connected to 'author' output port then it could make the equality check. the output could be a tuple query#me thus other nodes (not graph.oz) will not do anything when they receive this tuple.

Hence quite possibly graph querying becomes possible. Indeed... graph.oz could connect its input port to a component connected further down the processing line. so the graph could actually perform transformation and extract whatever is calculated.

hmmm brainstorming

[dmichiels]

waw, so many ideas and good concepts! I admit my head in not in the best condition to do a brainstorm (too tired and mono-focus), but the ideas will grow with time.

I don't read very well all your links, missing time, but I have already some ideas.

A first reaction I have is to ask if graph.oz is the best place to implement a db. A little as we say that the stack can be card, the db can be card. Take the simple example of the stack : it's a card that have a ordered list of other cards, and can switch from one to the other like an placeholder. It also understands next, previous, find, add, ...

It could be interesting to keep graph.oz really simple, just load a sub-net/graph. The basic behavior will be simple to proof correct and to maintain.

Then, we could "easily" add a (complex) db card. This card will understand action that represent query : eq, ... as you propose. If the user want to make a db of his card, he can create a new simple graph :

content(usercard) out -> in db(dbcard)

Then, the user can query the db component!

If we want that Fractalide have this db behavior by default, we can simply add this new card automatically when a card is loaded, as we will automatically put the card in a QTk window!

It is to switch more quickly in "all is a card" and leave the oz code as small as possible.

[sjmackenzie]

oh wow yeah we can do all that just in FBP.

Yes this is a better approach indeed. Keep graph.oz, component.oz and subcomponent.oz minimal. Build everything from there.

Yeah okay I'm dropping this, it's occupying too many thought cycles. Later!