HTML Logo by World Wide Web Consortium (www.w3.org). Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS, which is now in beta. ocPortal 9 will be superseded by Composr 10.

Head over to compo.sr for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.


ocPortal thoughts

Login / Search

 [ Join | More ]
 Add topic 
Posted
Rating:
#65284 (In Topic #14020)
Avatar

Community saint

Some thoughts on where ocPortal's at and what would be nice to change

Hi everyone, not sure if this is the right part of the forum but I've been doing some thinking about cool things we, as a community, could be doing with ocPortal and have written up a blog post. Was wondering people's thoughts :)

Please keep in mind that none of my personal activity (like this) is representative of ocProducts. This is the mutterings of my own Free-Software-loving, Web-avoiding-if-there's-a-desktop-equivalent self :)
Back to the top
 
Posted
Rating:
#65287
Avatar

Thanks for that, interesting read :).

Couple of problems with your hook situation Chris.

One is memory usage. PHP is a beast when it comes to memory, and the amount of PHP code loaded up as stands on say an AED screen is about 8MB just in PHP code. If individual hooks were 'fatter' that could easily rise to '16MB', which is the whole memory limit for what some hosts have.

Second is that we're going minimalistic. In 5.1 the entire 'search' addon is going to be optional for instance. So merging hooks kind of assumes a fat core.

For example, there is infrastructure to create new configuration options. This is actually useless, however, since the configuration options are designated via hook

You're right but actually it's backwards. The hooks are there for HipHop PHP which can't do eval() so can't handle DB-situed config options. They're not used at all under normal operation. For v6 I think the DB stuff will go and the hooks will stay, it's better practice, and more stable (relies less on DB).

Some parts of HTML and its kin are a little annoying, for which various workarounds can be used. Unfortunately, ocPortal uses Flash to work around some of these, for example the limitations of file uploading (a form must be submitted (ie. a new page loaded), no progress information is given, etc.). This is unfortunate because the only viable runtime for Flash is Adobe's (formerly Macromedia's) and this isn't Free Software.

I always hoped the browser makers would see sense and fix this in the browser, but they haven't done yet. Maybe you could help us do better bad-flash-plugin detection to make it skip out swfupload? It's supposed to do that now but it's obviously not been working well on your Linux machines.

HTML5 upload (well, actually it's the related new JS API standard) should help. However unfortunately for now the browser makers can't agree on it and the only standard way is to either initiate an upload that requires an abnormal POST request that not all PHP installs can use, or to do in-JS processing of the file bytes (not good for obvious reasons). It's exactly as you said it - we sometimes have a foundation of jelly to work on!

Regarding video, we're going with the latest jwplayer in v5.1 which supports HTML5 playback with Flash fallback. Works great, uses a proper 'video' tag.

Regarding Tempcode - the problem with XML is that you can't shear across the XHTML structure and you can't put it inside or between XHTML attributes.
Tempcode certainly is ugly though. There's something on the tracker for changing the syntax (v6).

To be honest with a lot of the stuff at the end I see a lot of problems relating to hosting compatibility, implementation time, usability, and I think there'd be limited real-world utility. It's fascinating stuff though, I suspect there are some gems to be polished in all that. Webdav is a big good thing I think because it can help themeing (acting as a meta-layer that can do magic) and improve ease of use (so people don't need to piddle around with a web interface). To me that is the kind of strong use case that justifies a feature - something like XMPP discovery, I just don't think many people would benefit from it at the end of the day. Git is a very interesting one, but it's again quite hard to imagine many people actually using it, even many programmers (and again I worry about hosting compatibility).


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#65290
Avatar

Community saint

Chris Graham said

One is memory usage. PHP is a beast when it comes to memory, and the amount of PHP code loaded up as stands on say an AED screen is about 8MB just in PHP code. If individual hooks were 'fatter' that could easily rise to '16MB', which is the whole memory limit for what some hosts have.

Yeah I thought that might be a problem. I did mention that the objects could be proxies, loading their methods if they happen to get invoked, but TBH I don't know if that would be easy to do in PHP. If it were Python I'd do it as something like:

Code

class ProxyObject:
    def __get__(method_name):
        """This handles requests for this object's members (methods, variables, properties)
        # Load the code we need here, ie. only when it's asked for
        require_code('hooks/' + self.type + '/' + method_name)  # Where "self.type" is "galleries", "downloads", etc.

        # Use current instantiation stuff here
        # ...

        return hook.run  # Give back the newly loaded function
I don't know if that kind of dynamism is possible in PHP without resorting to eval, and redefining method lookup probably wouldn't work in HipHop, but the idea is that we shift the "for each hook run 'require_code' and 'object_factory' with the right directory paths" into its own function, but rather than simply hiding it in something like "require_hook", we can be a little smarter and provide objects which hide the per-subsystem division of the hooks. Thinking about it a bit more, I think that defining any of these objects explicitly, like "galleries", "downloads", etc., even if it's via hooks, should be avoided, and instead we can work it out implicitly from the filenames alone; so 'hooks/systems/search/galleries.php' will mean that there's a 'galleries' object available with a 'search' method (which will only be defined when it's used), if another system, say 'config', has a hook called 'galleries.php' then they'll both be available as methods in the same 'galleries' object (instantiated when needed). Other than these methods, the objects would be empty. They wouldn't have any state other than their type, and they can be generated and garbage collected over and over (eg. no need to make them singletons or anything, as they are only a way to organise code, not for transferring values around). Anyway, that's some clarification but as I say I don't know if this would be easy in PHP (I've not had to delve into the object model much yet).

Chris Graham said

The hooks are there for HipHop PHP which can't do eval() so can't handle DB-situed config options. They're not used at all under normal operation.

Ah, well this specific example was a bit of a guess. I happened across it the other day, as I'm making a Flattr addon but its initialisation does things like:

Code

require_code('database_action');
add_config_option('FLATTR_ID','flattr_id','string','return \'\';','FEATURE','SOCIAL_NETWORKING_INTEGRATION');
But these options aren't appearing in the config screen. I then found the config hooks and assumed that add_config_option was deprecated. I also remember getting a little confused over this when coding the workflows. Maybe this is just a case of unclear naming/commenting rather than having deprecated code lying around.

Chris Graham said

Regarding video, we're going with the latest jwplayer in v5.1 which supports HTML5 playback with Flash fallback. Works great, uses a proper 'video' tag.
OK that's actually pretty cool :) I suppose abstraction like this is the best way to go when none of the options is clearly better in all cases.

Chris Graham said

Regarding Tempcode - the problem with XML is that you can't shear across the XHTML structure and you can't put it inside or between XHTML attributes.
Tempcode certainly is ugly though. There's something on the tracker for changing the syntax (v6).
I think my biggest concern is slight nuances in syntax (like $, +, {foo} vs. foo, etc.). Other than that I was throwing out ideas (I gave up turning it from bullet points to prose towards the end ;) ). I mentioned s-expressions since that's what Tempcode looks like at the moment, except for the slight nuances I just mentioned.

As for the rather niche ideas, I know they're not killer features but I may try to make addons for them anyway. There are a lot of projects which are defining protocols, then trying to cobble together working sites based on them, for example GNU Social (an example installation of which is at daisycha.in), however the hard part is building a decent tool; the protocol's pretty easy in comparison. ocPortal already makes great sites, which solves the hard problem, so I think having a few more protocols spread around would allow these ideas to be realised much sooner (albeit via a Not Invented Here solution). Plus I've got a soft spot for XMPP since I made a library for its Publish/Subscribe mechanism a couple of years ago (although the standard's changed slightly now  :|  )
Back to the top
 
Posted
Rating:
#65293
Avatar

But these options aren't appearing in the config screen. I then found the config hooks and assumed that add_config_option was deprecated. I also remember getting a little confused over this when coding the workflows. Maybe this is just a case of unclear naming/commenting rather than having deprecated code lying around.

My stab at what's happening would be missing language strings somewhere. ocPortal will skip over that situation rather than showing an error as it's quite easy for rogue entries to get left around in the config table.

As for the rather niche ideas, I know they're not killer features but I may try to make addons for them anyway. There are a lot of projects which are defining protocols, then trying to cobble together working sites based on them, for example GNU Social (an example installation of which is at daisycha.in), however the hard part is building a decent tool; the protocol's pretty easy in comparison. ocPortal already makes great sites, which solves the hard problem, so I think having a few more protocols spread around would allow these ideas to be realised much sooner (albeit via a Not Invented Here solution). Plus I've got a soft spot for XMPP since I made a library for its Publish/Subscribe mechanism a couple of years ago (although the standard's changed slightly now    )

Awesome :).


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
1 guests and 0 members have just viewed this: None
Control functions:

Quick reply   Contract

Your name:
Your message: