Nerdin' out
Not all of you care about the development side of MU*, or even know what a MU is, so here's a nice shiny LJ cut to cut down on your daily spam.
As everyone who knows the technical side of me is pretty much aware of by now, I'm historically a XML whore. For over a year now I've been politely hinting to Akari that this is something I'd love to see in ProtoMUCK, but Akari's got plenty of things to do as it is between work and the various games she runs.
A few months ago I became aware of something called JSON, mostly because Google had been moving away from using XML as part of the AJAX applications they write. "But my precious XML! Google is usually pretty smart, why would they do this to me?"
And so my line of thought persisted until about two weeks ago, when I actually took a look at www.json.org as part of a conversation about MUCKs and webservices. It...was simple. Very simple, and functional. I'll still keep XML in my toolbelt as a document formatting language, but I have to agree that JSON is a much better tool for data serialization.
The long and the short of it is that I've already written a JSON parser+unparser for MUCK in softcode. I consider it beta quality and it'll never RFC-compliant JSON support unless full Unicode support gets added on the ProtoMUCK or Fuzzball sides of things, but it's good enough to handle the first 7 bits of UTF-8 that are backward compatible with ANSI. ...Which is pretty much everything I personally need it to handle, I suspect.
Where am I going from here? My next project is a sturdy HTTP client library for ProtoMUCK. ProtoMUCK can already handle HTTP if it's acting as the server, but the real strength of having JSON is the ability to interact with external services, like Google Calendar. Once that's done, I'll be writing two sample applications and releasing the whole kit.
1: JSON Library
2: HTTP Client Library
3: MUCK-to-MUCK object copy service
4: Google Calendar interface
This is pretty exciting stuff to me. I've had pictures in my head of this sort of interoperability for a few years now, so it's really neat to know that I can realistically have these things working very soon now.
I can't really think of anyone other than rika who would want to fall asleep eyeballing a draft of the program header for LIB-JSON.MUF, but here you go. I'd go ahead and release the library, but I want to make sure it's properly vetted with proof of concept apps #3 and #4 before it goes fully public.
As everyone who knows the technical side of me is pretty much aware of by now, I'm historically a XML whore. For over a year now I've been politely hinting to Akari that this is something I'd love to see in ProtoMUCK, but Akari's got plenty of things to do as it is between work and the various games she runs.
A few months ago I became aware of something called JSON, mostly because Google had been moving away from using XML as part of the AJAX applications they write. "But my precious XML! Google is usually pretty smart, why would they do this to me?"
And so my line of thought persisted until about two weeks ago, when I actually took a look at www.json.org as part of a conversation about MUCKs and webservices. It...was simple. Very simple, and functional. I'll still keep XML in my toolbelt as a document formatting language, but I have to agree that JSON is a much better tool for data serialization.
The long and the short of it is that I've already written a JSON parser+unparser for MUCK in softcode. I consider it beta quality and it'll never RFC-compliant JSON support unless full Unicode support gets added on the ProtoMUCK or Fuzzball sides of things, but it's good enough to handle the first 7 bits of UTF-8 that are backward compatible with ANSI. ...Which is pretty much everything I personally need it to handle, I suspect.
Where am I going from here? My next project is a sturdy HTTP client library for ProtoMUCK. ProtoMUCK can already handle HTTP if it's acting as the server, but the real strength of having JSON is the ability to interact with external services, like Google Calendar. Once that's done, I'll be writing two sample applications and releasing the whole kit.
1: JSON Library
2: HTTP Client Library
3: MUCK-to-MUCK object copy service
4: Google Calendar interface
This is pretty exciting stuff to me. I've had pictures in my head of this sort of interoperability for a few years now, so it's really neat to know that I can realistically have these things working very soon now.
I can't really think of anyone other than rika who would want to fall asleep eyeballing a draft of the program header for LIB-JSON.MUF, but here you go. I'd go ahead and release the library, but I want to make sure it's properly vetted with proof of concept apps #3 and #4 before it goes fully public.