where is SimpleDesk Desk Team?

Started by cristianlf, July 12, 2013, 10:10:42 PM

Previous topic - Next topic

cristianlf

Hello SD Team!!!!

I Hope you can get together and bring us a even better version of SD Im reaaalyy love this product ...

well if you know something let us now ...

regards.

venguard223

#1
What would be in it? What new features?

Github shows development is basically dead and has been since I left in 2011, with just bug fixes and some SMF 2.1 compatibility code since then.

ETA: Sadly I have neither the time nor motivation to pick it up, too much other stuff going on for that to happen now :(

SleePy

Basically echo what Venguard2223 said.  I haven't had time or interest in developing this further.  I actually wanted to develop it out of a mod really and more into a standalone package simply requiring SSI.php to get going and then a integration package.  Reducing the amount of dependencies if possible.
Jeremy D — Spare-Developer

tfs

I sure wish that development would continue.  I'd donate money and time gladly.  I rely on SD every single day, but I could use some fixes and tweaks.
A good tree cannot bring forth evil fruit, neither can an evil tree bring forth good fruit.

venguard223

@SleePy: the problem with reducing dependencies is that you lose the one thing we wanted to keep in it originally - the theme system. The whole underpinning was that it wasn't just tying it to SMF to make it an SMF add-on but to reuse SMF as much as possible, so that you get all the benefits of using SMF with few of the drawbacks.

It'd be far nicer to do that than to have a separate system that just gets lightly integrated (which amounts to more overhead and more maintenance in the long run)

@tfs: Fixes probably aren't a huge deal if they're legitimate bugs. Shoot me a message on Wedge and I'll take a look when I'm able (I won't be back in front of my proper laptop until the start of August so after that shoot me a message and I'll see what I can do), while tweaks on the other hand are a different kettle of fish. I don't have time to do big enhancements but if they're the sort of thing I can crank out in a day or so I'm happy to get that sorted for you.

SleePy

venguard223,

Understandable, I just see no reason it can't rely on SSI and still pull the theme system and others.  The major thing I want to break out is the integration into SMF's main code (ie for topics and menu stuff).  I suspect with improvements in 2.1 having better hooks, we can do this.  Making it less of a mod and more of a Add-on that relies on SMF's SSI to do its stuff seems to be the best option for future.  It makes it work easier, easier to develop and makes it so a simple mod that adds the hooks is all that is needed to bring in the integration for menus, unread replies and topics.

tfs,
Is there any such bugs which need addressed?  Trying to get back into SMF stuff, I should try to spend time with SD and get working with it again.
Jeremy D — Spare-Developer

venguard223

Bugs - see http://www.simpledesk.net/community/index.php?topic=1315.0 and http://www.simpledesk.net/community/index.php?topic=1316.0

As far as SSI integration goes, yes, you could rewrite most of the guts to hang off hooks. Have fun rewriting the attachments system though I guess just cloning action=dlattach would be easier.

Thing is... the actual changes to SMF itself are surprisingly light, I already converted much of it to hooks the first time around. The real pains in the posterior to change, though, are the board index (since that's fugly as sin), attachments (while you can hive a lot of it off to its own action handler for serving attachments, the changes to the backend are a bit of a different beast), track IP integration (unless there's a hook).

There are no real integration points with topics, and IIRC the menu is driven by a hook anyway (though disabled mostly in SSI mode for performance again IIRC)

The other thing is if you make it powered by SSI rather than the action handler, you're going to have SO much fun rewriting everything to not be referencing the action handler. Everything was pulled under action=helpdesk for a reason ;)

The other other thing with going the SSI route is that standalone mode mostly becomes pointless and/or bordering on impossible to implement sanely. I'm still not impressed, by the way, that the SA KB mod 'borrowed' large chunks of that code without a credit even if SD was BSD and allowed them to reuse the code.

tfs

Quote from: SleePy on August 14, 2013, 12:47:20 AM
tfs,
Is there any such bugs which need addressed?  Trying to get back into SMF stuff, I should try to spend time with SD and get working with it again.

I'd be willing to install any number of test forums for you and I to work with.  I'll perform beta testing for you to your heart's delight.  :)

I use SimpleDesk daily in my real-world job.  I've probably worked through a thousand tickets since we started using it.  But as far as bugs go, I just don't have a good idea of what they are right now (besides the two Arantor linked).  Once the code went to GitHub I threw up my hands in frustration.  :)
A good tree cannot bring forth evil fruit, neither can an evil tree bring forth good fruit.

venguard223

You and me both as far as Github is concerned... I know that there is some stuff in there for SMF 2.1 compatibility but I have no idea what the state of it is any more :(

Oh, I just realised something else; if SD were pushed into an SSI only context, might as well remove the plugin manager and edits to the language editor since neither will work properly in that situation, especially the plugin manager.

SleePy

Quote from: tfs on August 14, 2013, 09:38:21 PM
Quote from: SleePy on August 14, 2013, 12:47:20 AM
tfs,
Is there any such bugs which need addressed?  Trying to get back into SMF stuff, I should try to spend time with SD and get working with it again.

I'd be willing to install any number of test forums for you and I to work with.  I'll perform beta testing for you to your heart's delight.  :)

I use SimpleDesk daily in my real-world job.  I've probably worked through a thousand tickets since we started using it.  But as far as bugs go, I just don't have a good idea of what they are right now (besides the two Arantor linked).  Once the code went to GitHub I threw up my hands in frustration.  :)

I apologize that Git seems a bit confusing.  Moving to Github was a choice that was supposed to help bring exposure to our project and allow contributions.  Alas that hasn't really happened (although we did get help with SMF 2.1 compatibility).  Perhaps I can work on a way to bring more exposure to you guys when Git is updated.  Would a topic that gets a new reply every time we get a commit help out?  I think Wedge does that (or they do a lot of manual posting :P).  It would help bring that to light, and I should be able to include a download link as well.

Quote from: venguard223 on August 14, 2013, 10:24:57 PM
You and me both as far as Github is concerned... I know that there is some stuff in there for SMF 2.1 compatibility but I have no idea what the state of it is any more :(
2.1 Compatibility and that has been all really.  We need devs to work on it, but thats a challenge.  Big mods can be a challenge to work with.  Especially in a developer environment.  For me personally, I have SMF setup to where I can work between PHP 5.3 or PHP 5.5 and change my git branch around to whatever I want.  I did think about getting my databases going again, but haven't.  On my laptop I used to run 2 web servers (Apache and nginx), 3 versions of PHP (5.1, 5.2 and trunk (or 5.3 at that time), 3 database (MySQL, Postgresql and SQlite), and had a magic script that got appended that added easy upgrade handling, killing of sessions, changing themes, and switching between all the different softwares.
When I tried working with SimpleDesk, it wasn't as easy because of mostly my lack of SimpleDesk knowledge and that SimpleDesk required me to test mod installs every time I made a change to the package installer (I figured I could get away with modifying the none package edits/installer script).

Quote from: venguard223 on August 14, 2013, 10:24:57 PM
Oh, I just realised something else; if SD were pushed into an SSI only context, might as well remove the plugin manager and edits to the language editor since neither will work properly in that situation, especially the plugin manager.
It was just a thought.  I toy with many ideas in my head.  Some of them are great, others are not.  I was toying with it to think how it would go.  My thoughts on it mostly would be that it would make it much easier to work with since we got a almost standalone install.  I think plugin manager would still be doable.  Its not like plugin manager can't still scan the packages directory or do the LE.  Its not like those couldn't link to the SMF stuff.  My thoughts where you would be able to decompress it into a directory, run the installer which would setup a settings file with the link to SMF SSI.php, and a few other basic settings and off you go.

I've also toyed with the idea of seeing what we could do to start a abstraction layer, so SMF isn't the only source it will work on but other forks such as Wedge could use SimpleDesk.  Mostly so we are not limiting people to using SMF only if they want a helpdesk.  It would make sure that SimpleDesk can communicate with other forks as long as the API is there.  Again, idea in my head, but not anywhere near paper yet.
Jeremy D — Spare-Developer

venguard223

QuoteI think Wedge does that (or they do a lot of manual posting

Manual posting, baby!

QuoteIt was just a thought.  I toy with many ideas in my head.  Some of them are great, others are not.

Yeah, I know that feeling only too well.

QuoteMy thoughts on it mostly would be that it would make it much easier to work with since we got a almost standalone install.

The problem with it is that you end up having to reduplicate a ton of stuff. For example you'd pretty much need to handle attachments yourself with all the joys of things like file permissions. By bootstrapping it with the existing attachments system (for example) there's no duplication and much lower support overhead.

QuoteIts not like plugin manager can't still scan the packages directory or do the LE.

If only that's what it actually did. The plugin manager still relies on the packages system to actually perform installs etc. and the language editor is a direct integration of the SD files.

QuoteMy thoughts where you would be able to decompress it into a directory, run the installer which would setup a settings file with the link to SMF SSI.php, and a few other basic settings and off you go.

Yeah, that'd be the ideal except it means a massive rewrite and all kinds of support issues that were never support issues in the first place even assuming the rewrite doesn't generate new bugs.

QuoteI've also toyed with the idea of seeing what we could do to start a abstraction layer, so SMF isn't the only source it will work on but other forks such as Wedge could use SimpleDesk.

No chance it's going to work on Wedge. I did make the port to Wedge and mostly it worked last time I tested it, even allowing for all the bazillions of changes in our markup. But I realised ultimately that I want to rewrite from scratch for Wedge to fix some of the architectural issues that are present (e.g. being able to assign multiple people to a ticket and the mess that is the current 'items to do' count for each user), plus there's things like the Wedge notifications system that can be used now.

SleePy

Quote from: venguard223 on August 15, 2013, 12:03:53 AM
The problem with it is that you end up having to reduplicate a ton of stuff. For example you'd pretty much need to handle attachments yourself with all the joys of things like file permissions. By bootstrapping it with the existing attachments system (for example) there's no duplication and much lower support overhead.
It's quite possible we could still get it done with little overhead.  FYI, I am sure you know/remember, but the customize site uses SMF's attachment system as well.  It does do a lot of direct handling, more than I would want SimpleDesk to do, but still has SMF handle a good chunk of it.


QuoteIf only that's what it actually did. The plugin manager still relies on the packages system to actually perform installs etc. and the language editor is a direct integration of the SD files.
We should be able to use PacMan and LE without being in SMF or get stuck in weird SMF issues like redirects and whatnot.  Yes there would be some code copying, but otherwise it may be doable.

Quoteassuming the rewrite doesn't generate new bugs.
That's a undocumented feature.

QuoteNo chance it's going to work on Wedge. I did make the port to Wedge and mostly it worked last time I tested it, even allowing for all the bazillions of changes in our markup. But I realised ultimately that I want to rewrite from scratch for Wedge to fix some of the architectural issues that are present (e.g. being able to assign multiple people to a ticket and the mess that is the current 'items to do' count for each user), plus there's things like the Wedge notifications system that can be used now.
Doesn't mean that the abstraction layer couldn't call a notification system and in SMF it does emails or PMs and in Wedge it would do the notification system.  The API would basically say, here is this data, you handle it now.  For a notification system, we don't care about the results.  Other things we would and that would get tricky.
Jeremy D — Spare-Developer