March 14, 2010

Recent Additions

Some small additions recently, so let’s get to it:

Twitter

Twitter sign-in is active, although we are still keeping this on the low. Today, a Twitter bridge was enabled which allows existing users to connect their twitter accounts and send ActionStatus updates (or any update) to their twitter account. Reachable on the dashboard.

Lime

Lime derivation from the Melative core is still currently under heavy development. Just as the derivation of the entire Nuclear api kit came out of Melative for open-sourcing, so will LightMeta. This is one project offshoot we have high hopes for, as it has proven very useful in creating an open, categorized/typified library based on media-types, but that’s not to say it is restricted to any typing specifics, and that’s the kind of light organization that makes it useful.

Kronblr

Kronblr, the federated micropublishing platform, hit version 0.1 early in the year, and we are still looking to push to 0.2, which will include some square revisions. Integration of Kronblr with Melative is presently stalled, as we look for options on structuring the ActionStatus format.

ActionStatus

ActionStatus is what we’ll be calling the format birthed from Melative action-updates, or textual scrobblings. ActionStatus has similarities to the increasingly popular ActivityStreams specification, and we want to make it as easy as possible to transform ActionStatus updates into ActivityStreams format.

Some might question why we don’t use the ActivityStreams spec and end there, and the answer is that ActivityStreams has limitations in comparison to ActionStatus. ActionStatus, for one, has no verb limitations and a format which fits better with Lime entities and attributes. Secondly, ActivityStreams is an Atom extension, and we do not use Atom as a native API format. Having a similar but slightly less specific format offers the advantage of maintaining native API structure with simple conversion to Atom when necessary.

Nuclear

Last but not least, Nuclear deserves a mention as it is largely what makes it easy to hack on Melative. Nuclear has seen good changes since Autumn 2009, many of which have enabled it an abstract federated core. This means that Nuclear can store users and social relations between users, regardless of domain. This high-level relation-building is something we believe is crucial for the future of Melative and web applications in general. Regardless of the success in our specification, we feel comfortable opening up to other simple, high-level relation protocols should they grow into feasible solutions.

Nuclear is a fun project to work on, and we have our eyes set on natively integrating some rising protocols such as WebFinger, XRD, RSD, Salmon, and more as the come.

That seems about it for now.

August 7, 2009

Recent Profile Changes

Today we added a couple new preferences to user profiles, timezone and language. There is currently no use for these, but the likely uses are as follows.

Language

Languages are internally defined using ISO-639 and this originally applied to the title names. Eventually, there will linkage between a user’s language preference and the primary titles that appear on various pages (except on another user’s Experience Library).

A second usage of the ISO languages will be in variations (pages), which we will be able to select the proper page based on language preference. This is nothing new/special and it might be wise to route entire subdomains to various language versions of the site (similar to Wikipedia). It’s still undecided, but the page data will be portable.

Timezone

There are only a few areas which allow custom timestamping, but timezone selection will aid in adjusting properly to UTC. Currently, user-timestamped entries are expected to be adjusted to UTC (or rather, the system does not compensate if the ts is not UTC). This preference is more of a helper function, rather than a feature, and simply adds a bit of transparency to user location.

Notes

Custom timestamping is currently available through Microupdates and setting Experience. All other events should be timestamped to UTC.

July 23, 2009

Late July Addendum

Items on the waiting list.

  1. New front page layout and information
  2. Creator/Character pages (via search and relation)
  3. remove.association API method
  4. Stream extension bugs (0.1.4.8)
  5. User statistics on /timeline
  6. Insert tracking (partially the additions API method)
  7. Variation data/field sizing (which titles are most complete)
  8. Cron jobs to remove invalid @replies
  9. Apply new stream parsing class
  10. Reflections view (similar to associations)
  11. Stream item editing (context, timestamp, message)

Various involvement level, but I’m terrible at judging what to do first versus what will accomplish the largest gain. So let’s see if we can be vocal. Some of the more important issues are items 1, 4, 7, and 8, because they affect currently operating methods (although a front page is needed for aesthetics… important, but I’m terribly inefficient. New items would be 11, 9, 5, 3, and 2. These tend to take the longest time because they lack API methods and the interface (having a method makes things quicker). So what’s left? Items 6 and 10, both which have existing methods, but need interfaces.

Now let’s take a look at the important ones, in terms of time-consumption (I’m sitting here wasting time writing this.. lol).

  • Front page: This will take a while given that styling is not my forte in any situation (even if my life was on the line).
  • Extension: I actually enjoy this, and though development goes very quick, there is a tendency to over-progress for the good of time. Still, these are quick fixes.
  • Data completion rating: This would be 1-2 days for the proper db scheming, but it only requires GET methods. Given this would be useful for editors, I’m sure they could work with a very basic XSL overlay (hopefully).
  • Removing phantom @: Right, this would be rather quick, since it is all in the DB and there is no need to have proper classes etc to perform maintenance (nothing would get finish otherwise).

Taking care of @replies, the extension, and the front page seem to be the most immanent and reasonable on time.

Updated 2009 Aug 28: crossed items which have been taken care of.

March 13, 2009

Joining the Stream

melative stream

I’ll make this short. This past week has been relatively good for development on melative, but it will be calming down in the next few weeks as I resume the semester and will be pressed. Of the current, a few important methods have been implemented on the nuclear API, and a xul application has been created for standalone, simple interface to some of the API, media content, and the friend stream. Things are still lacking, but I’m hoping to find individuals who are interested in testing and advocating the development and advancements of melative (non-webui).

The xul application can be downloaded here. For Windows and OSX users, Firefox 3 should be able to run the unzipped application.ini, for linux users use xulrunner. More information on running xul can be found here.

Please feel free to contact me via email (ryan at melative), twitter (@melative) or drop a message in the irc.

March 6, 2009

Nuclear API @ melative

Migrating the core of melative to the nuclear platform has been no simple task, but rather than waiting until a full conversion is complete (which could take months), I’ve decided to let the nuclear side of things interface with the database.

This is possible mostly because the conversion to nuclear has little to do with database schema changes (though nuclear does require some framework-specific tables for user management and social methods). That stated, the most crucial change has been the user management portion, which is entirely modularized per-nuclear. Users who are currently registered under the old system still exist, but due to hashing changes, passwords will need resetting under the dev-api domain [while logins should still work on the www].

Read the rest of this entry »

« Older Entries