it's my birthday so you have to answer
-
Tell me more about this "JsonPath". Does it require reading an entire Json document into memory at once or can it read a stream an object at a time?
Full JSON path only works over a loaded document. However, there is a JsonTextReader that works a lot like XmlReader but it does have extremely fast skip mechanisms, including "SkipToField" that only do a partial parse. You can use the reader to navigate to the node you want, and then you can call ParseSubtree() to only load that subtree into memory, and then you can use JSON path on that. The trouble is I didn't implement the JsonPath, someone else did under the MIT license and I'm using it in my code. It's quite cryptic and undocumented so I think i might be able to modify it eventually, but not at the moment. It only works on an in memory model.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
;P (you don't really have to answer, but I'd like your thoughts) In all seriousness though, I have what is either A cool Json library (now supporting JsonPath) with one of the most ambitious demo projects ever built. Or, a cool Tmdb API access library with multilevel caching with a neat little Json component on the side. It's the same solution. Should I present it as two articles, each focusing on the relevant bit - like a Json one, and then a separate one for the Tmdb access api? Or should I try to roll this whole mess into one article?
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
I'd be in favor of two articles. One article that goes into all details just might prove to be too much for someone who's only interested in one part or the other. I'd say, write an article that dives into the details of your library, and then the second article (which can link to it) can focus on demonstrating how to use the library in your real-world app. *If* I've already your description correctly.
-
I'd be in favor of two articles. One article that goes into all details just might prove to be too much for someone who's only interested in one part or the other. I'd say, write an article that dives into the details of your library, and then the second article (which can link to it) can focus on demonstrating how to use the library in your real-world app. *If* I've already your description correctly.
you got it exactly right. this was my first inclination and i'm inclined to go with it after reading all the comments here. Thanks for your input.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
;P (you don't really have to answer, but I'd like your thoughts) In all seriousness though, I have what is either A cool Json library (now supporting JsonPath) with one of the most ambitious demo projects ever built. Or, a cool Tmdb API access library with multilevel caching with a neat little Json component on the side. It's the same solution. Should I present it as two articles, each focusing on the relevant bit - like a Json one, and then a separate one for the Tmdb access api? Or should I try to roll this whole mess into one article?
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
I'd start writing about one of them and then see if the second flows nicely into that or requires a second artyicle. GHood kluck, I'll be waiting to read it or them! CQ de W5ALT
Walt Fair, Jr.PhD P. E. Comport Computing Specializing in Technical Engineering Software
-
you got it exactly right. this was my first inclination and i'm inclined to go with it after reading all the comments here. Thanks for your input.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
;P (you don't really have to answer, but I'd like your thoughts) In all seriousness though, I have what is either A cool Json library (now supporting JsonPath) with one of the most ambitious demo projects ever built. Or, a cool Tmdb API access library with multilevel caching with a neat little Json component on the side. It's the same solution. Should I present it as two articles, each focusing on the relevant bit - like a Json one, and then a separate one for the Tmdb access api? Or should I try to roll this whole mess into one article?
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
1. Happy Birthday! 2. I was thinking of writing a tmdb utility myself... but then I thought someone else would probably do most of the work for me if I waited a bit. So I waited a bit and now... Voila! 3. Two articles would probably be better or one with two distinct parts.
- I would love to change the world, but they won’t give me the source code.
-
1. Happy Birthday! 2. I was thinking of writing a tmdb utility myself... but then I thought someone else would probably do most of the work for me if I waited a bit. So I waited a bit and now... Voila! 3. Two articles would probably be better or one with two distinct parts.
- I would love to change the world, but they won’t give me the source code.
Well, you should be happy with it as it covers all of the v3 api. It auto manages guest sessions. It's got dual caching - it does in memory caching on a per-thread basis for the objects - it's aggressive, it doesn't refresh at all - the in memory cache is intended to be used in a batch and then cleared. And then it has global url based caching where you can set how aggressive it is. It automatically recovers from TMDb's request limits too, so it will retry requests. It does automatic paging - you can get a range of pages as a result array in one call. It exposes the entire thing as an object model perfect for LINQing over. :) I'm actually almost done - but I'm going to post it without testing the entire api. The rationale is I'd rather put out something where a few of the calls don't work then make you wait the month it would take me to write tests for this. It's really easy to fix, especially the bugs that are likely to crop up (field names and urls) So that's the one caveat.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
;P (you don't really have to answer, but I'd like your thoughts) In all seriousness though, I have what is either A cool Json library (now supporting JsonPath) with one of the most ambitious demo projects ever built. Or, a cool Tmdb API access library with multilevel caching with a neat little Json component on the side. It's the same solution. Should I present it as two articles, each focusing on the relevant bit - like a Json one, and then a separate one for the Tmdb access api? Or should I try to roll this whole mess into one article?
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
Happy Birthday ! I look forward to seeing you grow up :omg:
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
-
Happy Birthday ! I look forward to seeing you grow up :omg:
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
I'm sure you'll be right behind me, love.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I don't agree with any of them.
Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
Agreed.
I wanna be a eunuchs developer! Pass me a bread knife!
-
;P (you don't really have to answer, but I'd like your thoughts) In all seriousness though, I have what is either A cool Json library (now supporting JsonPath) with one of the most ambitious demo projects ever built. Or, a cool Tmdb API access library with multilevel caching with a neat little Json component on the side. It's the same solution. Should I present it as two articles, each focusing on the relevant bit - like a Json one, and then a separate one for the Tmdb access api? Or should I try to roll this whole mess into one article?
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
My thoughts: Enjoy your birthday! Have a great day :)
-
Well, you should be happy with it as it covers all of the v3 api. It auto manages guest sessions. It's got dual caching - it does in memory caching on a per-thread basis for the objects - it's aggressive, it doesn't refresh at all - the in memory cache is intended to be used in a batch and then cleared. And then it has global url based caching where you can set how aggressive it is. It automatically recovers from TMDb's request limits too, so it will retry requests. It does automatic paging - you can get a range of pages as a result array in one call. It exposes the entire thing as an object model perfect for LINQing over. :) I'm actually almost done - but I'm going to post it without testing the entire api. The rationale is I'd rather put out something where a few of the calls don't work then make you wait the month it would take me to write tests for this. It's really easy to fix, especially the bugs that are likely to crop up (field names and urls) So that's the one caveat.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
Cool! I can hardly wait! :cool: ..actually I can. I have putting off this project for over a year now so a few more days won't make much difference.
- I would love to change the world, but they won’t give me the source code.
I'm excited too. It's a ton of work, but I plan to use it to do very cool yet quasi-legitimate things so it's probably worth the effort. :laugh:
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
Cool! I can hardly wait! :cool: ..actually I can. I have putting off this project for over a year now so a few more days won't make much difference.
- I would love to change the world, but they won’t give me the source code.
It will be posted today. I'm working on the article right now. For now, here's the source. GitHub - codewitch-honey-crisis/Json[^]
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
