Gossamer Forum
Home : Products : Gossamer Links : Development, Plugins and Globals :

Multiple object properties plugin

Quote Reply
Multiple object properties plugin
I decided to open a new thread for this plugin idea, as it was multiple times discussed, in some threads containing "arbitrary tables" keywords.
I wanted to collect the links of related threads into one thread, and also attract such discussions here.

It seems, Aki, Yogi, Pugdog, myself and maybe others also faced this drawback of Links SQL, which is discussed in this & other threads listed below. I believe, we all did face the facts, where are the limits of Links SQL, and which missing features are limiting improvements of our website and web developments.

The threads which containd discussions related to this subject:
http://www.gossamer-threads.com/...ary%20tables;#213838
http://www.gossamer-threads.com/...ary%20tables;#206049
http://www.gossamer-threads.com/...ary%20tables;#240823
http://www.gossamer-threads.com/...ary%20tables;#275415


Similarly as Pugdog had such development plans, I also planned to develop a plugin, which will create the possibility to have properties attached to each object.
Pugdog calls it "arbitrary tables" feature, I call it "multiple object properties" feature, but I think the idea behind is the same.
Currently it's still just a plan for me, maybe sometime in the future will have (or will need to have) time to develop it, as my website will need this feature.
I think Pugdog is in similar situation like me, having a lot plans & ideas, and not enough free time for all developments.


Anyway, let me express my ideas behind my "Multiple object properties" project:


Currently we have some objects like: Links, Categories, Users

Current solution in LSQL:
Our current problem in LSQL is, that a link record may have only 1 to 1 selection for a property.
This is similar, to radio buttons. You can have only 1 choice for 1 question.

Wanted solution in the plugin:
But we need to have N selections for 1 link record property.
This would be a "checkbox" like solution, so we could have N selections for 1 question.
This kind of solution is missing from current Links SQL implementation, so we will need a plugin for that task.

The main object list is managed the plugin config.
By default would likely contain: Links, Categories, Users
But the list could contain any kind of object, not limited to these.
So if we want to add a Review object, we can safely do that.
We can also remove objects. Safe removal can be done, if object table contains no data, yet. If object table already has data, should force a confirm dialog (warn that data will be lost), if a backup checkbox was checked do data backup, then after confirmation if accepted, can remove object properties data.

The object properties are also managed the plugin config.
We can add or remove objects properties from the plugin config panel.

Some features, notes:
  • Each object can have properties attached. Links, Categories can have properties, and Users might also have properties.
  • Each object property object needs a separate table, where properties are stored.
  • Each object property object needs a separate data table, where data for properties are stored.




    It's quite such an ideal task, which can solved very well with object oriented programming.
    The solution should be not very difficult (however at first sight everything seems easy, then later do you face how difficult the development can be Laugh), but definitely I should first have free time, to work out the idea and the plugin in details.

    Let me have a small request: let me reserve the "Multiple object properties plugin" name for myself, in case that I will ever develop this plugin. I don't think this would mean any problem to a developer who may develop such plugin earlier.

    Best regards,
    Webmaster33


    Paid Support
    from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
    Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
  • Quote Reply
    Re: [webmaster33] Multiple object properties plugin In reply to
    Pugdog wrote:
    In Reply To:
    If someone wanted to fund this, it might be a possible. But, I can only give this a few hours a week of thought, and sometimes not even that much. It needs about 10+ hours a day for 15 to 20 days, at least, and that is an expensive proposition to get the skelleton worked out. It probably needs an additional 10 to 20 days to get a working beta, and who knows how much time after that to get it really working. I estimated this at about 300+ hours of real work, not counting "brain time" which is that time you spend thinking about it, drinking beer or diet coke, playing puzzle games, etc to figure out the sticking points.

    Just thinking loudly...

    The 300 hour is around 2 month development time, if the developer works on it, in full 8 workhour a day.
    This would mean at least 300 hour x $15/hour development price = $4500 development value.
    Also this would result a final price between $200 and $450, to cover the time invested into the development.
    And this is just calculated by my low development prices.

    The question is, if website owners could afford such plugin price or not...?

    Best regards,
    Webmaster33


    Paid Support
    from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
    Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
    Quote Reply
    Re: [webmaster33] Multiple object properties plugin In reply to
    Where do you come up with the $15 hour price???

    Average programming time is between $35 and $150 an hour, with the modal vaule being somewhere between $50 and $75 an hour.

    The reason is how programming hours are calculated. This goes back to the original work, "The mythical Man Month".

    I've carefully, over 2+ years considered this.

    We are talking about at least 300 hours, with the cooperation of GT, to make some minor changes, and perhaps incorporate the changes into the core code.

    Today was the first time I noticed that you charge $15 hour for programming. Unless you program every day, for at least 8-10 hours, and have a boss paying your SSN and other taxes, benefits, etc, you are grossly undercharging for your time. But, that is up to you.

    This is a change to the core code of at least $25,000 , and in the range of $18,000 to $75,000 depending on actual time, and hourly charges.

    This is based on the cost of a *real* skilled programmer at the rate of $100,000 to $135,000 per year, with benefits. Not on the cost of a high school kid, who spends most of their time learning the ropes.

    I realize this is not the forum for business talk, but the real costs of program development have to be considered.

    For 2-3 months of full-time development, at the rate of $100k + per year, you are lookit at at least a minimum of $35,000 with benefits, but with over time, or perks, bonuses, or extended dvelopment time, you are looking at anywhere from $35,000 to $75,000 to develop this.

    If you were wondering why things don't happen, or updates take so long, it's because they are worked in to the various "extra" time of staff programmers who at starting salary make $35,000 per year, to the real braniacs who make upwards of $75-150,000 per year, to the *real* elite, who can pull in $250k or more a yea.r

    It's based on their ability to solve problems, and create solutions, and thereby save money for the support division of a company, which can eat up as much as 60% of net profits.

    But again, this is not a business forum.


    PUGDOG� Enterprises, Inc.

    The best way to contact me is to NOT use Email.
    Please leave a PM here.
    Quote Reply
    Re: [pugdog] Multiple object properties plugin In reply to
    Quote:
    Where do you come up with the $15 hour price???
    Average programming time is between $35 and $150 an hour, with the modal vaule being somewhere between $50 and $75 an hour.
    I know, that my $15 price is very low.
    However I live in Hungary, and that price is a fair hourly price here. But since the dollar-euro exchange rate is getting worser, I will have to increase my prices, as this price is getting low here, too.

    Anyway, salaries are not so friendly here, compared to a $5000 monthly developer salary in US.
    A $2000-$2500 monthly salary is a very good salary (almost to say a top salary) in Hungary. Unsure
    Of course there happen to have higher salaries, but it's rare.

    The real problem is, that I found, most LSQL users, can NOT afford even the $15/hour custom development price.
    Or maybe they don't know, that my $15 price/hour is a really friendly price. Cool


    Quote:
    For 2-3 months of full-time development, at the rate of $100k + per year, you are lookit at at least a minimum of $35,000 with benefits, but with over time, or perks, bonuses, or extended dvelopment time, you are looking at anywhere from $35,000 to $75,000 to develop this.
    It means that computing with your lowest development price suggested ($35000), would result a final plugin price between $1750 - $3500. That's irreal high price.
    If we multiply planned sellings by 10x, that means $175 - $350 price. That's irreal high selling amount.

    I realize, that until there are so cheap Perl programmers (not to hurt Andy, he is *my friend* and it's not about him personally), who are pricing their plugin mostly below $50, then it's difficult to come out with plugin prices between $200 and $500. GT's plugins are around this range, so they are positioning their plugin prices more realistically.

    I think a final price between $200 and $350 would be valid, but in that case it will be undervalued, based on the supposed $35000 total development price.

    The question still is, if website owners could afford such plugin price or not...?


    Quote:
    I wanted this as an open-source group project anyway.
    I don't really have other income nowadays (now, finishing my college studies also badly affects this), so mainly I live just from programming and my website development. Can I ignore this fact?
    We can make that plugin in group work for free, but the question is then: can *we* afford this for free???


    Quote:
    I realize this is not the forum for business talk, but the real costs of program development have to be considered.
    If do you think, that we should NOT continue the discussion publicly, we can continue in PM.

    Best regards,
    Webmaster33


    Paid Support
    from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
    Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
    Quote Reply
    Re: [webmaster33] Multiple object properties plugin In reply to
    Time is still the demon here. The largest blocks of time are found in Highscool and College kids, with the next block being someone on someone elses payroll <G>

    On the surface, this seems simple, but there are a whole lot of "gotchas" that have to be worked out first. And, the dispatcher concept is probably the best way to avoid most of them, but to get that working, requires complete reassembly of the GT database and table .defs and default behavior (eg: associated, dependent, FK, etc relations).

    Most of the time is working through the actual program flow, and fixing any "bugs" in the current system, while creating this new super-level of dispatch. The reason is to maintain performance, and stability, and continued growth, *ALL* bugs, hacks, and such have to be removed, and *ALL* table access has to be done in a uniform manner. Otherwise, a new plugin or upgrade is installed, and the entire cascade can break. The current behavior has to be put under a microscope, and any "bad behavior" changed and eliminated. No short cuts, or "exceptions" allowed, unless they go through the dispatcher too.

    Once that is done, the rest of the work is fairly trivial, just connecting up parts of the existing sytem, and writing a management interface to link in the tables, and such. It's grunt work, not brain work. (for the most part). But, again, it's _time_. That's the problem.

    The current system acts as an interface or buffer between MySQL and the DBI:DBD interface, and the application programming.

    It imposes some rules/restrictions on the requests, some are managed by the GT engine, while others are converted and passed through into the DBI:DBD interface, which manages the actual connection to the SQL database.

    The dispatcher is another level, that sits between the application and the GT engine which connects to the DBI:DBD interface. It doesn't quite replace it, but it has to interpret what the GT application is asking for and pass it on. Maybe, it's more correct to visualize it as sitting 1/3rd of the way into the GT engine? Not quite in the middle of it, but not on either side of it either.

    This code has to understand how your database is set up via the .def files, and create the appropriate calls.



    In the simplest version, you attach tables via the dispatcher that just keeps a set of linked fields for each type of request. So, when you request LinkID 1003 it checks the dispatch table for any always linked tables, then the data for the 1003 link, for any special tables, and returns all the _required_ data for THAT request (not all the data).

    This can be done as a plugin, but it has performance issues, and some gotchas. *AND* it still has to make some changes to links core behavior.

    But it can be done.

    It doesn't require attacking the GT::SQL engine codes at all (except for fixes).

    But, it has limitations, and requires a whole new search routine written -- which is *not* a bad thing. No major search engine uses a stock, or one-table search engine. The search has to pull from various sources for performance and simply "mass" issues.

    My time estimates are for the above "plugin" solution.

    The costs go up, if the dispatcher actually has to sit inside the GT::SQL engine. Maybe double.



    Remember, Links SQL was a port of Links 2.0, with all the quirks and bugs and backwards compatible behavior.

    Links SQL 2.0 was a complete rewrite of the core code, and some of the logic, most notibly the separation of the "Link" from the "category". But it was still logically backwards compatible to the old links.


    This new program will have to be a complete RETHINK of how this works, since it will all have to be considered objects (and needs to be considered that way if the output is going to port to CSS easily). A "Link" is an object, and associated parts. Some are attached all the time, others are attached some times. But each of those parts is an object in itself. EG: A "Body" has a Head, Legs, Arms, etc. Those are attached all the time. But it also has clothing, hats, shoes, tools, etc that are attached only SOME times. Each of those also has properties and behaviors.


    For example, and this is *not* a good one, a Link may have different properties based on what category it's in. If it's in both the local area and the regional category, the associated table with regional data is attached. But, when it's called from the local category (or more info is requested) the "local" data is now attached.

    Or, if an item is being browsed from the category "Tea Pots" the associated "Gift" properties are not attached, if the person is not looking for a Gift. But, if they are searching for a gift, then you change the fields you show, by attaching the specific gift properties, such as boxing, or other options.


    Like I said, it's not a good example, but it shows how far the associated data can go. The dispatcher *needs* to be able to handle that, even if the first 9 releases don't go beyond 1 or 2 levels of associated tables, the logic has to be able to handle, and expand to, handling 3 4 or 5 levels *if* the coding was done efficiently.


    PUGDOG� Enterprises, Inc.

    The best way to contact me is to NOT use Email.
    Please leave a PM here.
    Quote Reply
    Re: [pugdog] Multiple object properties plugin In reply to
    I believe, you are overestimate the task.
    It may be possible tough, that I underestimate the task, but I trust myself and I hope did not underestimate it.


    Quote:
    The dispatcher is another level, that sits between the application and the GT engine which connects to the DBI:DBD interface.
    There are multiple dispatcher levels, not just one. But we can all dispatcher levels as a merged, simplified one in the scheme.


    Quote:
    This can be done as a plugin, but it has performance issues, and some gotchas. *AND* it still has to make some changes to links core behavior.
    Yes, may be done as plugin.
    And yes, some core codes may need to be rewritten by the plugin level.


    Quote:
    requires a whole new search routine written
    Yes, that's true. This is the only serious drawback I see.
    This may need a lot time... But if we are lucky, we can suffer with some code duplication and small changes. Unfortunately this would also mean, that future LSQL versions will be not automatically compatible, but an update/patch will be needed to match the changed codes. If only small changes were done in the core search code, manual patches can be done quickly, so this would not be a serious problem.


    Quote:
    This new program will have to be a complete RETHINK of how this works, since it will all have to be considered objects (and needs to be considered that way if the output is going to port to CSS easily). A "Link" is an object, and associated parts.
    That would be only true, if GT would decide to implement this feature deeply into LSQL.
    Yes, that would mean a full rethink of LSQL base concept and code.
    But as plugin it has less cost, and faster development.


    Quote:
    Like I said, it's not a good example, but it shows how far the associated data can go. The dispatcher *needs* to be able to handle that, even if the first 9 releases don't go beyond 1 or 2 levels of associated tables, the logic has to be able to handle, and expand to, handling 3 4 or 5 levels *if* the coding was done efficiently.
    I don't plan so complex solution.
    I would keep it simple as much as possible (only 1 additional property level per object).

    Best regards,
    Webmaster33


    Paid Support
    from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
    Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...