scaling list addressing

[joejoe]

Hi and thanks!



I would like to associate a username with a bunch of schedules (lists), or vice versa.



Would anyone please direct towards an efficient way to scale this type of data structure:

Code Select Expand

; Format: Schedule# (Username, Schedule Name, Start Time, Interval in Seconds, Expiry).

(set 'S0 '("Username" "Feed plants" 1450754544 604800 1456197744))
(set 'S1 '("Username" "Manicure plants" 1450754544 259200 1453346544))
Or should I use this format:

Code Select Expand

(set 'Username
 '(("Feed plants" 1450754544 604800 1456197744)
   ("Manicure plants" 1450754544 259200 1453346544)
  )
)
And would implicit addressing be the best way to call up the list elements?



Very much appreciate and thanks again! :)

[TedWalther]

I would do it like this:

Code Select Expand


(define schedules:schedules)
(define (schedules:add u)
  (let (s (sym (string "_" u)))
    (if (eval s)
      (push (args) (eval s) -1)
      (set (sym (string "_" u)) (list (args))))))

(schedules:add "user1" "Feed plants" 1450754544 604800 1456197744)
(schedules:add "user1" "Manicure plants" 1450754544 259200 1453346544)

(println (schedules "user1"))


Although this doesn't handle your "vice versa" scenario.  Are all "schedules" guaranteed to have unique names?

[joejoe]

Swiss Army Ted!



Greatest improvement! Thank you for this!



I like that your schedules:add method allows me to put in more list elements if needed!



I also appreciate how this method creates a nested list of usernames with their associated data.



How then would be best to use implicit indexing to call up the user schedules?

Code Select Expand

(println (schedules 1 1))
returns an error:

Code Select Expand

ERR: invalid parameter in function println : 1

As for the vice versa mentioned above (associating schedules with multiple users):



One thing I am considering as I further this code is to allow multiple users to access the schedules of other users.



Ok and greatest of thanks again, Ted! :0)

[TedWalther]

You're welcome JoeJoe.



What I'm doing is using the red-black tree implementation, or "contexts as dictionaries".  This is a common idiom in newlisp, very fast and easy.



So the question is, is a schedule unique.  What do you mean by "allow another user to access the schedule".  Does a schedule always belong to one and only one user?

[joejoe]

TedWalther,



I appreciate the "contexts as dictionaries", thanks and it makes great sense!

So the question is, is a schedule unique.

Yes, every is schedule unique.

What do you mean by "allow another user to access the schedule".

I mean, any user could access another's schedules.

Does a schedule always belong to one and only one user?

A schedule would be created by one and only one user, and optionally shared with other users.



Big thanks TedWalther!

[TedWalther]

Too vague.  How would "other" users access a users schedule?  What would they do with it?

Code Select Expand


(define user-schedules:user-schedules)
(define (user-schedules:add u s)
  (let (nu (sym (string "_" u)))
  (if (eval nu) (push s (eval nu) -1) (set nu (list s)))
  )
)
(user-schedules:add "user1" "schedule1")

(define schedules:schedules)
(schedules "schedule1" (list 1 2 3 4))


Sounds like you want some sort of permission schemes.  To really do this, you need to specify, what are the access controls you want.  Which users can do what, with each schedule.  Are you trying to make schedules visible and invisible on a per user basis?  How is this data being accessed?

[joejoe]

Thanks again TedWalther!

Too vague.  How would "other" users access a users schedule?  What would they do with it? [...]

When a user creates a schedule, that user can set that schedule to be private or public.



Users could create their own schedule or they could browse and use public schedules. Each user would have a list of schedules they have started to use, something like "My Current Schedules".

Sounds like you want some sort of permission schemes.  To really do this, you need to specify, what are the access controls you want.  Which users can do what, with each schedule.  Are you trying to make schedules visible and invisible on a per user basis?  How is this data being accessed?

You are correct on needing permission schemes. Access controls for each schedule would be public or private. Any user can use any public schedule. A private schedule can only be viewed and used by the user who created it.



Would your suggested code still apply to this situation? Thank you again! :)

[TedWalther]

So your data model is like this:



Every schedule is unique, will have a unique name or key.



Every schedule will have a creator/owner.



Every schedule will be either public or private.



Then I propose that the schedules format is like this:

Code Select Expand


;; (schedule "schedule1" "owner1" 'public 1 2 3 4 ...)


Thing is, how will the code know which user is calling?  That info has to be passed into the code somehow.



Are you doing this for a school project?

[joejoe]

So your data model is like this:

Every schedule is unique, will have a unique name or key.

Every schedule will have a creator/owner.

Every schedule will be either public or private.

Then I propose that the schedules format is like this:

Code Select Expand


;; (schedule "schedule1" "owner1" 'public 1 2 3 4 ...)


That makes the best sense, I see this completely, thanks Ted!

Thing is, how will the code know which user is calling?



That info has to be passed into the code somehow.

 

I would guess a login system. I have installed http://newlisponrockets.com">//http://newlisponrockets.com a few times.



Once logged into Rockets, I could pass the schedule info into a modified blog post in the Rockets database?



If any simpler way occurs to you, that would be superior! :)

Are you doing this for a school project?

That would be a luxury indeed. :-)

[TedWalther]

Then do this:

Code Select Expand


(define (schedule:get sched usr)
  (let (s (schedule sched))
    (if s
      (if (or (= usr (s 0)) (= 'public (s 1)))
        s
        'access_denied)
      'not_found)))


Once you confirm that works, you can add more code on your own to verify that the user is valid before returning a schedule.



Just have a separate context called "users".

[joejoe]

Ok big thanks Ted!



I understand the code above to test whether a script is public, and allow it if so.



Am I on a good line of thinking to have a user/pass/cookie allow private schedules to display?



Thanks again! :)

[TedWalther]

Am I on a good line of thinking to have a user/pass/cookie allow private schedules to display?

Yes, as long as the cookie lets you know who the user is, and you are using SSL (https).  SSL will mitigate from people snooping the connection and copying the cookie.

[joejoe]

Super, got you 100% Ted!



Correct me if better,



Get going with the cookie here:



http://www.newlisp.org/syntax.cgi?code/cookie-cgi.txt">http://www.newlisp.org/syntax.cgi?code/cookie-cgi.txt



and tie it to the user form login info? Then use both to authenicate schedule access?



Thanks again!