Feb 26, 2013 at 3:22 AM
Edited Feb 26, 2013 at 3:59 AM
Yeah, I know I have sort of had some trouble properly grokking how to set up the authorizers and which one to use where (also what the difference between the credentials are and what applies to what). My first test project was using the
, but then I needed to switch to one that allowed me to specify all four keys from a static source, so I think that's
, but the name threw me at first. They're all authorizing a single user, right? That's the idea, as far as I got it: always the app+acting-user; so, at first I wasn't sure that was the right one.
WRT the entities themselves, the one thing I found myself confused by is what the separation of input and output properties was and how, sometimes, properties that look like they should have a value, given their name, don't have a value, and that value is actually
elsewhere. The LINQ-like wrapper is really a brilliant piece of abstraction, but I wonder if a separation of Criteria and Result entities might be/might have been a bit clearer to understand.
That sort of ties into another thing ... I get that causing the "collection" to be "enumerated" is the thing that fires off the queries. So, anything that does that like
or whatever. But, if the two entity types did separate, you could make your own custom thing that's intended to be the "final" method that would both cause the enumeration
project the sequence of criteria objects into a sequence of result objects. Of course, this just the result of a weekend's worth of thought and nothing more than me just throwing ideas at you for the sake of transmitting my experience using this
That's funny you should say...
[...] such as moving to OAuth on public streams [...]
Does that mean it's not set up that way? Is that why I'm still trying to figure out why it's giving me a 401 Unauthorized while the REST stuff is working?
As for Mono/portable ... the
code is DLR stuff, right? Is that even implemented in Mono or the portable versions? Seems like that kind meta-programming programming would be ... a non-trivial bit of code to implement in a runtime.
Supporting async would be pretty cool. I've been looking for a reason to use it at work and I just haven't found the right hole for that shaped peg. That would almost require you to fork the code, though, right (for the purposes of compatibility with previous
framework versions)? Unless you could somehow pull the execution code out into modules where one does it the old way and one does it the new way, I guess.
Oh, one other thing, why do you have the repository folder structure set up so differently from the solution's folder structure? Just curiosity, no judgment :).
: I just looked at the top of the streaming example. So that means I have to type a literal user/password for the streaming to work? If that's the case, couldn't LinqToTwitter give a bit more of a warning that that's what I was missing?
: Okay, I also just loaded up the LinqToTwitterDemo
project. Now I see where all the documentation examples come from and why none of them show how the
variable is initialized. Looking through this now...
: So, I think I need to remember to read more of the source before I complain about a problem :). I got it to connect with the user/password. I definitely agree that getting OAuth to work for that would be good though. Kind of odd to
have to do it this way.