no no no no no no no no

---

:)

  --Ethan McCutchen.....Thu Feb 24 03:18:10 -0800 2011

---

if you want access to that stuff, put it in a card.

  --Ethan McCutchen.....Thu Feb 24 03:18:41 -0800 2011

---

If it isn't in an actual card, maybe the API could provide a way to supply content for virtual cards? I think we may want that, but we need to think about the implications.

  --Gerry Gleason.....Thu Feb 24 04:47:30 -0800 2011

---

That's what I was thinking. Suppose you love Wagn, and want an install now to handle lots of things. And, you have legacy data in another system that for various reasons you aren't going to import right away. You want it to be visible in Wagn as cards and there's a module that lets you do that (as Virtual cards), but then people are surprised when that content doesn't show up when they Search for it. You're still not ready to import Wagn (maybe the legacy system integrates with things that Wagn doesn't). Hence, this ticket.

  --John Abbe.....Thu Feb 24 10:51:00 -0800 2011

---

if it's not a card, it's none of WQL's business. There is no way it's going to be simpler to give WQL access to non-cards than to import. We can make the imported cards slaves of canonical masters that live elsewhere -- I think this is going to be a vital pattern -- but I really really don't want WQL extending tentacles anywhere outside of cards. That blows our modularity, our distributability, and our coherence.

 

Obviously, we can keep talking about this, and of course I could be wrong about its impracticability, but PLEASE don't suggest to anyone that this is in our path until we've got some more concrete technical vision.

  --Ethan McCutchen.....Mon Aug 08 10:01:23 -0700 2011

---

Seems to me that we can now do this sort of thing with events, by importing the data into cards. In the example, when you save an image card, and event would extract the meta-data and create more cards.

---

I'm also thinking about this in terms of wanting to attach card content to legacy models to create hybrid applications. WQL would be important in the value of the hybrid.

 

Wondering out-loud here, seems like search/indexing systems might be a way to integrate. Split off the idea of content searching because you already have an external indexing system with a query API. Their might be deeper architectural benefits to this move anyway, you don't have to depend only on the DB's search capability and can get a faster, more flexible search.

---

I think I agree with what you're saying here, Gerry, but these are unrelated ideas, right? We're not interested in exposing external data to WQL, we're interested in:

 

1. figuring out the best way to import external data into cards (which would expose it to WQL, of course, but would make it no longer external).

2. optimizing card searches by way of some sort of indexing system.

 

I don't know how #2 works, but it doesn't involve WQL traversing non-card data, right? (Even an index would be based on card data, no?) I have several thoughts about indexing, but does that fit this?

---

In other words, I would see it as a pretty core design principle that Wagn NOT get lost in dealing with non-card data, and I would want either to push against that principle directly or structure the discussion in a form that embraces and reenforces the principle (this one doesn't seem to).

---

Agreed that #2 is really a bit of a different issue, but maybe I need to explain better why I brought it up here. The point is that if data is indexed by an external search engine, we wouldn't need to import the indexed content to Wagn in order to expose it to search. Instead we would need to send Wagn updates to the indexer and we would need to have WQL be able to use the external indexer.

 

I agree that Wagn should not have to deal with non-card data, I'm just saying that if (content) search is externalized, it might expose external data to search without Wagn dealing with it directly.