First login?
Lost password?
 
 
 
General mailing list for discussions and development of PeerLibrary and related software.

List archive Help


Re: [PeerLibrary dev] PeerDB vs. Meteor collection queries


Chronological Thread 
  • From: Mitar < >
  • To:
  • Subject: Re: [PeerLibrary dev] PeerDB vs. Meteor collection queries
  • Date: Thu, 14 Aug 2014 06:10:38 -0700
Hi!

You could store reactive variable into template instance:

https://github.com/peerlibrary/peerlibrary/blob/development/client/publication.coffee#L1648

We are storing it into data and not template instance, because in the
older version of Meteor we are still using, there was no way to access
template instance from a template helper. Now they have a
UI._templateInstance() now, which you can call inside a template helper
to access an instance. Can you test how this works in new templating
engine? If one store a reactive variable inside a created method onto
template instance, and then have a template helper access that template
instance and use value from the reactive variable, if reactive variable
changes, does template helper rerenders?

I must say that I don't agree completely with your quest against global
state. This is how I imagine it:

URL should contain a global state of the application. If you copy-paste
URL into another browser, you should get the same state, user interface,
location of the publication, same dialog opens, etc. For PeerLibrary, I
would imagine something like that:

https://peerlibrary.org/path/which/determines/entity/we/are/showing/plus/maybe/slug?values&in&various&forms#hash_of_the_rest_of_the_ui_state

So then URL is parsed out and Session is configured based on it.
Currently we are not yet using query strings or hash segment. But I
think that using Session for such things is OK. So to use Session to
guide which parts of the UI is shown, which page is shown, which
publication is shown, which dialog box is open, etc. This is the state
of the application. And once it is stored in the global state (and I
like that it is an explicit state, not just many global variables), then
you can do things like storing this state in a hash segment of the URL
(we store it on the server and return a hash for it), so that users can
share it with others. Hot-code push and autoreload is also possible, we
can push when we have a new version of PeerLibrary to the client, while
client is working, and it autoreloads into a new version, without user
having to reload anything manually. This is where I would like to get
eventually.

So for me using Session is not so problematic. But there are cases where
state should be internal to the template instance and we are using this
already as well. (Mostly connected with storing of the information which
is connected with data loading states, is data already available, is
searching in progress, etc.)

BTW, Meteor GitHub tickets are meant only for bug reports and not
discussion. You should use meteor-talk or meteor-core mailing list for
discussion. (In PeerLibrary is different and we prefer everything in one
place.) (The only exception was for new Meteor templating engine Blaze,
but even that they started discouraging.)

If you want to dive into one more aspect of Meteor, their use of fiber,
pleas help me with this. I am stuck:

https://stackoverflow.com/questions/25248493/how-to-use-fibers-with-streams


Mitar

> fyi: Nico started a discussion on global variables in meteor:
> https://github.com/meteor/meteor/issues/2402
>
> We've played around a bit and we're much more familiar with the best
> practices in meteor. A lot of the confusion I had came from the use of
> global variables in meteor ("session"). I simply could not imagine that a
> framework encourages the use of global variables in 2014. ;-) Hopefully, we
> can fix this in meteor and in peerlibrary.
>
> Cheers,
> André
>
>
>
> Mitar
> < >
> schrieb:
>> Hi!
>>
>>> OK, now I've understood that you have to manually subscribe (on the
>>> client) and publish (on the server). Imagine I have 2 different
>> queries
>>> for persons on the same page. Then I subscribe two times to the
>>> search-persons endpoint and all Persons matching any of the two
>> queries
>>> end up in the client's Person document class? So I've to filter them
>>> again on the client?
>>
>> Hm, this is a bit tricky question. So search-persons is really a
>> special
>> endpoint (BTW, I am calling things "publish endpoints" because for me
>> it
>> is much clearer than "publish functions" or just "publish" which is
>> often used elsewhere in Meteor community). For how it is currently
>> designed, you can have only one search query active at a given moment
>> for an entity. But this is because we are using only one field for
>> search results for each entity. We could change this a bit, but there
>> was no need for that until now.
>>
>> So let's discuss some other publish endpoint. But for all other
>> subscriptions (so one which do not use full-text search through
>> ElasticSearch) you should subscribe not based on queries but based on
>> which data you want to have on the client. And this often depends on a
>> view (page) user is on. For example, you want information about a
>> group,
>> and all members in the group. So you subscribe on the group and you
>> subscribe to all members in the group. And then you can do arbitrary
>> queries against this data.
>>
>> How complicated queries you allow to be send to the server we decide.
>> This is what our public API will be later on. The collection of publish
>> endpoints. We could allow that user's can request a publication of
>> documents for arbitrary MongoDB query by defining such a publish
>> endpoint, but we are in fact very conservative and allow only
>> publishing
>> based on IDs or some very restricted set of fields (the latter,
>> currently mostly wrapped into search).
>>
>> So maybe an easier way to think is that multiple subscriptions are
>> merged on the client. So you could subscribe for documents from author1
>> and create another subscription for documents from author2. Then you
>> would have on the client document from author1 and author2 available to
>> do queries on.
>>
>> This works even on the field level. You can have one subscription to
>> get
>> some fields and then another to get another, for the same document. But
>> it is limited only to top-level fields.
>>
>> One interesting thing having such federation between server and client
>> where data is kept in sync and you have same query language both on the
>> server and client, is that you can run exactly the same code both on
>> the
>> server and client. This allows things like latency compensation (which
>> we are not yet using in PeerLibrary), easier code for input validation,
>> etc.
>>
>> But again, the main complications is then how to define publish
>> endpoints and how you subscribe to them so that you have all data you
>> need for queries on the client when you need it, but not more. In the
>> worst case you could do:
>>
>> - subscribe with query and get documents for the query to the client
>> - wait for data to come to the client
>> - repeat the same query on the client on the documents you have
>>
>> But this is not really how you do, because it would take quite long.
>> User would have to wait for the query, for data to get to the client,
>> and then you would be able to do something. You could, but you do not
>> really do it like this (maybe we will in some cases). Mostly, what we
>> currently do is subscribe to the document or documents when you get to
>> the page (having a nice progress bar, which we do not yet have, while
>> this data is loading), and then do queries later. In most cases this
>> works, because at least currently we have mostly one URL one entity or
>> known list of entities mapping. So for publication page you subscribe
>> to
>> that publication. And if you need some more data, we sync that in as a
>> subdocument with PeerDB.
>>
>> (What I just described is not latency compensation. That is something
>> else.)
>>
>> (I am hopping that I am not making you even more confused.)
>>
>>> Btw, I'm not complaining about Meteor not providing enough. I'm just
>>> trying to see the benefits and downsides of it (compared to
>> techniques I
>>> know).
>>
>> :-)
>>
>> Feel free to write-up what you learn sometime. In general: as you are
>> learning, thing all the time to write things down. Documentation (wiki
>> pages) for new contributors are missing a lot. We should expect that
>> most of our potential contributors would be coming from outside Meteor.
>> So please, help. This is probably one of the most important things you
>> are doing now. Learning how to start contributing. So document and
>> think
>> about how to make things easier for people coming after you.
>>
>>
>> Mitar
>
> --
> Homepage http://page.math.tu-berlin.de/~gaul
> github https://github.com/andrenarchy
> Twitter https://twitter.com/#!/andrenarchy
> Diaspora https://diasp.org/u/andrenarchy
> (you won't find me on facebook!)
> Jabber
>
> PGP Key 0x0FA9170E
>

--
http://mitar.tnode.com/
https://twitter.com/mitar_m

Archive powered by MHonArc 2.6.18.

Top of page