We can't win them all.  Such is how the proverbial cookie crumbles.

I have compiled all of my online resources into a focal wiki entry.  My intent is for anyone who wishes to continue this project to be able to pick up where I left off.  There is quite a bit of reading to be done, but by my best estimate, someone with intimate knowledge of Joomla!'s core would be able to finish this project in under a few days.

Of course, since this project is listed on my own personal wiki, the guarantee is implicitly present that I will, at some point, return to it.  Of this you can all be certain. :)  So if nobody else beats me to it, I'll have a finished product down the road.

My only regret is that I could not finish it in the time allotted.

Thank you to everyone for all your invaluable help and assistance this summer.  To say it has been a learning experience would be an understatment.  Thank you especially to Amy for providing guidance and giving me a second chance with this project.

Here is the wiki entry.  It will be updated periodically with other resources I come across or mental notes I uncover, until such time that I can devote my full, undivided attention to it.

Catch you all on the flip side.

I suppose occasional reading of the GSoC mailing list pays off:

I had also misread the timetable as August 18 being the final deadline to submit evaluations and code.

From what i understand the evaluation period start on the 18th and ends September 1st. All code/documentation should be done by August 31st/September 1st so that your mentor gives you a positive review. And then you have a couple of days to polish things up, perhaps write a report or presentation and send a packaged finished project to google. Am i reading this correctly?

So, basically we have a month of GSoC in front of us :)

LH's response:

Exactly.

This is good to know.  I have been laboring under the impression that coding was absolutely set to end by August 18.  In fact, this is still how the calendar looks, but considering LH directly confirmed the speculation of students, I think we've heard the absolute word of truth from as high up as we can possibly get it.

Meanwhile, with Chris' assistance, I have discovered that I've kind of gotten caught between two Shindig architectures, which was creating the confusion between identical classes to override and which ones to use.  Turns out, the first was an "old 0.7 wire format", while the other is the newer RESTful API implementation.  Obviously, the latter is what I'll be using. :P  And to get things working from the data end, overriding those three classes is indeed all that is required.  Everything will work as is.

Furthermore, another special treat for developers down the road with this particular nuance: there is a great deal of custom configuring that can be done with the look and feel of gadget rendering, not to mention the ability to add entire JavaScript handlers to the scene without affecting Shindig in any way.  Gadget CSS, use of new JavaScript libraries, and unique passkeys can all be implemented on the Joomla! side and set up to communicate with Shindig in such a way that keeping up with the latest SVN release is no trouble at all.

Yes.  These are all customizable and can be tailored to Joomla!'s specific settings, all independent of the Shindig source tree but fully integratable.  New looks and feels for the gadgets based on the active J! template, new JavaScript libraries which can be as simple as DOM styling, or as complex as AJAX should the specific J! component employ any of that...yeah.  Pretty freakin' spiffy.

Another bit of implementation will be the meta-data service to aid in the retrieving and rendering of gadgets.  This is information pertaining to the gadgets themselves, like preferred size, set user preferences, and gadget caching.  But this should be pretty simply once the main part is finished.

Anywho.  It's thundering outside (gorgeous), and I am in the middle of final exams week, and if I expect to walk down the platform on Friday to receive my bachelor's degree in Computer Science, I had better put my nose to the grindstone these next few days.  Unfortunately, it's not looking like I'll have an install ready for the August 1 magazine deadline. Sorry Amy =/

Oh by the way, I was recently given an iPhone as a graduation gift, and I have to say - I like the idea of making some sort of Joomla! XML-RPC application.  What else it would do, I'm not sure...but I'm quite positive this exceptional group of GSoC-ers could come up with something, if not now then definitely for next summer. ;)

OH.  One more thing.  As of this Friday, I will no longer have access to my GT post office box, so if the Joomla! book is on its way, I'm not sure if it will be able to get where it's supposed to go.  I have my parents' home address and my new Pittsburgh address (where I'll be after August 11) on hand if anyone needs it.  And if anyone knows in general what the status of the book is, please let me know!  It'd be great to have it :)

Since my last update, I have heard back from not one, but TWO Shindig developers regarding integration.  Brad, a Shindig developer who made the mistake of telling me he was familiar with the Joomla! architecture, responded to me by way of email today, starting the ball rolling with how to go about tying an external library into the Joomla! framework.  Chris Chabot, one of the head Shindig developers and probably the lone Partuza dev, stumbled across this blog and he and I have since been in touch, the latest regarding the down-and-dirty specifics of the Shindig architecture.

Today I began the process of tracing Shindig's path of execution from beginning to end, to further familiarize myself with how it handles particular data requests.  The URL redirects I mentioned and had a screenshot of in a previous post is the single point of entry for all requests that are routed through Shindig, as summed up in the architectural overview of Shindig.  These redirects reference specific classes, which Shindig dynamically calls and loads based on the URL.

Now.  Each of these handler classes, or "servlets" in Shindig terminology, have identical first-layer handler method: namely, doPost(), doGet(), doPut(), and doDelete().  These methods are also formed and called dynamically by way of how the request reaches the Shindig server.  More technically, what the value of $_SERVER['REQUEST_METHOD'] happens to be.

Clear as mud so far?  Excellent.

Depending on the method of the request, and the URL the request accessed, this determines both the specific servlet and the particular method invoked in that servlet.  Which then allows Shindig to take over entirely from that point, taking care of the entire OpenSocial implementation on its own.

The way Partuza works its magic through Shindig (and the way Joomla! is just starting to as well...) is by overriding some default data handlers - specifically, abstract classes built intentionally to be overridden and extended - to tailor the data handling and processing to the specific web application.

Case in point, Joomla!.  Again, as mentioned in a previous post, these data handling classes are called "JoomlaAppDataService", "JoomlaPeopleService", and "JoomlaActivitiesService", overriding their respective abstract classes and implmenting the necessary functions within the Joomla! context.

Shindig takes care of everything else.  Seriously.  It's kind of ridiculous how powerful this application is.

What I am currently waiting on (and also actively investigating) is whether Joomla! can successfully survive by overriding only those three data handlers, or whether further integration will be necessary for these two apps to coexist peacefully.  I have already begun work rewriting and implementing these three abstract data handlers within the Joomla! environment.  It's pretty cool how this is working. :)

Oh, and the capstone project is proceeding pretty well.  The confrontation with my group member wasn't pleasant...but it accomplished what it needed to.  We have settled in a new direction and are poised to complete our project on time this Friday.  From them on out, it's allllll GSoC.  w00t

Annnnnd bedtime!

Howdy gentlepeoples,

I just wanted to alert everyone of a demanding situation I find myself in: my senior capstone presentation is this Friday, and one of our four group members - to whom we assigned a very critical part of our project - has spent the majority of the entire summer accomplishing squat, and with our deadline four days away we are scrambling to put his module together, quite literally from scratch.

And guess who the most experienced PHP coder in our group is? :P

I am budgeting my time and will be working on GSoC tomorrow as per usual, but I have not had a chance all weekend to make any further progress, as I and my other two teammates started work on picking up our fourth's slack.

It sucks when folks don't do the work they're assigned...but such is life.  Meanwhile, I'm still here.  With any amount of luck, I'll have an update tomorrow on my Opensocial progress. :)

Today has been one of those days.  Nothing's worked the way I've wanted it to.  My Joomla!-hacking has been noisomely unsuccessful.  My senior capstone group, designing a simple PHP-based appointment management system, was stuck on the same bug for over two hours today, and it ended up turning out to be a simple misuse of the PHP header() function (I will say nothing about a certain individual on my team who has made ZERO progress on his respectively delegated portion in the last eight weeks *cough*).  I discovered the Google Codejam competition was 21 hours into its 24-hour qualification period; needless to say, I barely solved the mathmatical side of the first problem, and the code wasn't even close.

When I came across a stunning discrepancy between step #5 of the Partuza installation process and the actual Partuza files, I was ready to chuck my CS major out the metaphorical window.

Bear with me; I didn't give up just yet.  After all, I had tootsie rolls at my disposal!

I decided to browse the rather inactive Partuza Googlegroup mailing list, and I found this particular thread with comments about the newest revision to the repository, #93, at the very bottom under "Log".

This spurred a memory of mine.  I'd seen something like this in the Shindig config file.  I went back to look at it.  I found entries with the names "BasicPeopleService", "BasicActivitiesService", and "BasicAppDataService".  Tell me if you see any similarities in those names and the names of three of these files from the Partuza repository:

(hint: BasicPeopleSerivce, BasicActivitiesService, BasicAppDataService)

Oh no, oh no...OH YEAHHH.

Swap out "Basic" for "Partuza", and you have the following Shindig config file:

There was a little voodoo magic still to do with Apache's mod_rewrite, since Partuza didn't seem to take kindly to the concept of "relative URLs."  But once that was in place, Partuza behaved beautifully.

That's not the best part, though.  This is the best part:

This is a list of URL mappings that Shindig employs behind the scenes in order to access its various features.  Partuza makes extensive use of these URLs in order to allow Shindig to do its thing.  All Partuza requires is where the PHP source of Shindig is, and the URL to the OpenSocial gadget's XML file.

See??  SEE HOW AWESOME THIS IS??

...oh right.  Um.  Replace "Partuza" with "Joomla!" in the above paragraph, and you pretty much have the roadmap I've been following for implementing Joomla! as an OpenSocial container.  Yes folks, its com_opensocial component will be communicating exclusively with three separate classes: JoomlaPeopleService, JoomlaActivitiesService, and JoomlaAppDataService.  That will handle all the data management from the earlier post I made about Shindig's three-tier architecture.

Yes, something good came out of the general debacle that was today.  Even though I may swear and pout and throw metaphorical objects through the metaphorically shattering glass of my metaphorical window...I really do love this line of work.  It's progress, even though it may not feel like it.

By the way, any word on the book? ^_^

Okbedtimebye!

I found it.  Shindig's Holy Grail.

Behold: a production implementation of Shindig.

Also: an architectural overview of Shindig.  I've been following this for weeks and have been forgetting to post the link.

Shidnig and Joomla! are beginning to talk to each other...a more detailed update to come!

Of which, there are many.

Let me break this down a little bit first.

*ahemahem*

The folks developing Shindig are, simply put, brilliant people.  They are developing a custom OpenSocial container that is specifically designed to be deployed in just about any environment; as several have told me personally through emails, integrating Shindig with Joomla! just "makes sense."  The hard part is getting the two to actively communicate.

On the Joomla! side: A component (com_opensocial) is acting as the entry point for the Shindig interface.  This component follows all the usual rules of Joomla! components: core and administrative sides, and strict MVC design.  This serves as the pluggable interface for which additional OpenSocial gadgets can be plugged in.  For those gadgets, each will consist of a module or even a plugin (I'm conducting tests right now to determine which is more feasible...suggestions are welcome).  A new external library has also be added to the mix.  Within the "libraries" folder of the Joomla! filesystem, "shindig" has been added, which contains all the library files, though the parallel Java implementation is absent, since it is inconsequential to this particular scenario.

Having the component successfully reference the library is extremely challenging.  I'm looking at how the other libraries are implemented and communicated with as hints to how I should go about jumping this hurdle.  Again, suggestions are welcome.  However, there is more that will have to happen than a simple function call or two, and that is what I have been working on of late.  On that note...

The Shindig side: Shindig is essentially three independent modules working together (for clarification: when I refer to "Shindig", I am speaking only of the PHP implementation.  The parallel Java implementation does not factor into this project).  These three modules are as follows: Gadget Rendering, OpenSocial Server Components, and Persistent Data Access.  The latter two are encapsulated within a single layer of abstraction, the Gadget Data Servlet.  The other is aptly named the Gadget Rendering Servlet.

Essentially, the folks with Shindig have employed the exact architecture Joomla! uses: Model (Data), View (Rendering), and Control (Servlets).  These three modules are independent of one another (DING DING DING).  Yes folks, one of these modules can be swapped out for another implementation of the same functionality, and the other modules wouldn't know the difference.  Nevertheless, this doesn't exactly point to a cakewalk integration process.  As an example, if I wanted to rewrite the Data portion of Shindig (which, actually, is the only module I'm 100% positive at this point that I'm NOT going to touch), I'd have to throw out six PHP classes and rewrite their functionality from scratch within the Joomla! environment.

The other two modules are just as difficult/easy.  Depending on your perspective.

The module I have been spending the most time with is the Gadget Rendering Servlet.  After all, its only job is to render the OpenSocial widgets, after all the data processing has taken place.  For all practical purposes, this is the module I have to concern myself with; everything else can remain as it is.  However, integrating it into Joomla! MVC architecture (or, making it the View) has been very difficult.

A thought I had recently was this: is there some way I can buffer Shindig's gadget rendering, and rather than actively allow Shindig to render the gadget as it would normally, forward that data directly to Joomla!?  I'm not sure if this is even possible.  Even something as simple (but agonizingly annoying) as headers being sent can throw a wrench in this hack of an idea.  Change the way Joomla! echoes HTML the browser and it could break the whole link.

This method might be useful for testing.  But in production, I'll have to continue my work of overriding the default Gadget Rendering Servlet to act as a View within the com_opensocial component.  Fortunately, Joomla! provides a plethora of existing formatting and output functions; my current problem is figuring out exactly what calls from the massive API are appropriate for rendering the gadgets.  This is where I need to sit down and have an e-discussions at some point with a core Joomla! developer and pick their brain on the topic.  I'm pretty sure a simple JText isn't going to cut it.

*pant pant* Whew!  Anyone else having a blast, or is it just me? :)

By the way...anyone know if my book is on its way? *innocent smile*

As a final note, I am departing later today (~8 hours) for a road trip up to Pittsburgh, PA, where I will be hunting for an apartment to live in over the next year (my first at graduate school!).  The upshot is that I will not be readily available on Skype from the 10th through the 13th as I usually am.  I have no idea what my internet access will be during that time.  I have more code to post, but unfortunately I am at my parents' house right now, and I kid you not when I say that hitting the "Insert/Edit Link" button on this wysiwyg editor took a grand total of 15 seconds (I counted).  SVN doesn't play nicely with intarnetz that crawl.

Have a good weekend, fellow Joomla!-ers!

Ladies and gentlemen, the PBF crew from Georgia Tech:

(Left to right: Blair, Shannon, Cathryn)

Fixed bugs and trolled #joomlapbf while munching pepperoni and banana pepper pizza from Papa John's (provided exclusively by Cathryn!).  Not only did we conquer permissions problems with the computers in the library (seen in the background on the right) and issues with Subversion and Joomlacode, but we outlasted a typhoon and tamed Blockbreakers.

Basically, we were awesome. :)

PBF2 was quite an experience this past weekend, and OpenSocial development is continuing along very nicely.  But I have hit a wall:

In order to make use of Shindig, I have to have the mcrypt module installed in my PHP configuration.  Unfortunately, the stock install on OS X, while loaded with features, does not count the mcrypt library among those.  I have been scouring the internets high and low for ways to dynamically load this module without having to recompile PHP from source, as there doesn't seem to be any way to do that with the stock installation.  I'd literally have to have two installs of PHP running on my laptop in order to have mcrypt running in one of them.

If anyone has any ideas on how to solve this dilemma, please let me know!  I am running OS X 10.5.3 with PHP 5.2.5 and Apache 2.2.8.  Any assistance would be GREATLY appreciated!

First of all, Firefox 3 is FANTASTIC. I've been using it since RC1. Go download it.

Second, the high-level project plan is this: use the remainder of this month (as I have been) to develop a working communication protocol between Joomla! and Shindig by way of a J! extension. Once the two begin communicating, the month of July can be devoted to implementing the details of Shindig to make Joomla! a true OpenSocial container.

Third (which ties in with Fourth), I have submitted two bug reports, both pertaining to the idiosyncrasies of late with this blog. I intend on addressing those bugs during PBF in the coming weekends. I have also noticed that my comment counts on the overall blog page don't seem to be reflective of the actual number of comments I have received; every post seems to say 0. If I can get confirmation of this from someone else, I'll submit a third bug report. Regarding PBF, though, I have received a message from someone here at Georgia Tech who wishes to help me establish a venue here for PBF. It looks like GT will be a host for the event after all!

Gotta get to class! More to come!