Requiring JSON
Michael C. Harris
the json extension isn't installed. It is by default, but people do
some wacky things.
Requiring JSON is just a matter of adding 'json' =>
'http://php.net/json' to $required_extensions in the installhandler.
Are there arguments against requiring it?
--
Michael C. Harris, School of CS&IT, RMIT University
http://twofishcreative.com/michael/blog
Scott Merrill
<michael...@gmail.com> wrote:
>
> As per #327, the media silos (and admin ajax in general) don't work if
> the json extension isn't installed. It is by default, but people do
> some wacky things.
>
> Requiring JSON is just a matter of adding 'json' =>
> 'http://php.net/json' to $required_extensions in the installhandler.
>
> Are there arguments against requiring it?
If we want the admin interface to degrade graceful for non-JS capable
browsers, then I don't think we should require JSON.
Cheers,
Scott
Michael C. Harris
Do we want that? I don't think we state that anywhere?
How will silos work if we don't have JS? There are also a number of
pages in admin (tags, for example) that as they currently stand cannot
degrade. Should our ultimate goal be complete degradability, given our
cutting edge technology underpinnings? We are talking about the admin,
so mandating a JS browser doesn't seem very different from mandating
PHP 5.2.
Michael Heilemann
> If we want the admin interface to degrade graceful for non-JS capableDo we want that? I don't think we state that anywhere?
> browsers, then I don't think we should require JSON.
--
Michael Heilemann
http://binarybonsai.com
Arthus Erea
On Jun 11, 7:30 am, "Scott Merrill" <ski...@skippy.net> wrote:
> If we want the admin interface to degrade graceful for non-JS capable
> browsers, then I don't think we should require JSON.
about, it's the server. We already have high standards for the server
so I think it is reasonable to require another required extension. The
only reason we wouldn't do so is if we decided to abandon AJAX
entirely (which isn't happening anytime soon).
Sean T Evans
Hash: SHA1
Michael C. Harris wrote:
> How will silos work if we don't have JS? There are also a number of
> pages in admin (tags, for example) that as they currently stand cannot
> degrade. Should our ultimate goal be complete degradability, given our
> cutting edge technology underpinnings? We are talking about the admin,
> so mandating a JS browser doesn't seem very different from mandating
> PHP 5.2.
>
Our cutting-edge underpinnings are for our hosting requirements, as a
self-hosted option requires a level of knowledge that I think is
compatible with requiring cutting edge installations on the host. The
user can confirm what the host provide when they install. However the
user cannot always control what browser will be used to access the
admin. Mobile browsers, corporate environments, internet cafes... any of
those could be used by even an advanced user, and not have JS
functional. We need to keep that in mind.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIT8lnmQpMBUWJpdsRAtPfAJ9AMWsxgf+aUmAcznNrwHUKtjCV6gCgl3qX
5e09Cz+6XHFB5BZkoXGiqOE=
=mjm2
-----END PGP SIGNATURE-----
Jay Pipes
Scott Merrill
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael C. Harris wrote:
>> How will silos work if we don't have JS? There are also a number of
>> pages in admin (tags, for example) that as they currently stand cannot
>> degrade. Should our ultimate goal be complete degradability, given our
>> cutting edge technology underpinnings? We are talking about the admin,
>> so mandating a JS browser doesn't seem very different from mandating
>> PHP 5.2.
>>
>
> Our cutting-edge underpinnings are for our hosting requirements, as a
> self-hosted option requires a level of knowledge that I think is
> compatible with requiring cutting edge installations on the host. The
> user can confirm what the host provide when they install. However the
> user cannot always control what browser will be used to access the
> admin. Mobile browsers, corporate environments, internet cafes... any of
> those could be used by even an advanced user, and not have JS
> functional. We need to keep that in mind.
I suppose requiring JSON isn't a big deal: chances are most users will
use a fully capable desktop browser at least for installation and
primary use of their site.
But as Sean points out, I would like to be able to perform _most_
admin functions from the Blazer browser on my Palm Centro. I don't
expect I'll need to visit the /admin/tags page, but I'd like to post
and manage content, as well as moderate comments.
Cheers,
Scott
Matt Read
> But as Sean points out, I would like to be able to perform _most_
> admin functions from the Blazer browser on my Palm Centro. I don't
> expect I'll need to visit the /admin/tags page, but I'd like to post
> and manage content, as well as moderate comments.
Maybe this would be a opportunity for a "Mobile-WG", to create an
alternate non-JS based interface. As an example, GMail has an
alternate html only interface for unsupported browsers, which allows
you to do most of the admin tasks, without the funky ajaxy stuff. I
see no prob with providing such an interface for Mobile, non-JS
browsers.
Michael C. Harris
> On Wed, Jun 11, 2008 at 14:30, Michael C. Harris wrote:
>
> > > If we want the admin interface to degrade graceful for non-JS
> > > capable browsers, then I don't think we should require JSON.
> >
> > Do we want that? I don't think we state that anywhere?
>
> We've talked about it before, and no one has ever had a problem with
> requiring JS before, so...
We might have talked about it but I don't think we've documented it.
Arthus Erea
side: graceful degradation or alternate interface for clients without
JS is separate from the server. The only reason we wouldn't require
JSON (the PHP module) is if we decided to not use AJAX for *any*
clients. I don't think any of us want to do that, and we already have
some very strict requirements for the server so I wouldn't see the
harm in adding 1 more.
Michael C. Harris
>
> On Jun 11, 7:30 am, "Scott Merrill" <ski...@skippy.net> wrote:
> > If we want the admin interface to degrade graceful for non-JS capable
> > browsers, then I don't think we should require JSON.
>
> It's important to recognize this is not the client-side we're talking
> about, it's the server.
Granted there is more in the client-side discussion than just JSON.
However, in the case of JSON, server-side and client-side can't really
be separated. We use JSON to communicate with the client, and that
client must be JS enabled.
> We already have high standards for the server so I think it is
> reasonable to require another required extension. The only reason we
> wouldn't do so is if we decided to abandon AJAX entirely (which
> isn't happening anytime soon).
There seems to be a consensus that access to most of the admin should
be possible without JS, at least for mobile devices.
I propose we include the JSON extension as a requirement.
Additionally, we state that we will make every effort to have as much
of the admin as possible degrade gracefully (we can do a lot better
with the tags page, for example), but state that a JS-enabled browser
is a requirement for the default admin.
Moving slightly OT, using the word 'default' though implies other
possible admins. The obvious 'other' is a mobile admin, which seems to
me to be essential, and I think the mobile WG to work through those
issues is an excellent idea. But how far do we want that to go? Would
it be harmful to offer a very simple JS-free admin as well?
Arthus Erea
On Jun 11, 7:53 pm, "Michael C. Harris" <michael.twof...@gmail.com>
wrote:
> However, in the case of JSON, server-side and client-side can't really
> be separated. We use JSON to communicate with the client, and that
> client must be JS enabled.
can use JSON. However, if some clients have JS and some don't we can
always have some request JSON and some not, but the server must still
be able to send JSON for the clients that want it.
> There seems to be a consensus that access to most of the admin should
> be possible without JS, at least for mobile devices.
admin should be possible without JS or CSS.
> I propose we include the JSON extension as a requirement.
> Additionally, we state that we will make every effort to have as much
> of the admin as possible degrade gracefully (we can do a lot better
> with the tags page, for example), but state that a JS-enabled browser
> is a requirement for the default admin.
gracefully. Perhaps a compatibility working group should be formed,
with intention of working on degrading gracefully *and* making sure
the admin is compatible with browsers we select. (The WG would be
responsible for setting those standards.)
> Moving slightly OT, using the word 'default' though implies other
> possible admins. The obvious 'other' is a mobile admin, which seems to
> me to be essential, and I think the mobile WG to work through those
> issues is an excellent idea. But how far do we want that to go? Would
> it be harmful to offer a very simple JS-free admin as well?
firmly believe there shouldn't be a "JS-free" admin. Instead, we would
focus upon making sure everything still works in the default admin,
even without JS enabled. This would be for computers without JS
enabled. Thus, it would fall under the jurisdiction of the
compatibility WG.
A mobile admin is another issue, which I think deserves its own WG.
Fundamentally, the mobile experience should be different than that of
the default admin: when on our phones, we have very different purposes
from when on computers and the admin should reflect that.
OT, an idea was floated for an iPhone native app. I don't believe we
need this, since someone will probably develop a generic blogging app
which can hook into our APIs (and many other platforms'). If nobody
else ends up doing so, a WG could push it. Making an iPhone app would
generate good buzz for Habari.
Michael C. Harris
>
> On Jun 11, 7:53 pm, "Michael C. Harris" wrote:
> > Granted there is more in the client-side discussion than just JSON.
> > However, in the case of JSON, server-side and client-side can't really
> > be separated. We use JSON to communicate with the client, and that
> > client must be JS enabled.
>
> Not necessarily. If there's no JSON on the server-side, *no* clients
> can use JSON. However, if some clients have JS and some don't we can
> always have some request JSON and some not, but the server must still
> be able to send JSON for the clients that want it.
_requiring_ JSON or not. Should I not be able to install Habari if I
know that I will always be using the JS-free mobile admin?
> > There seems to be a consensus that access to most of the admin should
> > be possible without JS, at least for mobile devices.
>
> I agree with this, and would go so far as to say most (all) of the
> admin should be possible without JS or CSS.
>
> > I propose we include the JSON extension as a requirement.
> > Additionally, we state that we will make every effort to have as much
> > of the admin as possible degrade gracefully (we can do a lot better
> > with the tags page, for example), but state that a JS-enabled browser
> > is a requirement for the default admin.
>
> I support this, especially if we include a focus upon degrading
> gracefully. Perhaps a compatibility working group should be formed,
> with intention of working on degrading gracefully *and* making sure
> the admin is compatible with browsers we select. (The WG would be
> responsible for setting those standards.)
Looks like we're taking on the WG idea in a big way :)
> > Moving slightly OT, using the word 'default' though implies other
> > possible admins. The obvious 'other' is a mobile admin, which seems to
> > me to be essential, and I think the mobile WG to work through those
> > issues is an excellent idea. But how far do we want that to go? Would
> > it be harmful to offer a very simple JS-free admin as well?
>
> I think there are two issues here: mobile admin and JS-free admin. I
> firmly believe there shouldn't be a "JS-free" admin. Instead, we would
> focus upon making sure everything still works in the default admin,
> even without JS enabled. This would be for computers without JS
> enabled. Thus, it would fall under the jurisdiction of the
> compatibility WG.
Looks like I wasn't clear, but I was really talking about how we
manage any kind of alternate admin. JS-free was just an example. But
maybe the need is imaginary and we can just have one fully-degradable
admin (and maybe a separate lightweight mobile-focussed one).
Owen Winkler
>
> I support this, especially if we include a focus upon degrading
> gracefully.
I'll just state right up front, as unpopular as it might be to say, that
it will be a long time before I support graceful degradation in Habari.
For the core admin (and that's all I'm talking about) for now we
should require javascript.
This is not saying that I think we should exclude UA-specific admin
themes or work to eventually make the admin functional without
javascript. I just mean to say that we should base our core on an
A-grade user experience, not add js to a B-grade experience.
People should say that the admin works but sucks without the javascript,
not that it works without the javascript and, oh by the way, it has some
things in it that look neat when javascript is enabled. I think we're
fairly clearly in that territory with the timeline already.
Owen
Michael Heilemann
We _will_ get a mobile non-JS admin. But it would be ludicrous to expect the current admin to degrade gracefully to the level where a basic phone is capable of using it. It wouldn't be practical in any way, shape or form. It's obviously a separate project, and I personally think it's something that can wait at least until well after .5, if not .6 and .7 :) -- But that's me.
Which reminds me: We need better roadmaps. The .5 roadmap is about as vague as can possibly be.
As for other admin themes, what would be good though, is if someone with some insight can elaborate on how easy it will be to create a 'theme' for phones or for the iPhone or PSP or whatever might be interesting. Is it as simple as doing a plugin or what? What's the structure and process for it?
- Mike
Michael C. Harris
> Which reminds me: We need better roadmaps. The .5 roadmap is about as
> vague as can possibly be.
Vague in what way? An ACL system and podcast support. We probably
should have included an admin upgrade. Those are the goals for 0.5,
if we have them, it's time for 0.5.
We had much more in the roadmap for a while - now _that_ was vague.
Michael Heilemann
Vague in what way? An ACL system and podcast support. We probably
should have included an admin upgrade. Those are the goals for 0.5,
if we have them, it's time for 0.5.
Well, vague in the way that it doesn't specify what 'podcast support' contains. Is it as simple as detecting any links to .mp3/.mp4 files and making the feed work with that, or does it also mean a UI for handling time, author and rating data (and so on).
This information AFAIK exists only in the ephemeral space between the people who have talked about it (or you could try the wiki: http://wiki.habariproject.org/en/Special:Search?search=podcast), and so it's impossible for anyone to help implement this stuff, when that information isn't available. I don't even know where to look for any code might already exist...
Before I did Monolith, I got banged around a lot for the way I wanted to do the admin 'on my own', and someone, I forget who, told me that I should consider the fact that some people actually write documentation for their apps/features before implementing them. That way you know the path, you simply have to walk it.
And so I did that for Monolith, to the extend that it made sense and I had time. And it worked. And I suggest we do the same for roadmap features.
Chris Meller
And if you don't have a JavaScript-enabled browser, you are weak and deserve to be Habari-less.
Jay Pipes
Arthus Erea
On Jun 11, 9:16 pm, Owen Winkler <epit...@gmail.com> wrote:
> I'll just state right up front, as unpopular as it might be to say, that
> it will be a long time before I support graceful degradation in Habari.
> For the core admin (and that's all I'm talking about) for now we
> should require javascript.
Degrading need not be that way at all..
For the most part, I think it is fine for us to ignore the graceful
degradation when designing the admin: explore ideas, make the best
admin possible.
The degrading support can be added later. There is absolutely no
reason that the JS-enabled version should suffer due to the support
for no-JS.
jaypipes
http://wiki.habariproject.org/en/Installation
It's listed under required modules for PHP
Cheers,
Jay
On Jun 11, 7:36 pm, "Michael C. Harris" <michael.twof...@gmail.com>
Michael C. Harris
> On Thu, Jun 12, 2008 at 09:55, Michael C. Harris wrote:
>
> > Vague in what way? An ACL system and podcast support. We probably
> > should have included an admin upgrade. Those are the goals for 0.5,
> > if we have them, it's time for 0.5.
>
> Well, vague in the way that it doesn't specify what 'podcast support'
> contains. Is it as simple as detecting any links to .mp3/.mp4 files and
> making the feed work with that, or does it also mean a UI for handling
> time, author and rating data (and so on).
> This information AFAIK exists only in the ephemeral space between the
> people who have talked about it (or you could try the wiki:
> so it's impossible for anyone to help implement this stuff, when that
> information isn't available. I don't even know where to look for any
> code might already exist...
I'm not saying that our roadmaps can't be improved, but they're not
the place for these sorts of things. The specifics are in trac as
tickets. If someone wants to help with podcasting, asking here or on
IRC how to get involved will get you pointed to the appropriate places
(for example, ticket #9, the podcast and RSS plugins, FormUI for
adding enclosure data etc).
> Before I did Monolith, I got banged around a lot for the way I wanted
> to do the admin 'on my own', and someone, I forget who, told me that I
> should consider the fact that some people actually write documentation
> for their apps/features before implementing them. That way you know the
> path, you simply have to walk it.
> And so I did that for Monolith, to the extend that it made sense and I
> had time. And it worked. And I suggest we do the same for roadmap
> features.
But no-one asked you to put Monolith documentation in a roadmap.
Michael C. Harris
> On Jun 11, 7:36 pm, "Michael C. Harris" wrote:
> > On Wed, Jun 11, 2008 at 02:32:01PM +0200, Michael Heilemann wrote:
> > > On Wed, Jun 11, 2008 at 14:30, Michael C. Harris wrote:
> > > We've talked about it before, and no one has ever had a problem with
> > > requiring JS before, so...
> >
> > We might have talked about it but I don't think we've documented it.
>
>
> http://wiki.habariproject.org/en/Installation
>
> It's listed under required modules for PHP
Good catch ... but at this point we were talking about client side :)
Michael Bishop
On Jun 12, 4:50 am, "Michael Heilemann" <heilem...@gmail.com> wrote:
> On Thu, Jun 12, 2008 at 09:55, Michael C. Harris <michael.twof...@gmail.com>
fashion, is not the on the same level of change as a complete UI
overhaul to admin, and isn't something being done by someone who asks
to formulate it outside the previously accepted manner of "by
committee".
As far as it not being in the wiki, that certainly could be improved,
however I don't know that we've ever explicitly said the wiki is where
that information should reside. As as I understand it, this mailing
list is for those discussions, and publicly archived for future
reference. I know I've seen at least one recent discussion about what
podcasting support might mean initially (http://pastoid.com/v8+).
Anyway, to the more germane question about JS and degradation, can,
for the love of all that is holy, development be focused on getting
the JS fully working on all of the pages before tackling that step.
If that means being able to release a .5, fine.
Whether it was a conscious community decision to use this much JS in
admin, is, at this point, moot. Too much hard work has gone into it
to turn back, there _was_ a general consensus to adopt monolith, which
obviously relied on JS to accomplish the new features, so if nothing
else, it was an unspoken acceptance, and can be dealt with in the next
round of development.
At least that's my 2¢.
~milkb
Michael C. Harris
never posted to -dev.
Michael Heilemann
/me wishes he'd just added the one line of code to require json and
never posted to -dev.